Determine which ESXi Host has a .vmdk file locked

I was trying to remove some dead files left over from failed P2V attempts on an ESXi 5.0 host.  The question I have is which host has the file locked, I don’t want to reboot more than is necessary.  I am using iSCSI targets, and this command gives you a list of which Mac address has a file locked

vmkfstools –D /vmfs/volumes/<UUID>/<VMDIR>/<LOCKEDFILE.xxx>

I was able to get output that had this in it:

Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Lock [type 10c00001 offset 13058048 v 20, hb offset 3499520
Hostname vmkernel: gen 532, mode 1, owner 45feb537-9c52009b-e812- 00137266e200 mtime 1174669462]

Therefore the offending Mac address is :00:13:72:66:E2:00

I opened my vSphere client and found the offending nic in my  Configuration/Network Adapters by traversing each suspect host.

After rebooting that host, the file lock is gone.

Credit to this article from VMW http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051

Migrate VM from VMware Server 2 to vSphere ESXi 5

I tried to migrate an offline VM from Server 2 to ESX 5, in the process I kept getting what seemed to be a snapshot error on a VM without snapshots.  The VM would successfully migrate and then give this error on power up, or during the P2V Converter if I chose to remove snapshots.

“The parent virtual disk has been modified since the child was created.  The content ID of the parent virtual disk does not match the corresponding parent content ID in the child.”

I tried about 7 times unsuccessfully to migrate the VM, then a friend suggested I modify the defaults of the P2V and choose HW version 7 instead of HW version 8, and this time it succeeded.

Storage Path Selection Policy Choices

First we must talk about ALUA, it stands for “Asymmetric Logical Unit Access”, which is a feature on some mid range storage devices, (such as a Clariion) that will allow it to emulate a higher end array running Active/Active Storage Processors.  Each SP still owns the LUNS, but with ALUA, an SP can process data for the other one via the backplane in the chassis.

Keep in mind:

VMware Defaults are MRU for Active/Passive & Fixed for Active/Active

MRU never falls back automatically

Always ignore my advice and follow storage vendor best practices

Great place to find recommendations of what to use on your SAN

I am assuming your not using a 3rd party PSP, SATP or MPP, such as EMC Powerpath/VE (those are generally the best option if available)

 

Active/Passive (think EMC CX3 without ALUA)

Fixed = Not a great choice but will work.  Fixed will cause you to micro manage the ESX hosts to ensure that all hosts are on the same path.  If a host has a path fail and causes it to fail over to the 'non-preferred' path this will cause trashing with the remaining hosts possibly leading to downtime.

MRU = Best practice and a good choice, this will allow the storage array to set all ESX hosts to the proper path and eliminate LUN trashing or trespassing of the LUNs; all hosts in the cluster should be set this way. 

RR = Do not use, will cause trashing, data corruption and other issues.

Emulated Active/Active Mid Range Storage with ALUA Enabled, such as CX4 Clariion

Fixed = Decent Choice if you’re a control freak or have FC I/O bottlenecks.

MRU = Best Practice, vSphere 4 is aware of ALUA, this will allow the storage array to set all ESX hosts to the proper path and eliminate LUN trashing or trespassing of the LUNs; all hosts in the cluster should be set this way. Just make sure to balance the I/O among your SP’s.

RR = Works, but can cause excessive use of the backplane

Real Active/Active Higher End Storage such as Symmetrix

Fixed = Probably your best option,  will require each host and LUN to be set to opposite paths; and will require micro-management of the storage infrastructure.

MRU = Works, but probably not your best option, does not load balance traffic, could force all traffic to one HBA

RR = Easiest option as long as the SAN is dedicated to the vCenter, if not, perhaps Fixed is your best option

Setting up Sysprep for vCloud

Before Cloud Director can perform guest customization on virtual machines with pre-vista Windows guest operating systems, you must create a Microsoft Sysprep deployment package on each Cloud cell in your installation.

Procedure
1 Copy the Sysprep binary files for each operating system to a convenient location on a Cloud Director server host, such as /root/sysprep
Each operating system requires its own folder, MAKE SURE you use lower case for each folder, i.e. win2000 not Win2000.

Windows 2000 SysprepBinariesDirectory /win2000
Windows 2003 (32-bit) SysprepBinariesDirectory /win2k3
Windows 2003 (64-bit) SysprepBinariesDirectory /win2k3_64
Windows XP (32-bit) SysprepBinariesDirectory /winxp
Windows XP (64-bit) SysprepBinariesDirectory /winxp_64
SysprepBinariesDirectory represents a location you choose to which to copy the binaries.

Guest OS Copy Destination
1) stop the vcd services,  service vmware-vcd stop

2 Run the /opt/vmware/vcloud director/deploymentPackageCreator/createSysprepPackage.sh
SysprepBinariesDirectory command.
For example, /opt/vmware/vcloud-director/deploymentPackageCreator/createSysprepPackage.sh
/root/sysprep
3 Use the service vmware-vcd restart command to restart the Cloud cell.

Installing Windows XP in the cloud (VMware vCloud Director)

The first thing you’ll notice in the XP install is that it doesn’t see the default vCloud provided hard drive.  Normally in vSphere, you can mount the Floppy drive with the image on ESX.  In vCloud, assuming you don’t have vSphere console access, you’ll need to copy the file from one of your ESX hosts to your local hard drive, the upload it to the cloud.   You’ll need to use a program such as WinSCP and grab the file from the ESX(i) host /vmimages/floppies/vmscsi.flp.  Once inside of vCloud Directory, go into your Catalogs/Media tab and upload the floppy image.  Assuming you’ve already uploaded your XP ISO into vCloud, mount them both and install away.

Lab Manager API deployment issue

Spent the last few days troubleshooting an issue, initially, we thought it might be a fenced vs. unfenced configuration conflict, but when users try to deploy Lab Manager environments from the API tool we wrote in house, the following error was generated:

=========================================

Unable to deploy virtual machines in resource pool "LBM4".

• DRS failed to find hosts to deploy the virtual machines on the resource pool "resgroup-32975".
• DRS failed to find host for virtual machine "049104-DC". vCenter reported: This operation would violate a virtual machine affinity/anti-affinity rule.
• Unable to find host for virtual machine "RuleViolation".
• DRS failed to find host for virtual machine "049105-VCM". vCenter reported: This operation would violate a virtual machine affinity/anti-affinity rule.
• Unable to find host for virtual machine "RuleViolation".
• etc…..

=========================================

Since verything worked great from the Lab Manager UI, we knew it must be an API issue, it turns out the answer was that the old script from the Lab Manager 3 days was using the “Do Not Span Hosts” option.

Of course you want to span hosts in Lab Manager 4 !!

vCloud User and Resource Organization

I’ve been struggling with understanding how PvDC’s(Provider vDC), Org vDC’s(Organization vDC), Organizations all relate inside of vCD.  I drew up a graphic that helps me understand, hope it helps you as well.

Click the picture for a full size graphic.  Thanks to our resident vCloud expert @tomralph for helping me understand