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 !!