What is the current technique for importing KVM VMs into Vcenter?

[wsanders11]

I can't find any recent documentation about importing exported KVM VMs into vCenter. I have tried once doing this:

Convert KVM vm to VMDK: qemu-img convert -p  -O vmdk /dev/vms/sandbox /srv/storage/sandbox.vmdk

Copy the file to an ESXi host with SCP.

Create a new VM using the copied VMDK file as the system disk.

The VM runs for a while but eventually throws massive ATA errors and locks up.

When the VM is restarted vCenter has made the VMDK read only and it is unusable.

Attempts to clone the VM hang.

Attempts to clone the VDK file with vmkfstools fail with:

vmkfstools -i /vmfs/volumes/vsanDatastore/ISOs/sandbox.vmdk -d thin /vmfs/volumes/vsanDatastore/ISOs/sandbox/vmdk

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/vsanDatastore/ISOs/sandbox.vmdk'...

Failed to clone disk: The system cannot find the file specified (25).

The only comprehensible and not too ancient description of the process I could find online was this: https://nowhere.dk/articles/moving-virtual-machines-from-kvm-to-esxi-6-0

Which covers converting what seem to be a KVM SCSI disk to something Vcenter can use. But no info about ATA.

The VM I am trying to move is running centOS 6.2 and the destination vCenter version is 6.5

It also contains the dubious advice, "Now open the newly created vmdk file in vi and change the line ddb.adapterType from ide to lsilogic" which is impossible since a VMDK is neither human readable nor small enough to open successfully in a text editor.

Has anyone successfully moved a ATA-based KVM VM to vCenter?

[TheBobkin]

Hello,

Have you tried using vCenter Converter?

vmware.com/products/converter.html

In that article they are not referring to the -flat.vmdk (which is the disk data and not human-readable), they are referring to the associated descriptor file (.vmdk) that points to the -flat.vmdk .

Bob

[wsanders11]

The converter is a Windows based tool and I do not have a windows licenses available. I have tried in in the past where I had access to a windows box and never got it to work, it either hung or created corrupt VMs. Maybe the current version is better, but I'll need to scrounge up a windows license.

I sort of understood the article was referring to a descriptor file but the qemu-img convert command produced only a very large vmdk file which I presume is a "-flat' file. The VM needs to be created separately, then the hard disk device uses this file in situ.

Update: After a half our or so some lock expired and I was able to clone the VM in vSphere. The cloned copy of the VM came up error-free. So it would appear the cloning process fixed up whatever device or path problems existed in the previous copy of the VM.

[TheBobkin]

Hello wsanders11,

vCenter Converter works for Linux boxes:

www.vmware.com/pdf/convsa_61_guide.pdf

How were you creating .vmdk descriptors for VMs?

I don't think it is possible to attach a -flat.vmdk to a VM directly and if it was then this could be the source of issues.

It's also possible that any .vmdk descriptor used/generated could have had incorrect sizing and/or attributes of the -flat and caused the corruption.

If cloning after appears to work, great, but do intensive FS checks to ensure this is the case.

Bob

[wsanders11]

Well, a non-flat VMDK file is just a disk-image (or used to be.) So you create a new VM and when you get to the step to configure the VM hardware you can use the "New Device" wizard to select "Existing Hard Disk".

I was surprised it worked, boot blocks and all, but it did except for the initial ATA errors.

[wsanders11]

In that PDF doc:

"You can install Converter Standalone components only on Windows operating systems."

[TheBobkin]

Hello wsanders11,

Yes, it is installed and run on a Windows machine and uses the Linux box as target and the VMFS datastore as target - please note the handy diagrams on page 11-12 of that document that illustrate how this works (also note the 69 times that 'Linux' is mentioned!):

"I do not end up with a large flat file and a small vmdk config file. I end up with a small vmdk config file that contains a reference to a VMFS file:"

That's because you are not cloning it to a -flat but a vSAN DOM_OBJECT , vSAN doesn't use -flats, .vmdk descriptors point to DOM_OBJECTs such as the Object here with UUID e911b759-a4fe-21cd-6d0a-0cc47ad3960a .

If you are not writing it to a vSAN datastore then something must be going awry with vmkfstools -i destination clone format (-w switch IIRC).

Bob

[vasan22in]

Have you tried this.?

https://www.starwindsoftware.com/converter

Migrating VMs from PF9 KVM to ESXi - EverythingShouldBeVirtual

https://possiblelossofprecision.net/?p=2293

[wsanders11]

That procedure doesn't work as described. I copy the vmdk from the kvm host and run "vmkfstools -i `pwd`/myvm-temp.vmdk -d thin myvm.vmdk" and I do not end up with a large flat file and a small vmdk config file. I end up with a small vmdk config file that contains a reference to a VMFS file:

# Extent description

RW 41943040 VMFS "vsan://e911b759-a4fe-21cd-6d0a-0cc47ad3960a"

As far as I can tell that object does not exist; importing the small vmdk config file results in a bad VM.

This procedure does not work either:

- Use the vmdk file brought over from qemu-img convert.

- Create a VM, delete the SCSI disk and SCSI controller, you are stuck using the vmware IDE driver.

- Use the  vmdk file brought over from qemu-img convert as your disk.

- Bad VM is result.

By "Bad VM" I mean a VM that won't even boot into BIOS, it just displays a message "Press any key to continue".