How Can I Convert My Existing Workloads to Run on Scale HC3
-
A: There are several options for converting existing workloads to run on HC3. For Windows and Linux VMs, Scale has partnered with Carbonite and their Double-Take product to offer HC3 Move which can be used to migrate physical (P2V) and virtual (V2V) workloads onto HC3. It requires near zero downtime and gives the user ultimate control of deciding when to cut over from their source machine onto the HC3 platform.
In addition to HC3 Move, any backup solution that supports full system bare metal recovery can be used to transfer workloads onto HC3. In some cases virtual machine formats like VMDK can be directly imported to HC3 from other hypervisors (Veeam Example).
For those users who would like assistance in the migration, Scale also offers services that can do everything from showing end users how to use the HC3 Move tool while performing a single migration (Quickstart service) to performing the entire migration in a full services engagement.
For more information on other Migration processes and troubleshooting, on the Scale customer or partner portal search for the following documents:
x2v concepts - P2V/V2V Concepts for the Scale HC3 Cluster
- General discussion of migration issues and troubleshooting
on partner portal or the on customer portal
on that page you will also find information on some additional tools including:
clonezilla - P2V and V2V Migrations with Clonezilla and HC3
- Free open source tool that can migrate existing physical and virtual machines into HC3 VMs
and
P2V/V2V with Acronis and the Scale HC3 Cluster
Other documents available include:
foreign vm import - Import a Foreign VM or Appliance into HC3 Using the HC3 Web Interface
- free way to directly import many offline virtual disk formats into HC3 - vmdk, vhd, ova
on partner portal
on customer portal
- General discussion of migration issues and troubleshooting
-
qemu-img is actually what HyperCore OS uses internally when it is doing both import and export of VM's to/from HC3. As a result, if you use the "foreign VM import" process referenced above, it leverages the fact that if you simply rename a vmdk for example to a qcow2 file extension (that HC3 expects) and then import it, qemu-img will actually detect that the disk contained in file is really a VMDK and do that conversion automatically for you saving a step!
One other benefit of letting HC3 do the conversion is that it will convert to the right qcow2 format for that HC3 version automatically. if you are doing the pre-conversion using qemu-img on windows (or linux for that matter), you may want to run the qemu-img info on an empty HC3 exported qcow to see what flags it has and try to match them. depending on the version of HC3 and version of qemu for windows you are using I have seen cases mostly with older versions of HC3 where you need to specify the compat version to match something like this:
qemu-img convert -p -O qcow2 -o preallocation=metadata,compat=0.10 source-image.qcow2 output-image.qcow2(this was an older version of HC3)
On a very new version of HC3 as of this post it looks like compat: 1.1. I got tired messing with stuff like that and the extra step so now I always start with renaming the virtual disk files to .qcow2 extension and try letting HC3 figure it out first at least which generally works. (VHDX may be the exception ... and of course you have to get into the "right" vmdk format in some cases as there are lots of different vmdk formats)
Another tip / FAQ - if you ever have a .OVA file, generally a virtual appliance, that is just a tar archive that you can expand and inside there will be a virtual disk file, usually .vmdk but sometimes .img format that you can convert/import into HC3 using the above processes.
Of course ALL of this is just getting HC3 to see the virtual disk. The OS on that virtual disk has to have the right drivers_ active_ to be able to boot on HC3 which either means that it has virtio drivers pre-installed and set to boot (if "performance" drivers are selected when creating the VM) or IDE drivers (if "compatible" drivers are selected ... and for windows mergeide.reg was run before migration.) Linux is generally just automatic but Windows will result in a 7B BSOD if a driver for the boot disk isn't active on the imported virtual disk.
