Jump to content
Welcome to our new Citrix community!
  • 0

Updating VMware Tools in PVS using e1000, not working for me


Stephen D. Holder

Question

Greetings all,

 

I’m trying to update VMtools and target device software on a much-needed system using Aaron Silber’s method.  The ideas seems solid, however I think this is written only for PXE connections and not BDM .isos and of course… the organization I’m at only uses boot isos for their PVS environment.

 

I can get all the way up to step #8. In his article it should boot no problem on the E1000, but in my situation, I’m presented with the attached error.

 

No matter what I do to try and manipulate I keep getting this error. Funny thing is, if I remove the E1000 NIC and put everything back to the way it was the boot iso will boot just fine off VMx3

Any thoughts? I’m not looking forward to reverse imaging anything if I do not have to.

 

Thanks.

 

 

image.thumb.png.e149c6f1323eae4f44ab2c96e5500516.png

Link to comment

17 answers to this question

Recommended Posts

  • 1

Hi Mfernan,

 

No, I was not able to get it to work - I continued to bomb out during the bait & switch of the e1000. I'm inclined to mark duly and Carl Fallis response as the best answer, summing up that the e1000 method is old, unsupported and the technology expects different things to happen.

 

I went with the BCDEDIT method from our good friend Carl Stalhood. This is where you mount a .vhd needing updating, through a dedicated VM. It takes a little dancing to get it to work, but after going through 3 vhd's successfully I got the hang of it.

 

Not sure if it's faster than the e1000 bait & switch, but I think it is a supported method by Citrix and is clearly faster than traditional reverse imagining. 

 

Stalhood's wright up is pretty good, but I also created my own document. If you are interested, you can private message me and I'll send you my PDF.

  • Like 1
Link to comment
  • 0
8 minutes ago, shocko said:

Yes but for the ISO method have you actually booted back up into maintenance mode with the E1000 streaming the disk? This would be key I'd imagine. 

 

.... not sure I follow you. 

 

Step 1 in the article says  From the "PVS Console, place the image into Private Image mode."

 

This whole process is in private mode...

 

Link to comment
  • 0
On 6/20/2018 at 4:02 PM, Joe Shonk said:

What is the use case for using the E1000?  If the VMXNET3 adapter is working why wouldn't you use that?   the VMXNET3 adapter is much better to use that the E1000.

 

Joe

 

Joe,

 

The use case is to be able to update VMtools (more specifically the NIC drivers) literally within minutes instead of potential hours, getting around the traditional reverse imaging method. Multiple that by the number of pvs vdisks and it can be a real time saver. If you look at my original post, follow and read that link, you should see how the idea is appealing.

Link to comment
  • 0

It seems like ESX is acting different than what BDM is expecting.  ISO booting using 2 VMXNET3 or 2 E1000 works.  It's just the mixed E1000 and VMXNET3 that fails.  The error inidcates a problem with the UNDI, which is required by BDM booting.

Link to comment
  • 0

Hi all,

 

I had the same problem when trying to boot with both type of NICs (E1000 + VMxNET3) at the same time, we also use BDM

However I got VMWare Tools up to date in my environment following the steps below.

 

- Created new vDisk Version
- Boot
- Added the E1000 NIC, let the drivers install
- Shutdown
- Added another E1000 while removing the VMxNET3 (Was nessesary in my environment as there was a quirk when trying to remove the NIC otherwise)
- Updated the MAC Address in PVS
- Boot
- Updated VMware Tools
- Added VMxNET3
- Shutdown
- Removed all NICs (E1000 x2 & VMxNET3) and added VMxNET3 (again because of the quirk)
- Updated MAC Address in PVS
- Boot -> OK
- CMD: set devmgr_show_nonpresent_devices=1
- CMD: devmgmt.msc
    -> View -> Show hidden devices
    -> Removed the E1000 NICs

 

My colleague tried this yesterday and got bluescreens after removing the E1000, I think what I did different was the sequence.

Hope this works for you aswell.

 

Link to comment
  • 0

pbostelmann is absolutely correct. 

 

By simply adding again the VMxNet3 network adapter right after installing the VmWare Tools prior to shutting down, one is able to remove the E1000 and boot up again on the VmxNet3 without BSOD.!! 

 

Full process is: 

1/ With the BUILD server booted and the image in private mode, add an E1000 Network Adapter to the VM and let windows install it. 
    Ensure you select the same Port Group than the existing Network Adaptor used for Streaming. 

 

2/ Shutdown the VM. Edit the VM and take note of the E1000 MAC address. Remove the Vmxnet3 fully (disconnect is not enough). 

 

3/ From the PVS console change the BUILD server MAC address to the E1000 network adapter.

 

4/ Boot the Build server up. It will use the ISO as usual but the E1000 network adapter. 
    Please note that booting from the E1000 network adapter is extremelly slow. In UAT I had to reboot some servers several times.

 

5/ Update the Vmware tools Select the Complete setup type.

 

6/ When prompted to reboot, say No and add a VMXNET3 adaptor whilst the VM is running. Let is install. and then Shutdown.

 

7/ Remove the E1000 network adapter. Take note of the VMxNET3 MAC address.

 

8/ Set the MAC of the BUILD server to the MAC of the VMxNET3 adapter and boot the server up.

 

 

Link to comment
  • 0
On 6/22/2018 at 9:30 PM, Stephen D. Holder said:

 

Joe,

 

The use case is to be able to update VMtools (more specifically the NIC drivers) literally within minutes instead of potential hours, getting around the traditional reverse imaging method. Multiple that by the number of pvs vdisks and it can be a real time saver. If you look at my original post, follow and read that link, you should see how the idea is appealing.

 

So you're willing to sacrifice user experience to save a bit of administrative time?

 

FYI, I've updated VMtool before and many of them don't require a reverse image first.  

 

Link to comment
  • 0
39 minutes ago, Joe Shonk said:

 

So you're willing to sacrifice user experience to save a bit of administrative time?

 

FYI, I've updated VMtool before and many of them don't require a reverse image first.  

 

 

Not sure I follow you... I fail to see where the user experience is being sacrificed..?

 

If you have PVS image and it needs its hypervisor tools updated, in my mind, independent on how you do it, you schedule a downtime, perform the work and cycle the targets accordingly. Where is the user sacrifice?

 

In terms of updating your respective hypervisor tools - perhaps you are using a hypervisor which does not require NIC drivers to be updated within the actual PVS image itself. Perhaps the hypervisor is able to inject its own NIC drivers automatically upon target boot? Maybe you've been using E1000 this whole time?

 

If your hypervisor is VMware and you've been updating the VMtools tools regularly, without some sort of reverse imaging, I'd be very interested to see what Driver Date and Driver Version you are running on your vmnet3 adapter (Device Manager -> Network > adapter vmnet3 Ethernet adapter.) Sure, you can install VMware Tools and uncheck the NIC driver option but then you are missing out on enhanced code that could be leveraged by the host.

 

I am not saying you are wrong - I am not saying I am right, I'm simply curious... how are you updating your PVS vdisk NIC driver ----  without some form of reverse imaging?

Link to comment
  • 0
2 minutes ago, Stephen D. Holder said:

 

Not sure I follow you... I fail to see where the user experience is being sacrificed..?

 

If you have PVS image and it needs its hypervisor tools updated, in my mind, independent on how you do it, you schedule a downtime, perform the work and cycle the targets accordingly. Where is the user sacrifice?

 

In terms of updating your respective hypervisor tools - perhaps you are using a hypervisor which does not require NIC drivers to be updated within the actual PVS image itself. Perhaps the hypervisor is able to inject its own NIC drivers automatically upon target boot? Maybe you've been using E1000 this whole time?

 

If your hypervisor is VMware and you've been updating the Vmtools tools regularly, without some sort of reverse imagining, I'd be very interested to see what Driver Date and Driver version you are running on your vmnet3 adapter (Device Manager -> Network > adapter vmnet3 Ethernet adapter.) In the case of VMware, Sure, you can install VMware Tools and uncheck the NIC driver option but then you are missing out on enhanced code that could be leveraged by the host.

 

I'm not saying you are wrong - I am not saying I am right, I'm simply curious... how are you updating your PVS vdisk NIC driver ----  without reverse imaging?

 

The E1000 and E1000E Network Adapters are both emulated devices.  This means extra CPU cycles are required, by the VM, to provide this emulation.  The VMXNET3 driver, on the other hand, is considered an enlightened driver.  It works directly with hypervisor to avoid system calls that have high overhead.  Lower latencies and lower CPU overhead will translate to an overall better experience for the users.

 

I'm not entirely sure what VMware is doing with the VMXNET3 drivers upon upgrade.  If I had to guess, the driver swapped out during the boot process.  Similar, or perhaps the same method Citrix uses to upgrade the PVS Target drivers.  Beginning with PVS 7.1, you no longer had to reverse image to update the PVS Target agent.

 

Even if it's skipping the driver update, sure, I'd be missing out on the enhanced code that could leveraged by the host.  But I'd be missing out on it entirely if I was using the E1000E over the VMXNET.

 

Vmtools updates are one in a blue moon.  Users are on the system everyday.

 

Joe

Link to comment
  • 0
On 7/19/2019 at 10:46 AM, Joe Shonk said:

The E1000 and E1000E Network Adapters are both emulated devices.  This means extra CPU cycles are required, by the VM, to provide this emulation.  The VMXNET3 driver, on the other hand, is considered an enlightened driver.  It works directly with hypervisor to avoid system calls that have high overhead.  Lower latencies and lower CPU overhead will translate to an overall better experience for the users.

 

 

Hmm ok... I think I see what happened here... I think I may have accidentally mis-led you in my original post..

 

To be clear, the original post was about updating the VMware's NIC drivers in the vdisk. That wasn't specifically identified until I gave the use case (and even then it was kinda vague.) I'm assuming, but going back and reading, I can see how you may have thought I'm trying to swap out the vmx3 for E1000 for a 'fast fix', but that is not entirely true.

 

Taking your quote of me about the use case for the E1000 ---  the E1000 is not meant to be permanent, rather more of a interim patch while the VMtools (specifically again, the VMware NIC drivers) are being updated. In Silber's article you can see where he 'bait and switches' in steps 8 - 14. At the end of his article, he's booting from vmx3.

 

I don't think anyone is advocating to run their PVS targets off  E1000, because as you stated, yes, we'd want to have the low latency and enlightened driver available for optimal performance.

 

My purpose of the original post was to figure out if there was a faster way of updating the vdisk's VMware's NIC drivers - which as far as I can tell, still requires some sort of reverse imaging.

 

Hope this better clears the landscape...

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...