VM Migration To New Hardware with OpenStack
Sean Mooney
smooney at redhat.com
Mon Jul 19 11:43:43 UTC 2021
On Mon, 2021-07-19 at 15:27 +0800, Tony Pearce wrote:
> Hi Kris,
>
> I run RHV. RHV is basically oVirt (open source). Once you have the qcow
> exported from RHV, you can import this into Openstack as an image and
> deploy it there.
>
simply uploading the qcow to glace woudl work but you will end up witha large number of images that you dont want to keep for ever.
its more work but what i would proably do it temporaly upload them to glance and then create volumes form those images
then boot the vms form the cinder volumes and delete the image.
if you are using ceph then this wont actully help so ignore it in that case and just boot directly form the image but typically you do not
want to have 100+ imnages that are efectivly just snapshots for the vm living forever if for no other reason then it will double your storage needs.
in general however import vms is not trival to do because you will have to create networks, ports router ectra.
while it would be posible in many case to create the vms with the same mac and ip adress if you manually create the neutron ports and networks
there is a lot of work to do if you want to make it look transparent to the vm when you're done beyond just copying the vm disk.
100 vms is actully relitvily small.
in generall i would recommend considering not migrating them but in stead redeploy new vms and transferihng any
data you need to preserve instead.
for example deploy a new windows vm with the ERP application you mentioned in your previous mail on the openstack cloud.
then log into the old vm do a backup of the database and files used by the erp applicaiotn and then do a restore on the new vm.
depending on your current workload i would expect that you have some level of backups/restore capablity for them so in prinicpal
this could be an alternitive stragy to importing the raw qcow files.
> I'd suggest that you can deploy oVirt in a single machine
> and run some tests from there.
> Most of my VMs on RHV I run with a single disk for simplicity reasons
> mostly. What confuses me about your mail is that you have a Windows VM with
> /lv and /boot and these sound like unix partitions. Maybe the /boot qcow is
> where the boot loader resides.. no idea.
>
> If you can deploy ovirt then you can deploy a windows VM on a single disk
> then export this and import to Openstack to get familiar which is what I
> would do in that situation.
>
> Tip; On any of your disk images you can use `qemu-img info filename.qcow`
> to get information about the disk image, such as format and size in case it
> helps. You can also convert this data (such as converting to VHD for Azure)
> (I am just mentioning this as an FYI).
>
> You probably wont "combine" those files but instead, you would create a VM
> "profile" that has those three disks. I expect that the vendor was running
> a VM in RHV with three disks so this is what they have sent to you.
you cant really create a vm with a "profile" that has 3 disk. that not really a concept in openstack
vm flavors can have additon ephemeral disks but you canot provide deata for those disk to the only
way to boot with 3 disks that have data woudl be to create cinder volumes.
> >They handed over three qcow2 files for this VM as follows.
> >
> > 1. First file is OS image as qcow2
> >
> > 2. /boot as another qcow2 image
> >
> > 3. /lv-datat as another qcow2 image
> >
so waht you likely would do in openstack would be to replace 1 and 2 with a generic os image (windows server...) and convert 3 to a cinder data volume
from that layout it looks like they were using 1 disk per pattition.
while its unusual for windows to have a seperate boot partion it is possibel for the boot loader to be at least partly installed on a seperate partion.
its much more common to just have a small C:\ partion and install user applciation and data on a seperate D:\ partions which is what i would expect the /lv/datat to be.
i wonder if /boot is actully a uefi bios image or simialr rather then a boot partition. in any case the only way to really boot with all 3 disk woudl be to use
cinder volumes but in the long run i think doing an aplication level backup and restore is proably better then trying to import the images.
>
> HTH
>
> Regards,
>
>
> Tony Pearce
>
>
> On Mon, 19 Jul 2021 at 13:26, KK CHN <kkchn.in at gmail.com> wrote:
>
> >
> > QUERY Section A:
> >
> > We are in the process of migrating VMs from a Vendor to OpenStack .
> >
> > The Vendor has hosted the VMs using RedHat Virtualization and HyperV
> > around 100 VMs. Each VM size varies from 50 GB to 150 GB size.
> >
> >
> > What is the best way to migrate these VMs to New Hardware infra Installed
> > with OpenStack Ussuri.
> >
> > What need to be done at the existing live VMs with the Vendor and in what
> > file format we have to ask the vendor to give the snapshot of VMs to be
> > migrated ?
> >
> > I am new to the migration of VMs from a live production setup ( the
> > present Vendor deployed VMs with all aplications running on the VM with
> > HyperV and RedeHat KVM. )
> >
> > We are also using KVM hypervisor.
> >
> > Kindly advise and direct me with all good practices followed to perform
> > this migration from existing vendor to our own setup with OpenStack and
> > KVM.
> >
> > Pls shed some light on this.
> >
> > QUERY SECTION B
> >
> > Another question below
> >
> > ffor a trail the existing vendor has given a demo VM, which is a
> > Windows VM with an ERP application hosted on it . But the vendor handed
> > over three files of single VM , Three qcow2 files.
> >
> > They handed over three qcow2 files for this VM as follows.
> >
> > 1. First file is OS image as qcow2
> >
> > 2. /boot as another qcow2 image
> >
> > 3. /lv-datat as another qcow2 image
> >
> > How to combine these files and we can create a Running VM from these
> > files and put it on bare metal installed with KVM only. Is this
> > possible ? How ? What need to take care while doing this operation?.
> >
> > your hints and direcitons highly appreciated.
> >
> > Thanks in Advance,
> > Kris
> >
More information about the openstack-discuss
mailing list