“Save Location of VMDK” Bug in Virtual Center

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.

Why the 2TB Limit in ESX 4.1

So i was asked this question by a collegue of mine.  “Why is there still a 2TB size limit to a LUN in ESX”.   The argument was that in this day and age, and with ESX now running on a 64-bit kernel, why are we still ham-strung by this limitation?  After some consideration and thinking it was thought that maybe VMFS was the issue, but it can’t be because you can create extents and one big VMFS volume.

Well the answer is that ESX (& ESXi) are still using the SCSI-2 Standards. Yes the same SCSI-2 that was from ~1995.  The ultimate issue has to do with the way the standard addresses the “READ_CAPACITY” of the LUN.  It uses a 10-byte call for the capacity, which limits the return to a 32-bit number. (It actually is just under a 32-bit number, the last value of 0xffffffff is acutally reserved, and thus can’t be used.  This limits you to 2199023255040 bytes, which is just under the 2TB limit.

The only current work-around is extents, which are much less then ideal.

So until VMware decides to update their outdated storage methodology, we’re stuck with the 2TB limit.

Lack of Posts

Well i know i was supossed to start writing more, but things have been nuts between rebuilding our lab at work and my home life i haven’t had time.

I’m going to list my upcoming topics so that maybe i actually remember to write them….

iSCSI vs NFS Testing results on ESX 4.1

Discovery of correlation between vCPU count and VMFS write speed

Properly enabling iSCSI and connecting targets in RHEL 5

DataDomain and BOOST

My PrivateCloud Lab

Discovered issues with vCenter as a VM and running dvSwitches