Archive for December, 2010

Time settings/issues on ESXi 4.1

December 16, 2010 Leave a comment

Here are some short and sweet items that i discovered yesterday;

Interestingly, ESXi does not allow you to change the timezone, it is permanently set to UTC.

Also, If you setup an NTP server on your ESXi hosts and that NTP server goes away for some reason, the ESXi host will not revert to using its’ own clock or even continuing to make a valient effort of keeping time, it instead reverts to January 1, 0001, to say this creates some issues is simplifying it.  The ESX hosts complain about not being able to “synchronize”, which is the first clue you get about the issue.  When you try and manually set the date through the VI-Client, you get a bunch of errors when you try and do anything and then the VI-Client froze.  The only option i found was to get that NTP server online.

Note: It may have been possible to do it via powershell or cli commands, however i had needed to get the NTP servers online anyway, and once this occurred, the ESXi servers re-synced and was able to respond.

“Save Location of VMDK” Bug in Virtual Center

December 16, 2010 Leave a comment

So while doing a Proof of Concept test on a replication product for P2V, V2V and V2P scenarios a very interesting “bug” was encountered in Virtual Center that i’ve never encountered before.  We have to add .vmdk files that belong to VM “containers” to a “Master” VM.  So if you are protecting a SQL Server, you’ll have this “Master” VM’s .vmdk and the SQL VMs .vmdk attached to this VM.

The bug is this;

If you go and add another .vmdk to a VM, AFTER already choosing “attach an already existing vmdk” for a previously added vmdk, that new .vmdk will be created in the “already existing vmdk”s folder.

Since i’ve been working crazy hours, i’ll take a second to explain better.

So you have 2 VMs, they are named, “Master”, & “SQL”.  Each one is on a separate datastore in its’ own similarly named folder, which is default.  Then you go and add a 2nd vmdk to “Master” but choose to attach the vmdk from “SQL”.  Now you create another vmdk on the “Master”, however this is a new VMDK.  If you specify the location “store with the virtual machine”, it does not save the vmdk with the “Master” vmx, which is in the “Master” folder, instead it creates the new vmdk in the “SQL” folder.  This is quite interesting….

After digging around through the logs and doing some very quick testing, i found, what i believe, is the answer.  It seems that the “store with the virtual machine” is not actually returning with the location of the .vmx file, but actually returning with the location of last disk entry of the .vmx, so in this case “SQL”.

I would assume this is a simple fix by vmware, however since i have not encountered this before i’m wondering if i have just been lucky or if this is a new issue.

Categories: Uncategorized