Migrating VM's

Sean Mooney smooney at redhat.com
Thu Jul 29 18:24:27 UTC 2021


On Thu, 2021-07-29 at 15:28 +0000, Jiri Stransky wrote:
> (re-sent from a correct address for openstack-discuss :) )
> 
> Hello Derek,
> 
> On Thu, Jul 29, 2021 at 9:08 AM Derek O keeffe <derekokeeffe85 at yahoo.ie> wrote:
> > 
> > Hi all,
> > 
> > I have a question. If we have an old openstack deployment (Queens) that have VM's (with & without volumes attached) and we want to migrate those to a new deploy (Victoria) can this be achieved by the owners of the VM's through horizon in some way?
> > 
> > We can take snapshots of the vm's that don't have volumes attached, copy them to the new controller and re instantiate them but we haven't found a solution for the volumes yet. This give us more work though as it all needs to be done over cli so the user is taken out of the loop and it falls on us 3 admins to move over 300 VM's.
> > 
> > Any advice or info would be greatly appreciated. Thanks in advance.
> 
> OS Migrate might be worth a look, it's an Ansible collection. It does
> cold migration that does not require admin privileges (is runnable by
> tenants who are sufficiently technically savvy).
> 

default nova policy requrie admin right for cold migration
https://github.com/openstack/nova/blob/master/nova/policies/migrate_server.py#L25-L36

os-migrate is not useing nova migration apis its migrating the data and vms behind novas back.



>  It can copy VMs with
> attached volumes. If boot disk copy is desired, then the destination
> instance will be created as boot-from-volume (the alternative option
> being re-imaging the instance from a pre-existing Glance image in the
> destination cloud, which is good for instances which store important
> data only in volumes, and can be rebuilt as in `openstack server
> rebuild`). Aside from migrating VMs, it should also help you migrate
> prerequisites for VMs, e.g. tenant networking resources or security
> groups.
> 
> Perhaps even if you end up doing the migration on behalf of tenants,
> at least you wouldn't have to do it fully by hand, and you'd have
> something for the migration of attached volumes.

os-migrate is a tool for moveing betweeen different cloud deployemnets isntead of doing a upgrade you deploy a parralel
cloud and then you use os-migrate to move workloads.

while that sound nice in practic it will break any automatin that site on top of openstack ans the workload will not
be moved to a new cloud so so if you have deployed yoru vms with heat or use an external VNFM you willl nolonger be abel to manage the vms.

os migrate will not be transparent to the enduser
for example there keystone project id and user id will change.
this is because keysotne does not allow you to choose a uuid when create user or projects
https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-user-detail#create-user
https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-project-detail#create-project

while some resouces can be recarted with the same external ids resouces like flaover obviously need admin privladges.
nova lso caches the version of the imave and flavor the server was booted with.

if you have modifed the flaovr or image extra spces since the vms were booted the vms that are create on the destination 
may be diffeente then the souce and that may or may not break the newly created vm.

so while it might be useful in limited cases you shoudl be aware the way it works is generally not supprotable in public cloud or by normal users
its a tool that a cloud operator can use.

as a reulst it is portentially more dangourous then just a normal upgades as its more like that the vm abi and resouce uuids will change.
im also not sure if it will work with ironic i suspect not.

it also cannot handel all resouces for all service for example it cannot tansfer octaivia loadblanceser, barbical secreats, swift objecst or trove db instance or heat stacks to name but a few
service that are not supported.

if you can live with those limitation then os-migrate might eb the tool for you but i would personally upgrade in place.
> 
> Here's an "executive summary" of how it works:
> 
> https://www.jistr.com/blog/2021-07-12-introduction-to-os-migrate/
> 
> And docs:
> 
> https://os-migrate.github.io/os-migrate/
> 
> 
> Have a good day,
> 
> Jirka
> 
> 





More information about the openstack-discuss mailing list