Archive for the ‘ESXi’ Category
Each time a VM is powered on, a new log file is created in the main directory of the VM. These files all have a ".log" extension and the active log file is named vmware.log (though this can be defined in the VMX configuration file.)
VMware records the key events affecting each VM in the log files.
At VM start, the oldest log file is deleted, the vmware.log file is renamed by appending a "-##" sequence and a new vmware.log file is created. For example, here are some of the files in a VM before starting. Note the vmware.log file has a size of 487,490 bytes and is date stamped Jun 18.
The VM is started and you can see that the old vmware.log file is now called vmware-19.log. Also, vmware-13.log is gone.
If we restarte the VM, the same thing happens: vmware-14.log is gone and a new one is begun.
You can find more about VMware files that make up a VM at this link.
Running SBS 2008 migration on a virtual server takes us on a detour down memory lane
Working on a migration of Windows Small Business Server (SBS) 2003 to SBS 2008, I had jumped thru the previous 283 migration hoops (I exaggerate, but just a little) and was ready to boot the 2008 installer DVD with my handy SBSAnswerFile which Microsoft wants me to put on “…the root of a USB drive, floppy disk or a partition on the destination server.” Hmmm….
– USB drive is a no-go on the ESX server.
– Let’s put it on a 2nd virtual hard disk. No, the migration installer didn’t “see” it.
– OK, let’s put it on a virtual CD drive. No. It didn’t see it again.
– Finally, I went to the extra hassle of putting it on a virtual floppy. Success!
The blow by blow follows:
“The first 99% of the project flies by. But the 2nd 99%! Sheesh…” – anonymous
If you ever removed a snapshot in VMware ESX / ESXi, you’re presented with the ubiquitous progress meter. It chunks right along, increasing by 5% every so often. Encouraging.
And then it gets to the dreaded 95%. You’d think you’re almost home.
But you’re probably nowhere close. Stuck.
This is really kind of dangerous. I’ve been tempted to assume that something is hung up. And that leads to thinking a hard reset of the host is required.
How CAN you see the progress? What follows is not an elegant solution, but you’ll at least be able to see what’s going on.
First, you’ll need to go to the ESXi command line (see other posts on the internet for accessing ESXi via SSH.) In this case, I used PuTTY ( http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ) to get to the host IP and command line.
Go to the storage directory of the host, usually /vmfs/volumes, then the LUN directory and finally the VM directory.
Use the following linux command to list the files in time order, latest files last:
This will show you what files have been most recently processed. Repeat this command over time (remember up-arrow to repeat bash commands) and you should notice a progression, disk files progress from lowest to highest, and within a disk, the delta files progress highest to lowes.
For example, if you have a VM called Server with 3 disks, they would be called
And you’d see that they’d progress (latest file change time) in that order. The delta files, created by snapshots, have 6 digit sequence numbers in their names that would progress in reverse order.
Not very exciting, true. But at least you can see some progress. I recently removed a snapshot that took 2:40 hrs. It was up to 99% in about :15 of that.
While installing Level Platforms (LPI) Onsite Manager onto a Windows Server 2003 (a member server running on as and ESXi guest and added to a SBS 2003 domain) all went well, but one service would not start. Final, solution was that the MWService account did not have sufficient permissions. LPI tech support said to add that account to Administrators, Domain Administrators and Enterprise Administrators. This solved the problem.
Read the rest of this entry »
Problem: Using ESXi to setup Windows Server 2008 virtual machine, I was surprised to see a message after booting from the image of the install DVD:
Windows Boot Manager
Info: Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode.
This is from a Dell 2950 III with one Xeon CPU (Quad Core Intel Xeon E5405, 2x6MB
Cache, 2.0GHz, 1333MHz FSB) This is from Dell’s virtualization server catalog with available VMware ESXi and ESX software as an option.
Solution: Turns out, you must go to the system BIOS under the CPU section, and change Virtualization Technology from Disabled to Enabled since the factory setting is Disabled.