Cincinnerdi Tech Stuff

A mind-numbing read if ever there was one

Archive for the ‘ESXi’ Category

Seven rolling logs – vSphere log files

leave a comment »

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.

ScreenClip(70)

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.

ScreenClip(69)

If we restarte the VM, the same thing happens: vmware-14.log is gone and a new one is begun.

ScreenClip(68)

You can find more about VMware files that make up a VM at this link.

Advertisements

Written by scottledyard

2011, July 7th at 4:40 am

Posted in ESXi

Tagged with ,

We still need floppies? Seriously, Microsoft?!

with 2 comments

Only one installation issue

The end of a long marathon, migrating to SBS 2008

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:

Read the rest of this entry »

Written by scottledyard

2010, March 4th at 7:00 pm

The 2nd 95% – tracking VMware snapshot removal progress

with 7 comments

“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.

This would make you think you're almost done. Wrong!

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:

ls -ltr

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

Server-flat.vmdk
Server_1-flat.vmdk
Server_2.flat.vmdk

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.

Server_1-000005-delta.vmdk
Server_1-000004-delta.vmdk
Server_1-000003-delta.vmdk
Server_1-000002-delta.vmdk
etc.

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.

Written by scottledyard

2010, January 19th at 9:37 pm

Posted in ESX, ESXi, Linux, Virtualization

Tagged with

Level Platforms install does it all, but must add MWService to admin groups

with 2 comments

Summary:
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.

Details:
Read the rest of this entry »

Written by scottledyard

2008, December 17th at 12:09 pm

Dell server needs virtualization enabled to install 64 bit Server 2008 in ESXi

leave a comment »

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
File: \windows\system32\boot\winload.exe
Status: 0xc000035a
Info: Attempting to load a 64-bit application, however this CPU is not compatible with 64-bit mode.

Windows 2008 Boot Manager reports error

Windows 2008 Boot Manager reports error

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.

Written by scottledyard

2008, October 7th at 7:30 am

%d bloggers like this: