Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-04
17:40:00 mriedem meaning you'll reschedule to another host that will also fail
17:40:07 aspiers mriedem: right, that's what I was worried about
17:40:19 mriedem what makes a sev instance a sev instance?
17:40:23 mriedem something in the flavor or image right?
17:40:25 aspiers yes
17:40:30 aspiers hw:mem_encryption
17:40:36 sean-k-mooney you could block it either in the api by checking for the flavor extra spec
17:40:47 sean-k-mooney or in a prifilter i guess
17:40:47 aspiers sean-k-mooney: that's what I want to do, yep
17:40:58 aspiers I'm just trying to find the right bit of code
17:41:09 mriedem pre-filter doesn't work since it doesn't have the context on you doing a move operatoin vs a server create
17:41:18 sean-k-mooney its the validate_flavor_image_nostatus funciton
17:41:22 mriedem so just failing fast in the api or conductor would be sufficient
17:41:25 sean-k-mooney or one that it calls
17:41:42 aspiers nova.compute.api.API.live_migrate()?
17:42:01 mriedem what about cold migrate? does that work?
17:42:07 aspiers no
17:42:08 sean-k-mooney aspiers: you can do it the way we do for sriov migration i guess.
17:42:12 aspiers need to also block suspend
17:42:13 sean-k-mooney aspiers: no?
17:42:23 sean-k-mooney why would cold migration not work
17:42:35 sean-k-mooney suspenmd i get
17:42:38 aspiers oh sorry
17:42:39 mriedem heh, you might as well just write a decorator then
17:42:42 sean-k-mooney its doing a managed save
17:42:47 aspiers yeah cold migration probably OK
17:42:54 aspiers http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#limitations
17:43:08 aspiers yes, cold migration/shelve is OK
17:43:23 aspiers That's why I explicitly wrote that in the spec - cos I knew I'd forget later ;-)
17:44:06 mriedem def block_for_sev(func, context, instance, *args, **kwargs): if 'hw:mem_encryption' in instance.flavor.extra_specs: raise OperationNotSupportedForSev()
17:44:13 sean-k-mooney aspiers: if you do it in the conductor do it here. but if you eant to do it in the api. yuou need to do in a different location
17:44:16 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L318
17:44:19 mriedem then just decorate the methods that don't support sev instances
17:44:20 sean-k-mooney ill see if i can find it
17:44:49 mriedem it would be nice to not duplicate the same checks all over the api and conductor...
17:44:53 aspiers agreed
17:44:59 sean-k-mooney ya
17:45:12 sean-k-mooney sicne we know this just wont work for sev instace right now i think the api is better
17:45:15 aspiers presumably better UX if it's done in the API?
17:45:17 sean-k-mooney just flat out block it
17:45:35 sean-k-mooney yes we will end up doing less work too
17:45:49 aspiers right, so is e.g. nova.compute.api.API.live_migrate() the right place?
17:46:01 aspiers using a decorator like mriedem suggested
17:46:31 sean-k-mooney the problem with doing it in the api is when another dirver starts support sev then we need to remove it and move it to the condocor or somethwer else that can be aware of the hypervior type
17:46:45 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671793
17:46:46 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693
17:46:46 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800
17:46:47 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571
17:46:47 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801
17:46:48 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895
17:46:48 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'InstanceNUMATopology.cpu_pinning' property https://review.opendev.org/680106
17:46:49 openstackgerrit Stephen Finucane proposed openstack/nova master: Validate CPU config options against running instances https://review.opendev.org/680107
17:46:49 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add 'NUMACell.pcpuset' field https://review.opendev.org/680108
17:47:01 aspiers sean-k-mooney: what other driver would start to support SEV?
17:47:17 stephenfin mriedem: If you're interested, there's the startup check I was talking about earlier https://review.opendev.org/680107
17:47:18 sean-k-mooney hyperv maybe? vmware
17:47:35 sean-k-mooney i mean its not a kvm tech it hsould be usable on other hyperviors
17:47:36 stephenfin aspiers: Might be of interest to you, actually ^
17:47:45 stephenfin It's a similar thing to what you need, I suspect
17:47:52 stephenfin sean-k-mooney can confirm
17:47:54 sean-k-mooney aspiers: what i would do is write a check in hardware.py
17:47:57 stephenfin though /me has to go
17:47:58 sean-k-mooney then call that form the api
17:48:02 sean-k-mooney and or conductor
17:48:09 aspiers sean-k-mooney: there is already a check in hardware.py
17:48:32 sean-k-mooney aspiers: well we use check in hardware.py from the api for other things
17:48:54 mriedem fwiw i don't see any other virt driver supporting sev anytime soon
17:49:03 aspiers mriedem: agreed
17:49:13 mriedem the vmware driver is basically maintenance mode
17:49:22 mriedem xen is on the way out
17:49:23 aspiers sean-k-mooney: https://opendev.org/openstack/nova/src/branch/master/nova/virt/hardware.py#L1140
17:49:30 mriedem oh that reminds me,
17:49:38 mriedem efried: should we formally deprecate the xen driver before releasing train?
17:49:47 dansmith wow
17:49:51 mriedem right now you just get a quality warning in the logs on startup
17:50:05 mriedem dansmith: we talked about that at the ptg
17:50:11 mriedem hasn't had CI in probably a year
17:50:17 dansmith I know
17:50:23 sean-k-mooney mriedem: didnt we say we would at the PTG
17:50:25 dansmith it's just...a big and sad deal
17:50:40 sean-k-mooney mriedem: well if nothing impove in train
17:50:49 mriedem deprecating doesn't mean we remove in U
17:50:52 mriedem just that we have the option
17:50:57 dansmith yup
17:51:01 sean-k-mooney mriedem: i dont think testing has impvoed so we proably sue
17:51:04 mriedem we still need to nix nova-net
17:51:07 sean-k-mooney shoudl
17:51:16 dansmith deprecation should be a shot across the bow.. if nobody steps up at that point, then.. the signal is clear
17:51:40 mriedem i'll put it on the meeting agenda for tomorrow so it's in the meeting logs
17:51:41 mriedem and such
17:51:47 mriedem such and such and so and so
17:52:02 sean-k-mooney aspiers: ya so i would just call get_mem_encryption_constraint form the api and reject the live migration if its true
17:52:16 donnyd hasn't nova-net been on the chopping block for the better half of a decade?
17:52:25 aspiers sean-k-mooney: right, so is nova.compute.api.API.live_migrate() the right method to do the rejection?
17:52:30 mriedem donnyd: deprecated in newton
17:52:44 aspiers sean-k-mooney: and nova.compute.api.API.suspend()?
17:52:47 mriedem donnyd: nova-net gets hard to remove when it's tendrils are in everything
17:52:53 mriedem *its
17:53:07 donnyd makes sense
17:53:25 melwitt donnyd: did you ever figure out your slow image download problem? I had talked to penick about it and he said with the hardware specs you gave, download should be fast (like you were also thinking)

Earlier   Later