On Thu, 2021-07-29 at 09:04 +0000, Derek O keeffe 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?
no for two reasons. first cold and live migration are admin only so normal teants cannot use it. second whild its technially possibel to mix greate then n+1 version deltas in nova up to victoria or wallaby it may or may not work.
we only test n to n+1 queens to victoria is 5 releases.
you are very lucking in that you queens used version 5.0 of the comput erpc and victoria is 5.12 which means in theory you can pin to victoria to sue 5.0 and it might work.
https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L416-L4...
i not so long ago tested train -> wallaby pinning to 5.3 and it appeared to work but this is well in the depts of undefiend behavior land.
if you upgrade your nova contoler service to victoria and pin the RCP you __might__ be able to manage the queens compute suffently enought to have your admin manually migrate the vms form teh queens host to victoria host but i would not try to do it the other direction.
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.
i assume you care not willing or are unable to jsut do rolling update between the 5 release instead fo trying to skip strait form queens to victoria. that is the tested and supported way to do this.
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.
well your admins will have to move them whatever you decided to do since live migration is admin only unless you have used custom policy to alter that.
Any advice or info would be greatly appreciated. Thanks in advance.
so my main advice would be if you cant jus tdo back to back rulling upgrades keeping your vms active and in place then you need to do a lot of testing. on the neutron/cinder side you need to ensure all nodes use a singel release. nova can handel talking to newer or older neutron/cinder serivces but it cant handle talking to a mixed neutron or cinder well.
in queens neutron does not supprot multiple port binding in victoria it does. if you upgrade neutorn on the contoler to victoria but have the neutron l2 agent on the compute nodes still running queens the neutorn api will report support for multiple port bindings and nova will use the new live migration code path but the queens host wont have supprot for that. in this case you actully can live migrate to a victoria node but if anythign goes wrong it wont be able to revert as reactivignt the port binding on the souce node will fail.
so if your going to try and mix version like this you shoudl avoid mixing neutron verison. the same is likely ture of cinder, all of the openstack serice only offcially support n to n+1 upgrades so you want to avoid breaking that in all cases where you can avoid it. if you must do it for nova for some reason you should only upgrade the nova serices and leave the rest of the cloud on queens or upgrade everythin but nova to victoria fully.
even followign that advice its not guarentted to work
as i have said i have tested walably contolers with trian computes recently and i was able to live migrate from train to wallaby with a minor code chagne but that was with the simplest possibe vm with no cinder no cpu pinning or hugepages or any other complex features. i did break part of my advice by keeping the train version of neutorn l2 agent on the train comptue node but that was due to devstack limitations. you might be forced to do the same but the multiple port bidnings freature was added in rocky so in my case but side had it and it was not an issue for you your queens ndoes will not support ti but your victoria nodes will so if you upgrade neutorn on the contoler it will make live migraiton more risky as you wont be able to revert. the vm will have to be anually fix if the migration fails for any once it starts.
Derek