After Dell updates, Virtual Novell server under VMware 2 on Windows 2008 R2 server is now inaccessible from Vmware player clients running Novell IPX/SPX clients

Hello.  Have an emergency with VMware 2 - yes that is correct - not binding properly, I believe, on a Windows 2008 R2 SP1 server.    I am running a legacy Novell 3.2 system in the Vmware 2 environment.  Since VMW 2 is non-dedicated it can run as services on the Windows 2008 R2 server.  Clients are running Vmware Player with the Novell IPX enabled This has been working flawlessly for the last 4 years, but last night I ran some updates from Dell for BIOS, RAID firmware and driver, and lastly Dell Open Manage server administrator.  Rebooted after the updates and now none of the Vmware player clients can see the virtual Novell server.  The VMW 2 server is normally configured to use the NIC in bridged mode, which is the only way that the Novell client and IPX will be transmitted through.  NAT will not work for the Novell client to access the Novell server.  Vmware player clients are all set up with Bridged mode to their NIC's as well.  Needless to say, Dell can not assist on this.

I've removed and reinstalled the VMware 2. but am unable to connect from any VMware Player client. I am beyond desperate as the client is now down and unable to access their main case management database, Saga DOS, which runs in the Novell virtual server under the VMware 2 environment.  Any help on this would be welcome.  Probably best for someone to remote access the server / webext style.  

Thanks in advance.

Who is Participating?
jkirmanPrincipalAuthor Commented:

I figured this out earlier today.  Turns out that the Dell updates didn't break anything, they added a networking component that basically mucked up the situation.  The key was which adapters were bound to the VMWare Bridge protocol.  I looked at this after reading the following article:

{... beginning of article reference...}

Everything is fine but virtual machines are not able to communicate

If everything seems fine, there are no errors displayed but the VMs are not able to communicate then the following things should be checked.

The network interface to which vmnet0 is bridged. If there are multiple network adapters on the host machine the virtual network might be bridged to the wrong network. To eliminate this problem disable the “VMware bridge protocol” option by going to the connection properties of the network interfaces which should not be used for bridging.

{... end of article reference...}

Originally, the Windows 2008 R2 SP1 host server had the following network adapters:

Intel physical dual-port GB NIC 1 (connected)
Intel physical dual-port GB NIC 2 (connected)
Intel Team #1  (this is the main network connection for the server)
Intel GB LOM 1 (disconnected)
Intel GB LOM 2 (connected, used for iDRAC7)
VMWare Network Adapter VMnet1
VMWare Network Adapter VMnet8

In hindsight, the VMWare Bridge protocol was enabled on the Intel Team #1 adapter, and VMware traffic was accordingly bound to, and went through, that adapter.  I did not know to look at or even consider this aspect of the networking setup when I was first troubleshooting the issue.

After running the iDrac7 update, it created an additional adapter called:

iDRAC Virtual NIC USB Device

The benefit of this device (more of a service, according to Dell) is that it allows the iDRAC7 interface and controls to be accessed via local login on the Dell WIndows host server.  Without the adapter, per Dell, you can only login to the iDRAC7 web interface from another system.

After reading the above-referenced article, I took a look at the properties of each NIC, and I saw that the VMWare Bridge protocol was enabled on the IDRAC Virtual NIC adapter.  It was also enabled on the 2 LOM adapters, probably because as part of my diagnostic efforts on this, I had removed and reinstalled VMware 2, and I assume it automatically added and enabled the VMware Bridge protocol to / on all available adapters.  Within the properties of each NIC, I then unchecked the VMware Bridge protocol for each adapter, and left it checked and active for only the Intel Team #1.

After that I restarted the VMware services on the Windows host, started up the virtual Novell server, and saw the most beautiful error message after the Novell server's NIC driver loaded, namely that the other (physical) Novell server didn't like the network address I was using on the virtual Novell server.  

So in the end the solution was actually just a key click away (technically 2).  A "virtual" needle in the haystack.

Many thanks again for your suggestions.  They are always appreciated.  GIGS looks like an excellent resource, will definitely put that to use if and as needed.

Unless you prefer otherwise, I will be splitting points between my solution and your last comment / suggestions.

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
I would recommend you restore you server to a backup of VMware Server 2.0, which is an out of date product and not been supported for many years.

Something has broke when you complete he server update.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
This expert suggested creating a Gigs project.
I'm going to Recommend creating a project in Gigs for this question for someone to interact with you live to fix this issue.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

jkirmanPrincipalAuthor Commented:
Andrew, many thanks for your responses.  For the moment, I was able to put in a stopgap fix using an old physical Novell server I had on my rack which I hadn't used for a number of years, but is still physically viable.  Obviously I need to get them back on the virtual Novell as soon as possible.  One thing I forgot to mention in my original case description was that their Windows 2008 R2 SP1 server crashed on Monday night, and it was for that reason Dell recommended updates for the BIOS, idrac7 and RAID driver & firmware, and also Open Manage. I'm wondering if either the updates or the crash somehow altered or corrupted some part of the virtual Novell server's network configuration.  I'll be testing a backup of the virtual server and will post the results here.  

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Changing the Host OS may have led to compatibility issues.

Windows 2008 R2 SP1 server crashed on Monday night, and it was for that reason Dell recommended updates for the BIOS, idrac7 and RAID driver & firmware, and also Open Manage.

if you've been running fine for years, unlikely this was the issue.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Dell changes you made as advised by Dell broke it!

Don't apply updates and changes as recommended by Dell.

This is a warning shot, time to start thinking of migrating away from Novell Netware and VMware Server 2!
jkirmanPrincipalAuthor Commented:
Apparently I can't split points between us, since I assume I can't award points to myself - not a problem, I'm not remotely active in solving issues on this site, so glad to see the points go to you.

After this latest episode, I am thinking the same thing you said about migrating away from Novell etc.  Unfortunately case management migrations are massively expensive, but as you mentioned, this was a warning shot for operating in completely unsupported territory.

jkirmanPrincipalAuthor Commented:
Was able to solve the issue after reviewing a number of online articles.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.