I've put up v1005 that logs to a file called output.log in the install folder. If you post up the contents of this after a failure, I'll try to work out whats happening.
--------------------------------------Injecting bios440.rom to remote server--------------------------------------Detecting server type and preparing to get vmx file...ESXi server detected. This could take a while... I don't know if it helps or not, but if I try and run winscp it tries to connect, I get a thumbprint warning, then I get "cannot initialize SFTP protocol. Is the host running a SFTP server?". This is on a ESXi server and I enabled SSH. I can use putty and SSH into the ESXi server.
The next command that's executed is "df -m" which is parsed to find the datastore folder to unpack the temp files to. Can you post up the result of "df -m" in putty please? ESXi doesn't have an SFTP daemon, the tool uses SCP for the transfers instead. There's a checkbox in winscp to fall back to this.
Filesystem 1M-blocks Used Available Use% Mounted on visorfs 281 244 36 87% / vmfs3 81664 561 81103 1% /vmfs/volumes/4af663c5-9cf15fa0-655e-000c29a35ba3 vmfs3 76800 14771 62029 19% /vmfs/volumes/4af5e3dd-625e6bbe-27e8-000c29a35ba3 vfat 250 77 172 31% /vmfs/volumes/84cdde72-ff098934-b425-0e0b010dfe54 vfat 4095 3 4091 0% /vmfs/volumes/4af5e3dd-34ad89a7-f76f-000c29a35ba3 vfat 250 72 178 29% /vmfs/volumes/330e7a7b-34b85777-8307-c9ce230a376f vfat 286 243 43 85% /vmfs/volumes/c2a427e4-2d317086-fef9-b5750d88536c Yes, using SCP in WinSCP worked on ESXi.
v1.0.0.6 [fix] Fixed bug with more than one datastore folder. Thanks to yngdiego for helping to track this down.
Yup, downloaded just fine, thanks! I got a successful injection, but have the following issues: 1) ESXi 4.0 U1 hangs for a bit during boot on vmware-aam start. 2) Powering on a VM does not work. In the console I can power on the VM but a black screen stares at me and the VM never boots up. 3) When I tried to 'restore vmx backup' ESXBIOSTOOLS crashed with: Description: Stopped working Problem signature: Problem Event Name:CLR20r3 Problem Signature 01:esxbiostools.exe Problem Signature 02:1.0.0.6 Problem Signature 03:4b3e2f42 Problem Signature 04:mscorlib Problem Signature 05:2.0.0.0 Problem Signature 06:4a275af7 Problem Signature 07:41bf Problem Signature 08:a3 Problem Signature 09:System.IO.IOException OS Version:6.1.7600.2.0.0.256.1 Locale ID:1033
@yngdiego You're not having much luck here! Hopefully your experience is not typical... Your VMs are probably not starting becuse of a bad rom mod. Rather than doing a restore, try injecting the original bios back in. I'll try to work out why the restore isn't working for you in the meantime.
Re-injecting the original got errors: # tar xf /vmfs/volumes/4af663c5-9cf15fa0-655e-000c29a35ba3/vmvisor-sys/sys.tar -C /tmp/vmvisor-sys/ tar: write error: No space left on device .... # vmtar -c /vmfs/volumes/4af663c5-9cf15fa0-655e-000c29a35ba3/vmvisor-sys/vmvisor-sys.tar -o /vmfs/volumes/4af663c5-9cf15fa0-655e-000c29a35ba3/vmvisor-sys/vmvisor-sys.tar.vtar could not read shdr
You're running out of space on your main partition. Try rebooting the ESXi server and re-inject straight after the reboot.
Ok so I installed a new instance of ESXi 4.0 U1, downloaded the ROM, modded it, and re-injected it with your tool. Now the VM will boot, and my next step is to install a guest OS and verify the SLIC tables got added. Once all of that works, I'll try restoring via VMX again to see if that crashes.
Excellent tool! A couple more suggestions: 1) Allow a username other than root. If we have lockdown mode enabled, root is disabled. Typically we have a second less obviously named account with root level access. 2) When the VMX and BIOS files are saved, put the build number of ESX(i) in the file name. That way we can more easily tell which build the file went with. If the files came from an ESXi box put 'i' at the end of the build number (e.g. 208167i). I don't know if the BIOS files are unique to ESX/ESXi or not, but if they ever are we know what kind of system they came from. 3) I doubt this is possible, but if all of this could be accomplished via the HTTPS API instead of SSH, that would be easier since SSH is disabled by default. Not a huge deal for a 'hacking' tool. But with all the various commands you run, I'm thinking it's not possible. Excellent work! If you can work out the restore crashing problem, then this will be a perfect tool.
Now implemented (v1.0.1). This is now implemented for vmx backups. The following structure is used: [version + build]\[server ip]\[date/time] If you need to get the rom, just extract it locally from the relevant vmx file. I did look at this but I doubt whether esxi would allow some of the commands used. Vmware won't support an installation that's been shelled into so I doubt they would allow the sort of mods we are doing here through the official interface. I did look at using HTTPS to transfer the VMX files back and forth as it's much faster than SCP but the files are only 8MB so I didn't think it was worth the hassle. Thanks for the praise and constructive suggestions I've also now implemented an unhandled exception routine that logs a stack trace to a file called error.log in the install folder. This should make it a lot easier to resolve any remaining bugs.
v1.0.1 [enh] Added ability to use account other than root [enh] Added ESX/i version and build to vmx backup tree [enh] Added unhandled exception routine to log a stack trace to error.log in install folder
It looks like you do a lot of file manipulation on the ESX(i) host. Would it help if you copied down the 'raw' file to the Windows machine, did all of the extraction, zipping, etc. then just uploaded the result back to the host? Maybe that's what you do now, but looking at the logs it seems a lot of processing is happening on the ESX host. Another suggestion: Do you think it would be helpful to create a subdirectory with all of the files (VMX, BIOS) instead of placing them at the root of your program files? If we are doing this for several hosts, it keeps the directories cleaner. What is the .ZL ROM file?
Almost all of the processing takes place on the server. It would be possible to do most of it locally using ported linux utils but the vmtar utility source is not public and there's no known win32 port of it. I could do this but the vmx file contains all you need and the original bios files are only generally needed once to mod - there's no real need to archive them. FYI ESX and ESXi share the same roms. The ZL file is a zlib compressed copy of the rom that is extracted from the ELF executable and you can safely delete it.
IMHO, the less processing done on the ESX(i) host the better. I'd think it may process faster locally as well. But if you can't run vmtar on Windows, depending on the workflow, doing the rest of the processing locally may not gain you much. If you ported your app to Linux, could you do all of the processing locally and just use the HTTPS APIs, not SSH?