| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-08 | |||
| 09:42:56 | whoami-rajat__ | the usecase is simple, we create a dependency chain vol1 -> snap1 -> snap2 and we try to delete snap2 from cinder when the VM is off | |
| 09:43:38 | whoami-rajat__ | incase of online blockCommit, nova/libvirt updates the backing_file of snap2 from snap1->vol1 but incase of qemu-img commit | |
| 09:43:40 | kashyap | (Side note: you'd want to use the arrow the other way around to represent the backing files :-) vol1 <- snap1 <- snap2) | |
| 09:43:56 | whoami-rajat__ | oh yep | |
| 09:44:05 | whoami-rajat__ | active file is the last one | |
| 09:44:13 | kashyap | Yes | |
| 09:44:15 | whoami-rajat__ | vol1 <- snap1 <- snap2 | |
| 09:44:30 | whoami-rajat__ | anyway, when i try to do it offline using qemu-img commit | |
| 09:44:50 | whoami-rajat__ | the file gets commited snap1 to vol1 but i'm not sure how to update the backing_file of snap2 | |
| 09:46:29 | whoami-rajat__ | just for ease of referencing, these are the places where nova does online blockCommit | |
| 09:46:30 | whoami-rajat__ | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3130-L3131 | |
| 09:46:36 | whoami-rajat__ | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/guest.py#L822-L832 | |
| 09:46:47 | kashyap | whoami-rajat__: Offline: you can commit snap2 into snap1, and then snap1 back into vol1. What doesn't work for you? | |
| 09:47:00 | kashyap | Do you have a working example to show your problem? | |
| 09:48:10 | whoami-rajat__ | I'm not sure what you mean by working example, we issue ``cinder snapshot-delete snap1`` command from cinder that doesn't work right now | |
| 09:48:45 | whoami-rajat__ | the info send from cinder to nova is the current snap to be deleted and it's backing file only | |
| 09:49:52 | kashyap | whoami-rajat__: Okay, your question is: when doing it offline, once snap1 is committed to vol1, then how do you update the backing file reference of 'snap2' to 'vol1' -- correct? | |
| 09:50:08 | whoami-rajat__ | yep | |
| 09:50:48 | kashyap | whoami-rajat__: Then, 'qemu-img rebase' is used to change the backing file pointer | |
| 09:51:01 | kashyap | whoami-rajat__: Here's a doc, carefully take a look at it :-) -- https://kashyapc.fedorapeople.org/Offline-rebase-commit-and-convert.txt | |
| 09:51:31 | whoami-rajat__ | yep i saw it but the info sent by cinder to nova is limited, it doesn't send snap2 info to nova | |
| 09:52:08 | whoami-rajat__ | kashyap, I understand the process but i'm bounded by the info that nova and cinder share :) | |
| 09:53:12 | kashyap | whoami-rajat__: Right; it's tricky. To step back a bit, you're trying to fix a partcular bug? What prompted you to try this? | |
| 09:53:47 | kashyap | (You might want to explain what you've tried so far on the change, for other reviewers. They might ask the same what I asked here) | |
| 09:56:53 | whoami-rajat__ | i have just done the qemu-img commit part there, which works but when trying to delete snap2 it fails because of the backing file issue | |
| 09:57:12 | whoami-rajat__ | the main part i haven't figured out how nova/libvirt does automatically and how i can do it manually hence the WIP | |
| 09:58:54 | kashyap | Wait, why do you delete 'snap2'? You want to (a) delete 'snap1', because you've commited its content into 'vol1'; and (b) update the backing file of 'snap2' to refer to 'vol1' (which now also has 'snap1' contents) | |
| 09:59:33 | kashyap | (Then you can delete 'snap1' file, which is now not needed anymore, obviously) | |
| 09:59:56 | kashyap | whoami-rajat__: Anyway, I've made a comment in the change. This is tricky area; so might take some good trial-and-error. Patience will help :) | |
| 10:00:42 | whoami-rajat__ | kashyap, yep, that operation is successful but we didn't update the backing file of snap2, in a subsequent operation when trying to delete snap2 it errors out because backing_file of snap2 is wrong now | |
| 10:01:09 | kashyap | Right, that makes sense. | |
| 10:03:23 | whoami-rajat__ | yeah i have been trying out a few things here and there lately but no success, i thought the part ``dev = guest.get_block_device(commit_disk)`` might contain the info regarding the whole chain and maybe i can update the backing chain there | |
| 10:03:37 | whoami-rajat__ | but i guess nova calls ``virsh blockCommit`` and libvirt does all the work there | |
| 10:06:19 | kashyap | Yes; see the wrapper method commit() in guest.py | |
| 10:08:24 | lyarwood | whoami-rajat__: just reading up | |
| 10:08:50 | lyarwood | whoami-rajat__: the entire chain should be in .info file no? | |
| 10:09:02 | lyarwood | whoami-rajat__: that cinder controls | |
| 10:09:19 | lyarwood | I guess that doesn't actually show the chain | |
| 10:12:17 | lyarwood | kashyap: why would we commit anything to vol1? | |
| 10:12:32 | lyarwood | kashyap: shouldn't the base volume remain untouched if we are just removing the middle snapshot? | |
| 10:13:07 | lyarwood | ah because we'd want the delta in snap2 to remain the same | |
| 10:13:09 | lyarwood | ignore me | |
| 10:13:15 | kashyap | lyarwood: What happens to the content in the middle one, then? :-) | |
| 10:13:26 | kashyap | Yep, you you're right | |
| 10:13:28 | lyarwood | right I was thinking that would end up in snap2 | |
| 10:14:04 | lyarwood | getting confused with the image COW usecase where we don't want the image to change | |
| 10:14:12 | lyarwood | but this isn't the same | |
| 10:14:26 | kashyap | Yeah, I hear ya | |
| 10:14:54 | whoami-rajat__ | i think that happens incase of a blockRebase when backing file changes move up to the snapshot file | |
| 10:15:02 | kashyap | In this case, we have: vol1 <- snap1 <- snap2. Commit snap1 to vol1. Then update backing file of 'snap2' to 'vol1' (base). Then remove the invalid 'snap1' | |
| 10:15:41 | whoami-rajat__ | yep, 1) and 3) are already done by nova and cinder resp, we need to figure out 2) | |
| 10:17:02 | kashyap | Offline rebase | |
| 10:19:11 | stephenfin | kashyap, lyarwood: Could you stick https://review.opendev.org/#/c/756549/ and https://review.opendev.org/#/c/752912/ on your review queues, please? | |
| 10:20:12 | lyarwood | stephenfin: ack | |
| 10:20:28 | stephenfin | thanks | |
| 10:20:57 | kashyap | stephenfin: Ah, USB controller and 'vmcore'; nice | |
| 10:21:00 | kashyap | Will do | |
| 10:21:49 | stephenfin | kashyap: You'll likely be interested in https://review.opendev.org/#/c/756552/ also. That's lower priority for me right now but still potentially useful | |
| 10:22:46 | stephenfin | bauzas: Dead simple +2 here https://review.opendev.org/#/c/756135/ | |
| 10:23:30 | kashyap | Input devices; yeah, noted. | |
| 12:12:11 | bauzas | stephenfin: roger this. | |
| 12:33:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 12:33:26 | openstack | bug 1897528 in OpenStack Compute (nova) "32bit pci domain number is not supported" [High,Confirmed] https://launchpad.net/bugs/1897528 | |
| 12:33:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1897528 https://review.opendev.org/756696 | |
| 12:36:22 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Ignore PCI devices with 32bit domain https://review.opendev.org/756697 | |
| 12:44:26 | admin0 | hi .. can default_domain in nova be blank ? | |
| 12:57:31 | ganso | Hi Nova folks! I know everyone is busy with Victoria release, but if you have a minute to spare and could please take a look at this stable/ussuri patch that already has a +2 and just needs one more +2 to land: https://review.opendev.org/#/c/752245/ Thanks in advance! | |
| 12:57:42 | ganso | bauzas, lyarwood ^ | |
| 13:59:33 | sean-k-mooney | o/ | |
| 14:05:09 | gibi | \o | |
| 14:06:23 | sean-k-mooney | my os update did not go well after systemd crashed half way thorugh | |
| 14:06:36 | gibi | sounds bad | |
| 14:06:49 | sean-k-mooney | i had to reinstall | |
| 14:07:47 | sean-k-mooney | after a reboot while i could decypt the luxs lvm volume i could not boot form it so trying to get email and other stuff workign again | |
| 14:07:59 | sean-k-mooney | at least i have irc again | |
| 14:16:01 | bauzas | sean-k-mooney: glad to see you | |
| 14:18:21 | sean-k-mooney | i now have fedora 32. goggle calandar is still broken in thruderbird and evoltion and now im having issue with email too but i have a gui again so i guess that is progress | |
| 14:21:43 | openstackgerrit | Navid Pustchi proposed openstack/nova-specs master: add availability-zone-affinity-anti-affinity-filter review. https://review.opendev.org/756380 | |
| 14:30:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Allow excluding image type capabilities https://review.opendev.org/756534 | |
| 14:43:00 | ygk_12345 | hi all | |
| 14:43:02 | ygk_12345 | i have created a availability zone and added a compute node into it. but the zone status is showing as "not available". how can I change its status ? | |
| 14:43:27 | sean-k-mooney | i did not thnk the AZ had a staus | |
| 14:43:31 | sean-k-mooney | the host do | |
| 14:44:28 | ygk_12345 | sean-k-mooney check this outpout http://paste.openstack.org/show/798870/ | |
| 14:45:00 | ygk_12345 | sean-k-mooney the "test-aggregate-az" is not available | |
| 14:45:22 | ygk_12345 | i am not able to launch any vms in it | |
| 14:46:09 | sean-k-mooney | and if you check the host in test-aggreate | |
| 14:46:30 | sean-k-mooney | you see the host is listed and its avaiable/active | |
| 14:46:33 | ygk_12345 | the host is present in the aggregate | |
| 14:46:55 | ygk_12345 | but the host is not getting listed in the output | |
| 14:47:29 | ygk_12345 | http://paste.openstack.org/show/798871/ | |
| 14:48:35 | stephenfin | lyarwood: What, if anything, do you know about image-defined BDMs? | |
| 14:48:45 | stephenfin | Are they a thing we still use/support? | |
| 14:48:48 | ygk_12345 | sean-k-mooney did u see that. it hs one compute | |
| 14:48:54 | ygk_12345 | *has | |
| 14:49:08 | stephenfin | I'd trying to figure out what the e.g. 'img_mappings' image metadata property is/was used for | |
| 14:49:12 | stephenfin | *I'm | |
| 14:54:16 | sean-k-mooney | stephenfin: it might be realted to ephemeral disk | |
| 14:55:12 | sean-k-mooney | when you are using qcow the bdms have a type of local but i think there is a way or there was a way to split up the flavor.ephmerial storage using dbms to have multipel disks | |
| 14:55:28 | sean-k-mooney | no idea if that is what you are trying to figure out | |