| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 11:51:38 | sean-k-mooney | artom: not any more | |
| 11:51:39 | aspiers | artom, sean-k-mooney: so the suggestion is a common validation interface across all drivers? | |
| 11:51:45 | aspiers | sean-k-mooney: no I do | |
| 11:51:56 | aspiers | sean-k-mooney: I was wrong (again) | |
| 11:52:19 | sean-k-mooney | hardware specifc tratit valdiation lives in hardare.py | |
| 11:52:19 | aspiers | sean-k-mooney: https://review.opendev.org/#/c/680065/ has circular dependencies even before sev_enabled is added | |
| 11:52:21 | luyao | stephenfin: comments addressed , and thanks for your review. https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory+(status:open) | |
| 11:53:02 | aspiers | sean-k-mooney, artom: http://paste.openstack.org/show/771288/ | |
| 11:53:17 | aspiers | sean-k-mooney: so unfortunately your suggestion wasn't enough to solve it | |
| 11:53:20 | sean-k-mooney | s/triatis/flavor and image/ its where all the numa, pinning, hugepages and pci checks live | |
| 11:54:04 | aspiers | sean-k-mooney: right but until now it never cared about machine types | |
| 11:54:33 | aspiers | maybe moving get_machine_type to a separate class is the only way | |
| 11:54:37 | aspiers | s/class/file/ | |
| 11:55:08 | sean-k-mooney | no that wont work | |
| 11:55:16 | aspiers | right it won't | |
| 11:55:26 | sean-k-mooney | it because importing nova/virt/libvirt/__init__.py has sideffects | |
| 11:55:26 | aspiers | well, not unless it is moved outside nova.virt.libvirt | |
| 11:55:29 | aspiers | yes | |
| 11:55:51 | sean-k-mooney | we should remove this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/__init__.py#L17 | |
| 11:55:56 | aspiers | that sounds good | |
| 11:56:00 | aspiers | why is it even there? | |
| 11:56:11 | sean-k-mooney | we proably moved things and that was a quick hack | |
| 11:56:31 | aspiers | OK so first I have to get rid of that | |
| 11:56:33 | aspiers | sigh | |
| 11:58:26 | sean-k-mooney | remind me why you need to call the fucntion to get the machine type | |
| 11:58:39 | sean-k-mooney | i know its for suspend and live migate | |
| 11:58:46 | aspiers | no | |
| 11:58:53 | aspiers | it's to check for q35 | |
| 11:58:56 | sean-k-mooney | yes | |
| 11:58:59 | aspiers | https://review.opendev.org/#/c/680065/6//COMMIT_MSG | |
| 11:59:05 | aspiers | SEV doesn't work without q35 | |
| 11:59:15 | sean-k-mooney | aspiers: where is that check going to be called form | |
| 11:59:21 | sean-k-mooney | it wont be used in the api | |
| 11:59:28 | aspiers | yes in the API was the idea | |
| 11:59:34 | sean-k-mooney | and it can only be known on the compute node | |
| 11:59:41 | sean-k-mooney | but what api | |
| 11:59:49 | sean-k-mooney | live migrate and suspend? | |
| 11:59:55 | aspiers | no, launch | |
| 12:00:04 | sean-k-mooney | it cant be known at lauch | |
| 12:00:08 | sean-k-mooney | we have not selected the host | |
| 12:00:16 | sean-k-mooney | and the machine type can be set in the hsot config | |
| 12:00:26 | aspiers | right, this is the crux of the problem | |
| 12:00:40 | sean-k-mooney | right so you cant check for q35 in the api | |
| 12:00:41 | aspiers | but we can at least check the image | |
| 12:00:51 | sean-k-mooney | at lest not the create server api | |
| 12:01:02 | aspiers | no we can check for hw_machine_type in the image | |
| 12:01:19 | aspiers | we already require hw_firmware_type=uefi | |
| 12:01:21 | sean-k-mooney | checkign the image does not require calling get default machine tyhpe | |
| 12:01:24 | sean-k-mooney | or whathever | |
| 12:01:42 | sean-k-mooney | if we are jsut checking the image then just check the metadata directly | |
| 12:02:17 | aspiers | that's what I was originally doing https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/utils.py@538 | |
| 12:02:38 | sean-k-mooney | that check should be in hardware.py direclty | |
| 12:02:46 | aspiers | https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/driver.py@5097 | |
| 12:02:54 | aspiers | I was originally only checking the image | |
| 12:02:57 | sean-k-mooney | you can have a second check for the machine type on the host | |
| 12:03:17 | sean-k-mooney | aspiers: for the fast fail on create server i think that is all you can do | |
| 12:03:27 | aspiers | hang on | |
| 12:03:31 | sean-k-mooney | then you can do the late check in the dirver | |
| 12:03:45 | aspiers | either we *require* hw_machine_type=q35 image property or we make it optional | |
| 12:03:49 | aspiers | which are you suggesting? | |
| 12:03:58 | aspiers | I mean in the SEV case | |
| 12:04:01 | sean-k-mooney | we will not require it | |
| 12:04:06 | sean-k-mooney | or should not | |
| 12:04:14 | aspiers | OK so then what's the point of an API check? | |
| 12:04:16 | sean-k-mooney | we can check if hw_machine_type is set | |
| 12:04:27 | sean-k-mooney | and if its not q35 reject | |
| 12:04:32 | aspiers | OK yeah | |
| 12:04:41 | aspiers | then if not set, it will fail later | |
| 12:04:46 | sean-k-mooney | but the api check was not for create it was for live migrate and suspend originaly | |
| 12:04:51 | sean-k-mooney | yep | |
| 12:04:51 | aspiers | perhaps horribly on multiple compute hosts | |
| 12:05:02 | aspiers | no live migrate/suspend is a different topic | |
| 12:05:09 | aspiers | that's not related to machine type | |
| 12:05:22 | aspiers | that relies on checking for hw_mem_encryption | |
| 12:05:30 | sean-k-mooney | we could maybe report machine types as traits in the future | |
| 12:05:36 | sean-k-mooney | but that is not ideal | |
| 12:05:37 | aspiers | that's this one https://review.opendev.org/#/c/680158/3 | |
| 12:05:47 | aspiers | kashyap: didn't we talk about that? | |
| 12:05:59 | aspiers | kashyap: about machine types as traits? | |
| 12:06:08 | aspiers | thought I vaguely remembered some discussion on that | |
| 12:06:10 | aspiers | maybe not | |
| 12:06:12 | sean-k-mooney | i think that is leaking too much info personally | |
| 12:06:33 | aspiers | I don't see a security risk but different rathole | |
| 12:06:43 | aspiers | maybe you're right but let's not go there now | |
| 12:06:44 | sean-k-mooney | no that is not what i ment | |
| 12:07:19 | sean-k-mooney | we could advertise that the host has q35 support | |
| 12:07:24 | aspiers | OK so to summarise, the plan is this: | |
| 12:07:37 | aspiers | hw_machine_type=q35 image prop is optional for SEV | |
| 12:07:57 | aspiers | we have an API check enforcing that if it's there, it has to be q35 family | |
| 12:08:19 | aspiers | but if it's not there then we just hope the scheduler picks a machine with nova.conf defaulting x86_64 to q35 | |
| 12:08:35 | aspiers | if it doesn't it will fail and try other compute hosts | |
| 12:08:44 | sean-k-mooney | and check it in the driver | |
| 12:08:46 | sean-k-mooney | but yes | |
| 12:08:57 | sean-k-mooney | it will fail and rescdule | |
| 12:09:18 | sean-k-mooney | and you can use host aggreates ectra if you want too to reduce the chance of that happening | |
| 12:09:32 | aspiers | so the operator should configure CONF.libvirt.machine_type to x86_64=q35 on all SEV hosts | |
| 12:09:35 | sean-k-mooney | if you dont want to set q35 in the image or the config | |
| 12:09:55 | sean-k-mooney | yes i think that is what we shoudl recommend | |
| 12:10:03 | aspiers | OK | |
| 12:10:05 | aspiers | BUT | |