Great Tool. I have used it with success tons of times. Recently I setup a new ESXi server on a desktop box. When I try to run the tool it gives me an error about not able to get the host fingerprint Code: -------------------------------------- Injecting bios440.rom to remote server -------------------------------------- Detecting server type and preparing to get vmx file... VMware ESXi 4.1.0 build-260247 ESXi server detected. This could take a while... Determining latest Hypervisor Folder... Latest folder found: Hypervisor1 ESXi version 4.1.0 or greater detected - using file s.z Cleaning up temp files # rm -R /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/ # rm -R /vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/ Creating temp folders to unpack s.z # mkdir /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/ # mkdir /vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/ mkdir: cannot create directory '/vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/': File exists # mkdir /vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/vmvisor-sys/ mkdir: cannot create directory '/vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/vmvisor-sys/': File exists Copying s.z from HypervisorX folders # cp /vmfs/volumes/Hypervisor1/s.z /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/sys.gz Gunzipping sys.gz to vtar file # gunzip /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/sys.gz Converting vtar to tar using vmtar # vmtar -x /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/sys -o /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/sys.tar Untarring files to /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys # tar xf /vmfs/volumes/4db6e076-33360778-709a-002481213d84/vmvisor-sys/sys.tar -C /vmfs/volumes/4db6e076-33360778-709a-002481213d84/tmp/vmvisor-sys/ tar: can't open 'etc/init': File exists Getting host fingerprint Error getting host fingerprint Getting vmx using scp Error transferring vmx file: Operation failed and took 151.90 secs Any help understanding this error would be greatly appreciated. chaz
I think this happens if you set up a new ESXi box with the same IP address as an old one. The workaround is to connect to your ESXi box manually using winscp.exe in the program dir - this will cache the correct fingerprint and the tool will then work properly. I'll look at automating this in the next build. btw - it looks like etc/init is locked so i'd do a reboot or put the server into maintenance mode before you try again.
just as a note regarding this tool, if you install the Patch Release ESXi410-201104001, you need to rerun this tool as the patch will overwrite the SLICed virtual BIOS. However, this could mean there is a newer version of the BIOS with this ESXi patch and thus this newer BIOS needs to be patched with a SLIC cert, although I have not compared them yet, could well be the same aswell that just gets overwritten.
I also noticed if the computer you are running this most excellent tool on has FIPS encryption enabled in the local security policy that the tool does NOT work. It keeps telling me to check if SSH is enabled on the remote host. What is interesting is that I can launch winscp manually with FIPS enabled and connect via scp.
So I think I found out why I'm having such weird results. On the test machine I was using yesterday it consisted of a 4GB USB stick which ESXi is installed on. It also has an internal SATA drive formatted as a VMFS volume. During my initial testing both the USB stick and internal drive were connected. The computer had gone through several build upgrades over the months, but the wonderful Pix tool always came through. Now when it came to the 381591 upgrade, weirdness set in. I've narrowed it down to what appears to be a directory issue with the ESXi tool. If I disconnect the internal SATA drive with the VMFS volume and only rely on my iSCSI QNAP for VMFS storage, I can run the ESXi tool against the new build level and it extracts the "right" BIOS meaning the same one in the previous builds and has the same checksum. I also noticed when using the QNAP ISCSI datastore that the ESXi tool left the \tmp\vmvisor-sys folder with all of the contents. After the tool completed I tried to delete the folder and while most of the contents could be deleted, the usr, vmfs, and var folders refused to delete. When I re-ran the ESXi tool, it did appear to delete the contents before unpacking them again. Maybe a little cleanup is needed after the BIOS extraction process? So I reconnected the internal SATA drive and rebooted. I re-ran the extraction process, and it extracted a different BIOS, the one with the Dell SLIC 2.1 table. So it seems there's something on the internal VMFS volume that is confusing the extraction tool, thus why I'm getting weird BIOS results. To make sure I'm not going crazy I disconnected the internal SATA drive, re-downloaded the BIOS, and it downloads the original correct BIOS. So clearly something with the internal SATA drive is confusing the tool and making it download a different BIOS. The 381591 VMX file that has the correct BIOS has a date stamp of 3/18/2011 and a MD5 of FCECAE33B1437B795F6D97771444A8E2. Using the disconnected SATA drive approach the tool correctly uploads the SLIC'd BIOS, and the VMs are happily activated.
That's good news. The tool does do a cleanup at the end of each operation but if files are locked it can't delete them - and there's little I can do to stop the files being locked. Can you confirm the MD5 of the bios440 in the 381591 VMX? For some reason my update rollup doesn't seem to have applied properly and my build is still showing at 348481. It'd be good to confirm the bios is unchanged.
The MD5 of the bios440.rom file is the same for the last several builds, 4C7619BC196922FFDAD1891D60B8C06A. Any thoughts about the funky BIOS results on my one ESXi host? I just rebuilt a second ESXi host which also has an internal SATA drive and no weirdness. I have all of the logs from the mystery host I can forward. I'm still baffled what's going on when connect the internal SATA drive that so confuses the situation. I don't think when you just use the extact BIOS option that there's any cleanup attempted on the vmvisor-sys directory, at least I don't see that in the logs. There is clean when you do a BIOS inject though.
I now get the fingerprint error too on 2 freshly built ESXi 4.1 boxes I tried this, and although winscp did complain initially about the cert not ok, and cached it, but even then the fingerprint issue remains Tried rebooting the ESXi boxes, now if I connect with WinSCP it will not complain about the cert anymore, but the tool keeps saying: Getting host fingerprint Error getting host fingerprint Getting vmx using scp Error transferring vmx file: Operation failed and took xxx.xx secs Another other hints you can share to work this around?
Aha, found the culprit! Seems that if you launch the tool from a network share, it will fail with the fingerprint error. As soon as I launched it from a local drive location, both servers got patched without any fingerprint errors. Maybe it expects something to be accessible locally only?
I have an odd behaviour of VMware ESX 4.1.0 build-381591 The authentication takes longer then 15 seconds (even connecting with Putty, after inputting password I have to wait ~25 seconds for the prompt to return) hence the tool fails: Code: Detecting server type and preparing to get vmx file... VMware ESX 4.1.0 build-381591 ESX server detected... Getting host fingerprint Host fingerprint found: ssh-rsa 2048 d9:ad:9d:09:92:36:cb:b1:87:d0:bc:cb:fd:1f:ba:1c Getting vmware-vmx using scp winscp> open scp://root:********@10.0.0.53 -hostkey="ssh-rsa 2048 d9:ad:9d:09:92:36:cb:b1:87:d0:bc:cb:fd:1f:ba:1c" Searching for host... Connecting to host... Authenticating... Using username "root". Authenticating with pre-entered password. Host is not communicating for more than 15 seconds. Still waiting... Warning: Aborting this operation will close connection! (A)bort: Abort Terminated by user. Authentication log (see session log for details): Using username "root". Authentication failed. winscp> option batch on batch on winscp> option confirm off confirm off winscp> cd /usr/lib/vmware/bin/ No session. winscp> get vmware-vmx No session. winscp> close No session. winscp> exit Error transferring vmx file: I can of course do it by hand & then the output is like: Code: winscp> open scp://root:**********@10.0.0.52 -hostkey="ssh-rsa 2048 1d:25:10 :d1:92:46:1b:71:91:b2:0a:ff:0d:fd:6e:75" Searching for host... Connecting to host... Authenticating... Using username "root". Authenticating with pre-entered password. Host is not communicating for more than 15 seconds. Still waiting... Warning: Aborting this operation will close connection! (A)bort: - here it hangs for ~25 seconds & then carries on OK (while if run from the tool, it simply Aborts) Authenticated. Starting the session... Reading remote directory... Session started. Active session: [1] [email protected] Any chance to not Abort, but wait? sebus
I'm using VSphere 4.1 update 1. Do I need to download both update 2 and update 3 for fully update. Or just download the latest (build 433742) and install so I have full update?
you need both, only firmware updates are cumulative, and these do more than that AFAIK, unless you have of course an ISO with that build already (an overlay image as they call it), then it is OK and no patches needed