vCAC Agent Install ‘RepoUtil.exe’ Error

vcac-agent-errorLike many out there, I am upgrading my lab environment to the new vCloud Automation Center, since 5.2 was released. The installation process is a little different, and shows evidence of the transition from the old DynamicOps product to one more inline with the other vCloud Suite offerings.

I will write-up another post about the full installation of vCAC 5.2 in due course, but in the meantime this is a quick heads-up to make sure to read the requirements documents before completing the install.

vCould Automation Center 5.1 used to require DotNet 4.0 to be installed for Endpoint agents to run correctly. If you are in a lab environment and are happy to build and burn your existing vCAC deployment, then mostly an installation in situ will be fine for you. New database etc and installers are all vanilla.

However, installing the new agent on a Windows 2008 R2 server produced the following interesting error:

RepoUtil.exe has stopped working. A problem has caused the program to stop working correctly. Please close the program.

Further investigation into the Windows logs shows application calls to spurious and varied system DLL files – nothing useful immediately to ID the source of the issue.

Curious I thought. So, back I went to the documentation and read through the installation prerequisites. There I find that Dotnet 4.5 is required for vCAC 5.2.

If you install Dotnet 4.5 from Microsoft to your Windows instance, then re-run the Agent installer as administrator (per the manual) – then all should be well and the RepoUtil.exe error will not now present itself and prevent the install from succeeding.

VM Import: “Unsupported and/or invalid disk type 7″ errors….

Full error message from vCenter:

Failed to open disk scsi0:0: Unsupported and/or invalid disk type 7. Did you forget to import the disk first?Unable to create virtual SCSI device for scsi0:0,  Module DevicePowerOn power on failed.”

Came across another issue with importing and moving a VM into vSphere. The VM was created in Workstation 8 and was to be imported into vSphere to be used as a development VM.

Uploading the VM to the LUN worked fine, as did importing it to the vCenter Inventory. However, powering-on the VM resulted in the SCSI error type 7 message in vCenter.

Solution:

This can happen when importing a VM into vSphere, either from a backup or from another vSphere version. The solution is to re-import the source disk producing the error as ‘zeroedthick’ format.

Method:

1. Ensure you have SSH access to your ESXi server hosting your VM. (Host > Configuration > Software > Security Profile > Services > Properties > SSH = Running).

2. Use Putty to SSH to your ESXi host. Authenticate as the root user.

3. Move to the VM folder:

/vmfs/volumes/<datastore>/<vm-folder>

….where <datastore> is your LUN or NFS share and <vm-folder> is your VM container folder.

4. Use vmkfstools to convert the disk to zeroedthick:

vmkfstools -i mydisk.vmdk -d zeroedthick mydisk1.vmdk

5. Now go back to vCenter and browse the datastore hosting the VM. Both ‘mydisk.vmdk’ and ‘mydisk1.vmdk’ should be present.

(Optional: Download the original disk (if practical) to preserve in case of further issue.)

6. Remove mydisk.vmdk from the VM folder.

7. Rename ‘mydisk1.vmdk’ to ‘mydisk.vmdk’.

8. Power-on the VM and check for further errors in vCenter.

503 Errors and vCloud Director

In our lab set-up, I have been experimenting with vCloud Director configurations and high availability for vCloud Director cells – and more specifically what happens when the vCenters behind vCloud resources dissapear or have availability issues – then reconnect.

If a vCenter hosting the resources crashes and is subsequently restored, there may be odd or unexplained error codes from vCloud Director – specifically:

Unexpected Status Code: 503

…was seen a lot – when creating or deploying vApps within an Organisation that is backed by the resources managed by the vCenter that crashed. Interestingly, some vCloud functions continued to work whilst the continuity of vCenter was interupted, but this was due to the other resilient vCloud infrastructure (cells, database and AMPQ bus still responding).

The fix for these errors was to reconnect the vCenter server within the vCloud interface. It seems that simply allowing the vCenter to recover itself in sometimes not sufficient to allow the connectivity to recover automatically. To do this:

  1. Connect to the System vDC (the root or system Organisation for the cloud)
  2. Select the Administration tab
  3. From the left menu under vSphere resources, select vCenters
  4. Select the failed (and recovered) vCenter
  5. Right-click the vCenter and select ‘Reconnect’

A word or warning. While the reconnect operation only takes a very short time (a matter of seconds), this will affect other operations to the cloud consumers using resources from the effected vCenter, i.e. other errors may result from deploying or interacting with resources whilst the reconnect completes.

Fixing “HostDatastoreSystem.QueryVmfsDatastoreCreateOptions” Issue

Having recently made a right old mess of my home lab, I set about building it from scratch over the weekend. Having installed some nice, fresh builds of ESXi 5.0 I started adding in my SATA disks and began to create VMFS datastores on the hosts.

The first one worked ok. The second one didn’t for some reason. I got an error part way through the “Add Storage” wizard. The error stack wasn’t too helpful:

Call “HostDatastoreSystem.QueryVmfsDatastoreCreateOptions” for object “datastoreSystem-9″ on vCenter Server “svr-vcenter.vspecialist.co.uk” failed.

[Read more...]

Communication with the virtual machine may have been interrupted

I was trying to power up a new VM on an ESX 3.5 host just now and I got the following error:

“A general system error ocurred: The system returned an error. Communication with the virtual machine may have been interrupted”

Nice and helpful!

It appears that there are two ways to fix this. The first is to reboot your ESX host. Of course this isn’t normally practical and you may have VMs running. The alternative is to make your way into the service console and issue the following command:

service mgmt-vmware restart

Assuming that no errors are displayed as the service is restarted you should be sound as a pound (although these days the £ isn’t worth much).