| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-30 | |||
| 17:17:15 | aspiers | from the spec: "The iommu attribute is on for all virtio devices. Despite the name, this does not require the guest or host to have an IOMMU device, but merely enables the virtio flag which indicates that virtualized DMA should be used. This ties into the SEV code to handle memory encryption/decryption, and prevents IO buffers being shared between host and guest." | |
| 17:17:43 | aspiers | I've definitely seen kernel panics from incorrectly configured guests, I can't remember if I explicitly tested virtio-scsi without iommu | |
| 17:17:48 | aspiers | but it's required for sure | |
| 17:17:54 | efried | k, would be good to understand all of that to know whether this should be considered critical for RC2. It sounds like it probably is. <== dansmith mriedem | |
| 17:18:28 | sean-k-mooney | well you have to opt into enabling the scsi disk bus | |
| 17:18:30 | efried | aspiers: imo [unencrypted when encrypted was expected] would be worse than [kernel panic] (assuming the latter is only affecting the guest, not the whole host) | |
| 17:18:34 | sean-k-mooney | since that is not the default | |
| 17:18:43 | aspiers | sean-k-mooney: not if config drives or cdroms are used | |
| 17:18:52 | sean-k-mooney | but it would be very common to do so if you are using ceph | |
| 17:19:02 | efried | but either way it's a bug in a new feature and therefore RC potential IIUC | |
| 17:19:10 | aspiers | efried: [unencrypted when encrypted was expected] will not happen | |
| 17:19:10 | sean-k-mooney | aspiers: config drive should now defualt to sata | |
| 17:19:18 | sean-k-mooney | and it used to default to ide | |
| 17:19:21 | efried | well that's good anyway :) | |
| 17:19:36 | aspiers | efried: the <launchSecurity> element will be there regardless of any iommu stuff | |
| 17:22:47 | dansmith | efried: in a sec | |
| 17:23:12 | dansmith | mriedem: do you know if another db_sync --all-cells patch was floated somewhere? The one I was thinking of never merged and was abandoned silently in july | |
| 17:23:21 | dansmith | mriedem: https://review.opendev.org/#/c/519275/ | |
| 17:23:30 | dansmith | not sure why, but that probably took it off anyone's radar | |
| 17:24:10 | dansmith | or hmm, maybe we made it hit all cells by default... gosh, all this fell out of my head | |
| 17:25:19 | dansmith | ah, no --local-cell is just skipping cell0, so it still doesn't fan like I thought | |
| 17:29:30 | dansmith | efried: probably depends on what the fix looks like and what impacts it might have, and what the impact of not having it is (like you say expecting safe, but not safe) | |
| 17:30:55 | sean-k-mooney | thats the main part of the fix https://review.opendev.org/#/c/684825/4/nova/virt/libvirt/designer.py | |
| 17:33:37 | sean-k-mooney | aspiers: by the way the only think that stikes me about the fix is that we are testing with a fake xml we cannot generate | |
| 17:33:38 | mriedem | dansmith: i don't remember another, though i thought i had reported a bug at some point about making db sync support all cells but i might just be thinking of the archive command | |
| 17:34:05 | sean-k-mooney | e.g. its not posibel to have two scsi contolers with a different model based on how nova generates the xml | |
| 17:34:06 | dansmith | mriedem: yeah, so code in tree does not fan out (except to cell0) and that other patch got abandoned in July for some reason | |
| 17:34:16 | sean-k-mooney | that said it is vaild in libvirt to do that | |
| 17:34:19 | mriedem | i also remember bringing it up at some summit, i.e. should the nova-manage commands hit all cells? and it was a low priority response - that might have been sydney... | |
| 17:34:36 | mriedem | dansmith: my guess is they abandoned it b/c it sat since july with no replies | |
| 17:34:47 | dansmith | could be | |
| 17:34:59 | mriedem | lincanwei is still around though, he's the watcher ptl | |
| 17:39:20 | dansmith | oh, nm, this was abandoned in Jan, last patch was in july 2018, I see | |
| 17:39:27 | dansmith | hmm, I thought there was a more recent attempt at this t hen | |
| 17:40:32 | mriedem | i see a duplicate of the archive all-cells patch | |
| 17:40:56 | mriedem | https://review.opendev.org/#/c/599050/ ? | |
| 17:41:08 | mriedem | oh no that's different | |
| 17:41:13 | dansmith | no | |
| 17:41:14 | dansmith | yeah | |
| 17:41:22 | dansmith | anyway, not a big deal | |
| 17:41:51 | gmann | mriedem: dansmith : seems like sec groups are added for down cell response for detail GET API case only (it is not included in Show API case) | |
| 17:42:06 | mriedem | dansmith: heh https://review.opendev.org/#/c/420973/ | |
| 17:42:08 | mriedem | it was me! | |
| 17:42:14 | gmann | and that is because sec grps are added explicitly for detail case- https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/views/servers.py#L410 | |
| 17:42:32 | dansmith | mriedem: that's not the one I was thinking of, but..funny | |
| 17:42:34 | gmann | is it missed in 2.69 microversion ? | |
| 17:44:12 | gmann | with nova-net it was not added as there were no sec grp in DB nut with stephenfin patch to run sample tests with neutron fail - https://review.opendev.org/#/c/684335/5/doc/api_samples/servers/v2.69/servers-details-resp.json@12 | |
| 17:45:06 | mriedem | it was probably an oversight | |
| 17:45:36 | mriedem | i'm also not sure how much we need to care if the cell that the instance is in is down | |
| 17:45:40 | gmann | and same for host_status ? | |
| 17:46:12 | mriedem | if the cell that the instance is in is down, the host_status likely doesn't matter | |
| 17:46:16 | mriedem | you can't do anything with that instance | |
| 17:46:23 | mriedem | except maybe delete it | |
| 17:47:13 | mriedem | the whole point with 2.69 is return a minimal set of stuff based on what's in the API DB for the instance | |
| 17:47:24 | mriedem | not to return everything we possibly can | |
| 17:47:57 | mriedem | e.g. we could also proxy to cinder to get attached volume info but we're not going to do that (like the neutron api proxy call to get security groups) | |
| 17:48:49 | mriedem | gmann: for host_status this method won't work really https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/compute/api.py#L4881 | |
| 17:48:57 | gmann | yeah, it would not hurt to return. only difference will be GET and GET details response. Not sure is it worth to fix though. | |
| 17:49:11 | mriedem | instance.host wouldn't be set so at best we'd be returning NONE which is potentially not accurate - UNKNOWN would be more appropriate | |
| 17:49:29 | mriedem | if you're using 2.69+ and getting a repsonse from a down cell, there are already going to be a lot of differences | |
| 17:49:37 | mriedem | for which you need to account client-side | |
| 17:50:02 | mriedem | https://docs.openstack.org/api-guide/compute/down_cells.html gives the details on the fields that are returned | |
| 17:52:34 | sean-k-mooney | aspiers: commented on https://review.opendev.org/#/c/684825/4 over all this address the reported bug but it misses another edgecase where qemu virtio channeles are not handeled | |
| 17:53:09 | gmann | i see. then let's include in sample files as it is returned. | |
| 17:54:50 | mriedem | gmann: sorry, what is returned? | |
| 17:55:13 | mriedem | host_status nor security_groups are returned for GET /servers/{server_id} when the cell is down | |
| 17:55:51 | mriedem | show and detail are different in the down cell case b/c in the detail case we won't even get to https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/views/servers.py#L146 because we will have already filtered out the instances from the down cells | |
| 17:55:57 | gmann | mriedem: yeah but 'security_groups' are returned in GET /servers/details case | |
| 17:56:10 | mriedem | not if the instance is in a down cell | |
| 17:56:16 | gmann | mriedem: due to this - https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/views/servers.py#L410 | |
| 17:56:30 | mriedem | gmann: you will not get there with an instance from a down cell | |
| 17:56:37 | mriedem | the multi-cell instance lister code will filter out those results | |
| 17:56:45 | gmann | because for detail case it is added after show method return | |
| 17:57:11 | mriedem | ... | |
| 17:57:17 | mriedem | again, | |
| 17:57:28 | mriedem | GET /servers/detail will filter out instances from down cells | |
| 17:57:35 | mriedem | so we will not get to https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/views/servers.py#L410 for instances from down cells | |
| 17:57:38 | mriedem | so i don't see the problem | |
| 17:58:14 | mriedem | oh i think i see | |
| 17:58:24 | mriedem | https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/views/servers.py#L396 | |
| 17:58:27 | mriedem | self._list_view(self.show | |
| 17:58:29 | mriedem | but still, | |
| 17:58:39 | mriedem | instances from a down cell won't get that far | |
| 17:58:47 | mriedem | gmann: are you just basing this on code inspection? | |
| 17:59:30 | gmann | mriedem: this is from tests which I am not sure does actual down cell handling - https://review.opendev.org/#/c/684335/5/doc/api_samples/servers/v2.69/servers-details-resp.json | |
| 17:59:56 | gmann | so instance from down-cell will be there in GET detail case or not | |
| 18:00:08 | mriedem | will not | |
| 18:00:11 | gmann | *so not sure if instance | |
| 18:00:13 | gmann | ok | |
| 18:00:15 | mriedem | compute API get_all will filter those out | |
| 18:00:49 | mriedem | you would need to follow this thread https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/compute/api.py#L2760 | |
| 18:02:54 | gmann | but cell-down-support will be true for > 2.69 - https://github.com/openstack/nova/blob/961c2945491ebcea3cf1cb175a06d057155aa5a5/nova/api/openstack/compute/servers.py#L329 | |
| 18:03:24 | gmann | then it will include the instances form down cell also | |
| 18:03:29 | mriedem | no | |
| 18:03:31 | mriedem | that's not what that means | |
| 18:03:39 | mriedem | you need to look at the InstanceLister code | |
| 18:03:45 | aspiers | sean-k-mooney: I've replied and emailed the SEV gurus to ask them | |
| 18:03:53 | aspiers | sean-k-mooney: I would prefer to deal with that in a follow-up though | |
| 18:04:14 | aspiers | especially considering we don't actually know for sure yet it's an issue | |
| 18:04:32 | sean-k-mooney | yep we could | |