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).