| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-02 | |||
| 14:55:14 | kashyap | yaawang: Hi, please copy me on the impl of that 'cpu_models' thing. Happy to work out the details. | |
| 14:57:48 | kashyap | LOL | |
| 14:57:57 | kashyap | (Sorry) | |
| 15:04:18 | spatel | sean-k-mooney: morning | |
| 15:04:28 | sean-k-mooney | spatel: o/ | |
| 15:05:24 | spatel | I have testing my new openstack cloud, i have spun vm-1 but i am not seeing any live migration option in drop down menu | |
| 15:05:42 | gibi | kashyap: it is the remains of time I worked on versioned notifications a lot | |
| 15:05:53 | sean-k-mooney | spatel: that sound like a horizon issue | |
| 15:06:10 | spatel | hmm! | |
| 15:06:23 | sean-k-mooney | im not sure how that is displayed but i would not expect horizon to be able to tell if live migration is uspported | |
| 15:06:37 | sean-k-mooney | we do not have a api you can query to discover that | |
| 15:07:00 | kashyap | gibi: Yeah, guessed as much :-) | |
| 15:07:01 | sean-k-mooney | we just have teh endpoint to do a migration which can succeed or fail wehn you call it | |
| 15:07:07 | kashyap | sylvainb: Quite active discussion on that 'mdevctl' thread on libvirt upstream thread | |
| 15:07:17 | kashyap | Err, bauzas: | |
| 15:08:11 | kashyap | (I see that you wanted to try it, 'mdevctl' in Nova. Haven't caught up with the rest of the KM-long thread there, though.) | |
| 15:09:33 | spatel | sean-k-mooney: oh wait, when i logged in as admin i can see live migration | |
| 15:09:48 | sean-k-mooney | spatel: yes live migration is admin only | |
| 15:09:49 | spatel | its not available for end-user | |
| 15:10:23 | sean-k-mooney | spatel: yep the only action an endupser can do that might casue a migration to happen is resize | |
| 15:11:16 | spatel | yes they do have re-size option but not live, i think this is good because we don't want end user do live migration without understanding | |
| 15:11:47 | sean-k-mooney | yep | |
| 15:12:25 | spatel | sean-k-mooney: how do i evacuate single VM? is it something only available in command line? | |
| 15:13:04 | sean-k-mooney | proably. yes | |
| 15:13:43 | sean-k-mooney | you have to use the nova cli instead of opentasck one | |
| 15:13:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Stabilize unshelve notification sample tests https://review.opendev.org/668675 | |
| 15:15:21 | gibi | efried, mriedem: reported bug and fixed up the commit message ^^ | |
| 15:15:33 | efried | gibi: +2, thanks. | |
| 15:15:44 | gibi | efried: thank you | |
| 15:15:58 | efried | yahyoubetcha | |
| 15:23:22 | spatel | sean-k-mooney: let me try and see.. i am running test on cpu-pining live migration using evacuate | |
| 15:32:39 | sean-k-mooney | spatel: it should just be "nova evacuate <server>" and optioncally you can also proved a host as teh last postional arg. | |
| 15:33:33 | sean-k-mooney | since you are on shared stoarge however you need to ensure the vm is stoped and the compute service is disabled before you do the evacuate | |
| 15:37:35 | spatel | oh wait compute service disabled? | |
| 15:38:34 | sean-k-mooney | you cant evacuate form a host where the compute service is enabled | |
| 15:38:49 | sean-k-mooney | spatel: if the compute node is healty then you should jsut do a cold migration | |
| 15:39:05 | sean-k-mooney | cold migration wtih cpu pinning works as intended | |
| 15:39:16 | spatel | and cold migration support CPU-pining and hugepage | |
| 15:39:21 | sean-k-mooney | yep | |
| 15:39:52 | sean-k-mooney | for cold migration we generate a new xml on the destintion node so it works correctly | |
| 15:41:20 | sean-k-mooney | the bug for livemigration is while we caulate a new toplogy for the destination node we dont regenerate teh xml so we move teh vm bug still pin it as if it was on the souce node as we are using the xml form the source node instead of generating a new one for the destination node | |
| 16:35:43 | adrianc | Hi, any chance I can bother one of the fine cores here for a review for a FUP https://review.opendev.org/#/c/659101/ , already has a +2 from stephenfin :) | |
| 16:36:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Clean up test_virtapi https://review.opendev.org/667419 | |
| 16:36:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VirtAPI.update_compute_provider_status https://review.opendev.org/668706 | |
| 16:36:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: manage COMPUTE_STATUS_DISABLED for hypervisor connection https://review.opendev.org/668707 | |
| 16:45:20 | efried | adrianc: done | |
| 16:45:31 | efried | except for the "fine" part | |
| 16:47:50 | openstackgerrit | Merged openstack/nova-specs master: Re-propose the spec to allow specifying a list of CPU models https://review.opendev.org/642030 | |
| 16:51:37 | sean-k-mooney | jaypipes: hehe that was an old pull request :) | |
| 16:56:56 | jaypipes | sean-k-mooney: lol, doing some housecleaning :) | |
| 17:02:56 | efried | jroll: you back today? | |
| 17:08:40 | openstackgerrit | sean mooney proposed openstack/nova-specs master: add libvirt pqos spec https://review.opendev.org/662264 | |
| 17:08:49 | sean-k-mooney | lyarwood: ^ is the updated versions | |
| 17:13:52 | sean-k-mooney | hum looks like i need to fix the diagram | |
| 17:14:10 | jroll | efried: yep, hi! | |
| 17:14:21 | efried | jroll: Wanna talk TPM? | |
| 17:14:37 | jroll | efried: gimme 15, in a meeting atm | |
| 17:14:40 | efried | sho | |
| 17:14:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955 | |
| 17:14:51 | efried | I await thy ping | |
| 17:20:19 | gibi | efried, mriedem: I think I'm done with the heal port allocation rework based on your comments. (except two change in a followup) | |
| 17:20:26 | efried | ack | |
| 17:24:13 | openstackgerrit | sean mooney proposed openstack/nova-specs master: add libvirt pqos spec https://review.opendev.org/662264 | |
| 17:24:46 | sean-k-mooney | ok fixed the ascii diagram | |
| 17:28:19 | openstackgerrit | Merged openstack/nova master: Un-safe_connect and publicize get_providers_in_tree https://review.opendev.org/668062 | |
| 17:30:56 | jroll | efried: am free now | |
| 17:31:02 | efried | o/ | |
| 17:31:24 | efried | So what do you know about this "reboot required" business? I was able to confirm that from several sources. | |
| 17:31:44 | sean-k-mooney | im going to go have food so ill be away for the next hour or so. ill be back later | |
| 17:31:51 | sean-k-mooney | efried: reboot requried? | |
| 17:31:54 | efried | And are you caught up with what penick was saying about "oh, just leave it to us to manage the state of the TPM" | |
| 17:32:11 | efried | sean-k-mooney: talking to jroll about TPM stuff. Go do your food thing :) | |
| 17:33:09 | jroll | efried: I wasn't aware a hypervisor reboot was required until you were. and I think I'm caught up with penick? | |
| 17:33:21 | sean-k-mooney | oh im guessing after a guest has finished using a tpm and we delete teh guest the TPM is unaviaoble until after a reboot? and yep its time for breakfest/lunch/dinner brb | |
| 17:33:54 | efried | correct sean-k-mooney. Either unavailable, or still has the old VM's secrets in it. | |
| 17:34:46 | efried | jroll: So what penick is saying, IIUC, is that we should blindly pass the TPM through, and worry about the orchestration layer to know what's on it at any given time. I.e. nova doesn't do any prep or checking or clearing or ownership assigning. | |
| 17:35:15 | efried | That sounds like a pretty big security risk to me. Kind of doubt it's going to fly, design-wise, with the Nova maintainers. | |
| 17:35:16 | dansmith | how is that not a terrible idea? | |
| 17:35:21 | efried | yeah | |
| 17:35:34 | dansmith | I mean, I get that it's the minimum required effort to get what you want, but... | |
| 17:35:39 | dansmith | doesn't seem like a smart decision at all | |
| 17:36:27 | jroll | right, it seems like our use case would be long-running VMs | |
| 17:36:40 | sean-k-mooney | efried: that is not too unsuerpising. older gpus had the same issue. unless the uefi firmware is specificlay coded to handel it pci passthou deveice can become unusable until they are reset ususally that reuires a host reboot. | |
| 17:36:40 | jroll | and/or these hosts would only be accessible by this tenant | |
| 17:36:51 | sean-k-mooney | and now that i have my phone back to cooking | |
| 17:37:30 | jroll | I'm not sure I agree that we should just let nova blindly land stuff on a TPM without checking it, fwiw | |
| 17:38:35 | jroll | I haven't thought through what it would take to have nova track if a TPM is 'usable' or not | |
| 17:38:36 | efried | Right. That's Nova abdicating a pretty serious burden of responsibility to the unknown upper layer. I mean, we have trust models in place that are a certain shape and this really seems to be breaking outside of that shape. | |
| 17:38:59 | efried | so given that that approach is likely to be -many, unless there's some other place we can go with this, we're probably going to have to declare it dead in the water. (aka "downstream it if you really need it") | |
| 17:39:36 | dansmith | I'd like to see more uses for it | |
| 17:39:54 | jroll | I assume assigning some sort of TPM_DIRTY trait isn't going to fly, right? | |
| 17:40:06 | dansmith | while I feel for the situation of trying to push people to vms by providing things that look like hardware, the "single long-lived vm per host" use case doesn't hold much weight for me | |
| 17:40:46 | efried | jroll: If we were going to remove it from service via placement-ism, we would probably use the reserved=total trick. | |
| 17:40:54 | efried | rather than a trait | |
| 17:41:20 | jroll | dansmith: that's fair. the reason we would do this on a VM instead of bare metal is for neutron security groups, boot from volume, etc | |
| 17:41:39 | efried | (and btw, implied in your question and my response is: one RP per TPM) | |
| 17:41:53 | dansmith | but we also need to know how to clean it and I think that depending on placement as a persistence mechanism for something like this is an abuse.. it'd be too easy for an operator to just delete that allocation not knowing why it's there, only to have us hand the tpm to something else | |
| 17:42:04 | jroll | or rather, that's why the "single long-lived vm per host" is a somewhat valid use case for us | |
| 17:45:10 | jroll | efried: I guess I'm not deep enough in nova to offer suggestions on how to manage this, I'll have to dig around some and maybe come back and talk about it | |
| 17:45:37 | jroll | unless "tracking the state of the hyp" is 100% not going to happen for something like this | |