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]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.
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
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.
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.
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.
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".
=========================================
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 !!