| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-10 | |||
| 15:46:54 | stephenfin | Thanks :) | |
| 17:44:59 | openstackgerrit | Merged openstack/nova stable/rocky: objects: Update keypairs when saving an instance https://review.opendev.org/743268 | |
| 23:51:52 | openstackgerrit | sean mooney proposed openstack/nova master: Deprecate filters that have been replaced by placement filters https://review.opendev.org/745605 | |
| #openstack-nova - 2020-08-11 | |||
| 01:43:44 | ayoung | Dumb idea time. Say I wanted to live migrate a VM from one openstack instance to another, across cluster boundaries. Would this be at all feasable? | |
| 02:23:24 | sean-k-mooney | ayoung: only by using libvirt directly and then manuly updating the db | |
| 02:23:36 | sean-k-mooney | ayoung: in other words no not really | |
| 02:23:46 | sean-k-mooney | ayoung: not in any way that would be supportable by nova | |
| 02:25:37 | ayoung | Of course it would be horrible. But so is leaving a cluster in place because it has key workloads. | |
| 02:26:35 | ayoung | So, yeah, diret libvirt would be necessary, and the receiving cluster would need to be able to take that running VM and make a database entry for it. On the old host, you would need to finish the migration and then set the VM into a non-runnable mode, too. | |
| 02:26:58 | sean-k-mooney | the eaiser approch would be to snapshot the vms and then copy the images and restore them on another cloud | |
| 02:27:01 | ayoung | So, say I needed to do something like this to migrate ahead to Victoria | |
| 02:27:14 | ayoung | Yeah, but that means downtime, right? | |
| 02:27:27 | ayoung | We can snapshot and restore today | |
| 02:27:57 | sean-k-mooney | the live snapshot would not but you would hten need to restore the snapshot (createing a second instance of the applcaiotn) and somehow sync there state | |
| 02:28:05 | ayoung | openstack vm --steal <source> | |
| 02:28:46 | sean-k-mooney | if you looking for a solution before the end of they year it will need to be somethign you develop your self unfortuntely | |
| 02:28:56 | sean-k-mooney | what versions are you dealing with | |
| 02:29:10 | sean-k-mooney | is it n to n+1 or multiple versions | |
| 02:29:19 | ayoung | Oh, old stuff by your standards. OSP 16 is...Train? | |
| 02:29:23 | ayoung | I' | |
| 02:29:36 | sean-k-mooney | ayoung: do you work for redhat | |
| 02:29:45 | ayoung | I'm really more interested in being able to talk someone thriough waht it would take and why it is a bad idea | |
| 02:29:59 | ayoung | Yep, I work for Red Hat. I used to be Keystone core, but now I see stuff.... | |
| 02:30:03 | ayoung | sell stuff | |
| 02:30:13 | sean-k-mooney | well its a bad idea in general because you cant assume two openstack clouds are using the same hypervior | |
| 02:30:21 | sean-k-mooney | one could be libvirt and the other vmware | |
| 02:30:27 | sean-k-mooney | in which case you cant live migrate | |
| 02:30:46 | sean-k-mooney | ayoung: ah ok im in the compute dfg | |
| 02:30:55 | ayoung | Nah, that is not a problem. We know it is all libvirt when we are talking about this. People have old clusters...I have one on RDO Liberty.... | |
| 02:31:17 | sean-k-mooney | yes so there is the paralle cloud migration work that is being done | |
| 02:31:50 | ayoung | I suspect that even the live migrationm would not make them happy, but I need to be able to talk it through. I suspect that the payloads would not suffer the cloud split anyway. | |
| 02:31:54 | sean-k-mooney | that works by runing basicaly a proxy vm on each cloud that can acess the hosts running the vms then it somehow orchestrates the migration betwen the clouds | |
| 02:32:10 | ayoung | So migrate from Nova to proxy and then from Proxy to new cloud? | |
| 02:32:30 | ayoung | Ah, proxy VM, not proxy host | |
| 02:32:41 | sean-k-mooney | i think how its ment to work is the first recreate the flavors network imaves on the new cloud | |
| 02:32:50 | sean-k-mooney | both a new vm on the new cloud with thos imnages | |
| 02:33:05 | sean-k-mooney | then migrate the runing instnce form one cloud to the prepared vm on the new cloud | |
| 02:33:10 | sean-k-mooney | something like that | |
| 02:33:17 | ayoung | So the proxy is smart enough to "trick" the old and new Novas that all is well | |
| 02:33:43 | sean-k-mooney | i think the plan is to recreate the resouces on the new cloud with the same uuid/flavors ectra | |
| 02:33:49 | sean-k-mooney | e.g. spin up a nova managed vm | |
| 02:34:02 | sean-k-mooney | then swap out the root disk ectra using a migration | |
| 02:34:14 | sean-k-mooney | its totally a hack but its one thing that people are looking at | |
| 02:34:36 | ayoung | So it is not a completely crazy idea, but it requires a substantial amoung of work to make it stable. | |
| 02:34:36 | sean-k-mooney | the proxy just provides connectivity between the cloud i think | |
| 02:34:52 | sean-k-mooney | oh its crazy i would never use it in production or recommend it to customer | |
| 02:35:04 | sean-k-mooney | that does not mean that marketing dont like it and want to sell it | |
| 02:35:20 | sean-k-mooney | and there are people working on maiking it work | |
| 02:35:53 | sean-k-mooney | just because its a crazy idea does not mean its a worse idea then doing FFU form libverty to train | |
| 02:36:20 | sean-k-mooney | if your on osp 7 still it makes sense in a strange way | |
| 02:36:25 | ayoung | mind if I use " oh its crazy i would never use it in production or recommend it to customer" in my next deck? | |
| 02:37:13 | sean-k-mooney | i mean you can if you want | |
| 02:37:15 | ayoung | I am sure some sick bastid somewhere got live migration from vmware to libirt (or the reverse) working | |
| 02:37:30 | sean-k-mooney | its not something the compoent teams are currently plannign on supporting | |
| 02:37:52 | sean-k-mooney | it being developl by the upgrades dfg with input form the feild teams and support | |
| 02:38:13 | sean-k-mooney | vmware proablyt have the reverse working | |
| 02:38:30 | sean-k-mooney | ayoung: but realistitly its very unlikely | |
| 02:38:44 | sean-k-mooney | the virtual devices are completely differnt | |
| 02:39:03 | ayoung | I was actually thinking through the steps required for oVirt to Kubevirt and realized it was the same kind of problem | |
| 02:39:35 | sean-k-mooney | yes althoguh in that case i think there is less state to recreate | |
| 02:39:44 | ayoung | What makes that one interesting is that it is possibly a migration to the same hardware, but a different libvirst (in a container) | |
| 02:40:19 | sean-k-mooney | in both ovirt and kubevirt there isnt realy and nic state to recreate and if you are uing an external storage solution you can proably jsut reuse it since kubvirt allow much more acess to the xml | |
| 02:40:53 | sean-k-mooney | ayoung: i mean technically you can do that with openstack too | |
| 02:41:20 | ayoung | Right. Hence me being here and asking the question of people I trust to have the basis for answering. | |
| 02:42:03 | ayoung | The real question is if you could set up a system to do that, and to make it work with old deployments. | |
| 02:42:23 | ayoung | Like RDO liberty to OSP 17 | |
| 02:42:35 | sean-k-mooney | ayoung: https://www.redhat.com/en/blog/migrating-openstack-platform-13-openstack-platform-16-os-migrate | |
| 02:43:18 | ayoung | Never show stuff like that to sales.... | |
| 02:43:26 | sean-k-mooney | https://github.com/os-migrate/os-migrate | |
| 02:43:42 | sean-k-mooney | ayoung: its now offically a supported part of the product starting in 16.1 | |
| 02:44:01 | sean-k-mooney | it might be tech preview | |
| 02:44:21 | sean-k-mooney | im also not sure if it live or cold migration | |
| 02:44:57 | sean-k-mooney | Shut down the instances that are going to be migrated. Currently this OpenStack to OpenStack migration solution only supports cold migration. | |
| 02:45:02 | sean-k-mooney | so ya cold right now | |
| 02:45:45 | sean-k-mooney | if you know it was libvirt or osp on both end | |
| 02:45:55 | sean-k-mooney | you proably could make live migration work too eventurally | |
| 02:46:16 | ayoung | Like OSP 13 to 16 ... | |
| 02:46:19 | sean-k-mooney | this really isnt something supportable upstream in nova. | |
| 02:46:33 | sean-k-mooney | ayoung: its intended for moving fom 13 to 16 yes | |
| 02:46:41 | sean-k-mooney | as an alterniivte to an inplace update | |
| 02:46:46 | ayoung | I actually have just that use case.... | |
| 02:46:57 | sean-k-mooney | just deploy a second cloud the cold migrate the workloads | |
| 02:48:48 | sean-k-mooney | anyway its almost 4am here and i was just checking a few thing on my laptop when i work up so im going back to bed o/ | |
| 02:49:04 | ayoung | OK, thank you for all this. It might be very useful, if only to drive discussions. | |
| 08:56:22 | luyao | stephenfin, alex_xu: thanks for review, I updated and split the patch. https://review.opendev.org/#/c/714653/ | |
| 10:08:11 | lyarwood | jsuchome: apologies for not getting back to you yesterday | |
| 10:08:23 | lyarwood | jsuchome: I still wanted to write up a job that would actually exercise this | |
| 10:08:33 | lyarwood | jsuchome: the job I posted previously did not | |
| 10:08:49 | lyarwood | jsuchome: I'll try to find some time this week but I'm fighting a few fires downstream at the moment | |
| 10:28:22 | jsuchome | lyarwood: thanks, I was afraid I scared you away :-) | |
| 11:36:27 | openstackgerrit | Alex Deiter proposed openstack/nova master: Detach is broken for multi-attached fs-based volumes https://review.opendev.org/741712 | |
| 13:26:14 | openstackgerrit | sean mooney proposed openstack/nova master: Remove deprecated scheduler filters https://review.opendev.org/744800 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: compute: Add more type hints for resize functions https://review.opendev.org/745675 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: manager: Move context manager up one level https://review.opendev.org/745674 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: compute: Add type hints for resize functions https://review.opendev.org/745341 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/744958 | |
| 13:38:22 | openstack | bug 1879878 in OpenStack Compute (nova) "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Medium,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Add reproducer for bug #1879878 https://review.opendev.org/744950 | |
| 15:15:49 | sean-k-mooney | stephenfin: lyarwood can i get some priority review on https://review.opendev.org/#/c/738432/ | |
| 15:16:13 | sean-k-mooney | i want to get that backported sooner rather then later | |