| *** hemna3 is now known as hemna | 07:37 | |
| EugenMayer | is it possible to move an instance from one ability zone to a other? | 14:35 |
|---|---|---|
| artom | EugenMayer, through unshelve, yeah: https://docs.openstack.org/api-ref/compute/?expanded=unshelve-restore-shelved-server-unshelve-action-detail#unshelve-restore-shelved-server-unshelve-action | 14:48 |
| artom | And as of API 2.77 | 14:48 |
| EugenMayer | reading https://support.platform9.com/hc/en-us/articles/360046450633-Can-I-Live-Migrate-an-Instance-Across-Availability-Zones- right now | 14:48 |
| EugenMayer | seems like --force is no longer available? | 14:48 |
| artom | You can also force with live migration and an old microversion, yeah | 14:48 |
| artom | "Prior to microversion 2.30, specifying a host will bypass validation by the scheduler, which could result in failures to actually migrate the instance to the specified host" | 14:49 |
| artom | So you can live-migrate with 2.29 and the `host` argument | 14:49 |
| EugenMayer | ok i have xena, that will not work. Is shelve to understood as i understand shelve in SCM tasks? Temporary stash away, get back? But basically that is nothing else then a glance op backing up the image, and then restoring it? | 14:50 |
| EugenMayer | so shelve is somewhat a shortcut to backup / restore with a special image creating step and maybe a little more semantic - but technically glance image, then restore? | 14:51 |
| artom | EugenMayer, you can use any older microversion with any newer cloud by passing --os-compute-api-microversion on the command line, so that's not the problem | 14:51 |
| artom | The problem is that if you force a live migration to a host, you can end up with inconsistencies between what's in the database (request spec, specifically) and where the instance is actually running | 14:52 |
| artom | Which could break future operations on it | 14:52 |
| EugenMayer | artom ah yes, i could. What would you advice? Rather shelve unshelve? shelve would take 2x as long AFAIU since it will write to glance and read from there, why live is direct compute to compute, right? | 14:52 |
| artom | EugenMayer, but to answer your question, yeah, your understanding of shelve is essentially correct | 14:52 |
| artom | EugenMayer, forcing hosts with live migration is asking for trouble, do it in the properly supported way with shelve/unshelve | 14:53 |
| lyarwood | EugenMayer: if you're using rbd as a backend it shouldn't take that long | 14:53 |
| EugenMayer | i see. i just see that shelv is just creating an image in glance with -shelve as suffix | 14:53 |
| EugenMayer | lyarwood: for me it's long due to the way i run glance (and where) but i guess that is just my burden. I think i can take the hit with the downtime without bigger issues. | 14:54 |
| EugenMayer | A little comment on the part with the live migration, am i understanding it right that it would happen compute to compute, not going over glance? | 14:54 |
| artom | Correct | 14:55 |
| EugenMayer | oh damn, shelve in the GUI is non interactive, it just uses the old host. Hehe, onde again i guess :) | 14:55 |
| EugenMayer | artom and lyarwood - thank you for your insight! Super helpful. | 14:56 |
| artom | lyarwood, since you seem to be about - did you put up any code for ephemeral disk encryption, btw? I read through the spec, was looking to read through the patches | 14:58 |
| lyarwood | artom: https://review.opendev.org/q/topic:%22change-760456-2%22+(status:open%20OR%20status:merged) is the old topic from a year ago, I've got rebased things locally that I'll push up next week and talk you through | 15:07 |
| * lyarwood wonders why git-review borked the topic name | 15:08 | |
| EugenMayer | is there any way to see the progress of a live migration? | 15:24 |
| EugenMayer | like an estimation or how much data has been transmitted? | 15:24 |
| lyarwood | EugenMayer: https://docs.openstack.org/nova/latest/admin/live-migration-usage.html#monitoring-the-migration | 15:30 |
| EugenMayer | thank you! | 15:31 |
| EugenMayer | It seems after unshelving, availability_zone has been set, not availability_zone_hints - which now confuses my terraform. Is there a way to set the _hints one? AFAIR availability_zone is deprecated, right? | 15:44 |
| opendevreview | Merged openstack/nova stable/xena: Reproduce bug 1953359 https://review.opendev.org/c/openstack/nova/+/820550 | 17:29 |
| opendevreview | Merged openstack/nova stable/xena: Extend the reproducer for 1953359 and 1952915 https://review.opendev.org/c/openstack/nova/+/821941 | 20:32 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt dom caps config: start supporting CPU die_id attrib https://review.opendev.org/c/openstack/nova/+/823865 | 21:45 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: build CPU distance matrix upon init https://review.opendev.org/c/openstack/nova/+/823866 | 21:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!