Import XenServer export into Scale cluster
-
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.
-
@Danp said in Import XenServer export into Scale cluster:
What formats does Scale natively support?
It is KVM/QEMU under the hood, and I believe it supports qcow2.
-
@travisdh1 said in Import XenServer export into Scale cluster:
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.
-
@Kelly said in Import XenServer export into Scale cluster:
@travisdh1 said in Import XenServer export into Scale cluster:
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!
-
@travisdh1 said in Import XenServer export into Scale cluster:
@Kelly said in Import XenServer export into Scale cluster:
@travisdh1 said in Import XenServer export into Scale cluster:
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.
-
@Kelly said in Import XenServer export into Scale cluster:
@travisdh1 said in Import XenServer export into Scale cluster:
@Kelly said in Import XenServer export into Scale cluster:
@travisdh1 said in Import XenServer export into Scale cluster:
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.
-
Would the Starwinds V2V converter work?
-
@Danp said in Import XenServer export into Scale cluster:
Would the Starwinds V2V converter work?
I should. I'll have to remember to try that one out sometime.
-
-
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 This is great. Thank you. Out of band support like this is part of what makes me more confident in my decision to invest in Scale.
-
@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:
![0_1492722750586_2017-04-20 15_11_32-[6] The Fellowship.png](https://i.imgur.com/AHxvy1A.png)
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?
-
@Danp said in Import XenServer export into Scale cluster:
Would the Starwinds V2V converter work?
Yes, we love migrating Hyper-V and VMware guys to Scale/HC clusters LOL.
P.S. Just make sure you'll enable VM patching as KVM and MSFT/VMV emulated hardware is different, first VM reboot in maintenance to update the hardware is required.
-
@Kelly may be worth a call / online chat or email with [email protected] so they can look at the logs...
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.
-
@davedemlow Support was able to get things sorted out. One of our issues was that the target for the import was a NAS running SunOS. Never could get that running.
Final steps:
- Exported VM (VM-E) from Xenserver
- Converted VM-E using Starwinds V2V converter to qcow2 format
- Created an import shell vm (VM-I) and exported it to the same location as the above converted exported VM-E
- Renamed export VM-E to match the guid of the VM-I
- Imported renamed VM-E into HC3 cluster
- Success
It is a bit convoluted, but it works. Thankfully I don't have to move too many VMs other wise this would be a very time intensive process.
-
@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)
