Just looking through that script quick, all you should have to do is convert the disk image from .ovf to .qcow2. A number of ways exist to get this done, I've used qemu-img and VBoxManage to accomplish the conversion. After that, you should be able to import the disk image.

Note: You need to decompress and/or untar the ovf file first.

I don't have access to that sweet, sweet Scale hardware, so can only give generic help.

Just looking through that script quick, all you should have to do is convert the disk image from .ovf to .qcow2. A number of ways exist to get this done, I've used qemu-img and VBoxManage to accomplish the conversion. After that, you should be able to import the disk image.

Note: You need to decompress and/or untar the ovf file first.

I don't have access to that sweet, sweet Scale hardware, so can only give generic help.

Just looking through that script quick, all you should have to do is convert the disk image from .ovf to .qcow2. A number of ways exist to get this done, I've used qemu-img and VBoxManage to accomplish the conversion. After that, you should be able to import the disk image.

Note: You need to decompress and/or untar the ovf file first.

I don't have access to that sweet, sweet Scale hardware, so can only give generic help.

Hmm, I'll give this a shot.

Being that it's coming from XenServer, you might just have to extract the drive image from the .ovf and import that. Would make the process quick and easy!

Just looking through that script quick, all you should have to do is convert the disk image from .ovf to .qcow2. A number of ways exist to get this done, I've used qemu-img and VBoxManage to accomplish the conversion. After that, you should be able to import the disk image.

Note: You need to decompress and/or untar the ovf file first.

I don't have access to that sweet, sweet Scale hardware, so can only give generic help.

Hmm, I'll give this a shot.

Being that it's coming from XenServer, you might just have to extract the drive image from the .ovf and import that. Would make the process quick and easy!

Just looking through that script quick, all you should have to do is convert the disk image from .ovf to .qcow2. A number of ways exist to get this done, I've used qemu-img and VBoxManage to accomplish the conversion. After that, you should be able to import the disk image.

Note: You need to decompress and/or untar the ovf file first.

I don't have access to that sweet, sweet Scale hardware, so can only give generic help.

Hmm, I'll give this a shot.

Being that it's coming from XenServer, you might just have to extract the drive image from the .ovf and import that. Would make the process quick and easy!

I didn't package anything, so the ovf file is separate from the vhd.

Ah, vhd, yeah, just convert the vhd to qcow2 then. I was forgetting what XenServer uses as the default disk image type.

This is one of those questions where there are so many ways to accomplish this it's tough to answer... so while HC3 Move powered by Double-Take is the easiest, lowest downtime and fully supported by Scale technical support way to migrate workloads onto HC3 there are other ways you can try... given you mentioned Double-Take, I assume this is a windows VM you are trying to move.

one option - us a full system backup / bare metal recovery tool. Backup the VM on xenserver, do a bare metal restore of that VM into an empty HC3 VM. Just need a tool that can restore to different hardware and "inject" the right drivers... Acronis, storagecraft, unitrends, veeam endpoint backup, barracuda, many others can do that.

Clonezilla is another option that is free - but it doesn't do anything with the driver differences inside the VM (so there are some extra steps to prepare the VM to boot using it's built in ide drivers - run mergeide.reg first ... then "clone" to a hc3 VM set to compatible instead of virtio to do the migration... you can switch to virtio later)

Lastly - there was some discussion about converting the old virtual disk (VHD?) to qcow2 and using our import feature (which is intended for exporting and importing VM's from/to HC3)... well, a little undocumented "hint" you can try is that if you simply rename the VHD file to QCOW2, our import process generally can do the disk format conversion automatically. I want to state this is not a fully tested / supported feature but it "generally" works and may be worth a try... (also you need to make sure that windows inside the VHD file has the correct drivers installed / active to be able to boot properly on HC3)

on our support portal, try searching for "Import Foreign VM or Appliances" clonezilla and mergeide.reg for more information.

Hope that helps point you in the right direction.

(note: I couldn't find a way to upload docs here and the URL's for them are behind login)

@davedemlow New question for you. I'm trying to get the cluster to pull in the qcow2 file. I provide it with the information requested in the window, and I get the error below:

I have checked the URI on the node via smbclient and name resolution is working and it can enumerate the shares. The response appears to be too fast to have done any authentication, but that is purely subjective. I have provided it with valid domain credentials. I have tried both a share on my NAS and one on my local Win10 workstation. Any thoughts?

are you sure you have the full share and folder path specified? from your screen shot it looks like something may be missing... normally it should be somthing like smb://server/share/folder/

(in my screen below the share is /exports and the folder I'm importing from is /EmptyImportShell which I created doing a VM export to the /exports share previously ... in that /EmptyImportshell folder is a file called EmptyImportShell.xml which has all the metadata about the VM and one qcow2 file which in this case happens to be 93dfb769-5ccd-49af-90c6-dd464b03536d.qcow2 ... but it's a guid so your file name will be different)

But as a test, if you haven't already can you create a small "template" VM with 1 small virtual disk (don't even have to boot it) and try to export it to that same server / share / credentials to validate that the export works ... and that you can import it back in as a test.

If you can export that empty shell and then test import it back ... that should at least confirm all the permissions, paths, etc. are correct... then you can even use that empty template to replace the virtual disk file with the virtual disk you want to import ... just replace it but keep the name and extension the same and give it a go.

@Kelly yeah the HC3 Move (powered by Double-Take) is certainly easier and more direct...

if the xenserver export virtual disk file is a VHD file, you can probably skip converting it to qcow2 but simply renaming the file to match the guid of the exported empty qcow2 file (so it will still be named <guid>.qcow2 even though it's actually your VHD file.) Our import is actually using the qemu-img convert tool which will automagically detect that it's really a VHD format and do the conversion at the same time it imports it to save that extra step. (and also you can use that same "import shell" over and over... just keep replacing the guid.qcow2 file with the one you want to import)