| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-11 | |||
| 07:36:01 | openstackgerrit | ya.wang proposed openstack/nova-specs master: Add spec for live migration no performance impact. https://review.opendev.org/693655 | |
| 07:38:48 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 09:46:28 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 12:47:00 | brinzhang | dansmith: efried: In nova PTG in Shanghai we talked about this spec https://review.opendev.org/#/c/663563/, and we reached the agreement on this feature, you can see ML/Etherpad https://etherpad.openstack.org/p/nova-shanghai-ptg http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010643.html | |
| 12:47:22 | jroll | efried: I don't have anything, may be able to get something but not sure it'll be simple :) this might be a reasonable starting point: https://github.com/tpm2-software/tpm2-tools/wiki/Getting-Started | |
| 12:47:44 | jroll | efried: if you don't like the looks of that, I can bug an expert here | |
| 12:48:00 | brinzhang | dansmith: efried: I was updated (re-write) this spec, please review again (there are -2 on it now) | |
| 13:38:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove TODO from ComputeTaskManager._live_migrate https://review.opendev.org/693696 | |
| 14:01:48 | Erdosip | Hy! | |
| 14:03:48 | Erdosip | I would like to investigate about CEPH multiple pool support in the same nova process.. AFAIK this is not supported now, since nova only able to use one RBD, but we would like to use multiple... Are there any technical problems with this, to implement? | |
| 14:04:43 | Erdosip | I would like to investigate about CEPH multiple pool support in the same nova process.. AFAIK this is not supported now, since nova only able to use one RBD pool, but we would like to use multiple... Are there any technical problems with this, to implement? | |
| 14:05:57 | Erdosip | (sorry, i thinked, i can edit my previous message...) | |
| 14:23:51 | mriedem | Erdosip: this is likely a better question for the openstack-discuss mailing list, tag the subject line with [nova] so it's filtered properly | |
| 14:24:11 | Erdosip | okay, thanks! | |
| 14:29:10 | sean-k-mooney | Erdosip: the only way to connect to multiple cephs form the same nova host today is via cinder today as far as i know | |
| 14:30:00 | sean-k-mooney | i dont know what it would take to support it with the rbd image backend but as mriedem says if you ask on the mailing list someone more familar with that may respond | |
| 14:33:21 | dansmith | brinzhang_: skimming your changes, it does not look like my core concerns are addressed, so I'll leave my -2 on there | |
| 14:52:01 | efried | brinzhang_: I'll look again | |
| 14:53:07 | efried | jroll: oh, nice, good link, will read. | |
| 14:54:11 | jroll | :) | |
| 14:55:07 | dansmith | Erdosip: I've planned to add a tiny bit of multiple-pool support to nova when glance becomes able to replicate images in multiple pools | |
| 14:55:54 | dansmith | Erdosip: but it would just be the ability to know about multiple pools, there'd still be one "primary" pool that nova tries to get everything into in order to use them | |
| 14:56:31 | efried | jroll: I've gotten to the point where I can create an encrypted vTPM. I had found another "hello world" type script out there. It runs seamlessly whether encrypted or not -- that is, afaict the encryption/decryption happens at the libvirt level, and is transparent from the perspective of the VM. | |
| 14:56:55 | jroll | \o/ | |
| 14:57:01 | jroll | efried: cool, that makes sense to me | |
| 14:57:10 | efried | There have been some points of awkwardness thus far, including the need to recycle the libvirtd service before it'll pick up the "secret" | |
| 14:57:15 | jroll | or rather, aligns with how I understood the encrypted vtpm bits | |
| 14:57:19 | jroll | eek | |
| 14:57:23 | efried | Which would kind of be ... yeah, eek. | |
| 14:57:49 | jroll | I hope that's an unintentional bug :) | |
| 14:57:51 | efried | I'm still playing; it may be the case that creating the secret via the API rather than CLI could circumvent that -- not sure. | |
| 14:58:30 | efried | but even then, I'm still worried about your security requirements being satisfied here. | |
| 14:59:06 | efried | You create a "secret" in libvirt and give it a value. And then you create the libvirt XML with the UUID of that secret. And... that's it. There never seems to be a need to retype that secret value. | |
| 14:59:23 | dansmith | efried: libvirt's cli is just an api client, in case you didn't know | |
| 14:59:32 | dansmith | efried: virsh is, I mean | |
| 14:59:43 | efried | dansmith: I figured, point being to do it from the same process as wants to use the secret | |
| 15:00:08 | efried | sorry, I wasn't clear on that: use the libvirt API from within nova, rather than me typing in the CLI for my PoC. | |
| 15:00:12 | jroll | efried: huh, yeah, I wonder where libvirt keeps that secret | |
| 15:00:22 | efried | jroll: well, it keeps it in a file in a directory. | |
| 15:00:30 | jroll | sigh. | |
| 15:00:34 | dansmith | efried: yeah and my point is virsh and nova look the same to libvirtd, which is the thing that manipulates the guests, xmls, etc | |
| 15:00:39 | jroll | the secret itself is in a file? | |
| 15:01:37 | sean-k-mooney | efried: ideally you would want to store the secret in the hosts tpm rather then on disk | |
| 15:01:51 | efried | dansmith: Okay, I think I understand what you're saying. There's just one libvirtd "server side" and it hears things the same way whether through API or virsh. | |
| 15:02:12 | dansmith | efried: virsh is just an api client like nova, but yes that's what I'm saying | |
| 15:02:13 | efried | jroll: Yes, the secret is in a file. Presumably the fact that said file is encrypted is the thing that makes this more "secure". | |
| 15:02:16 | sean-k-mooney | efried: ya kind of virsh is just like the nova client | |
| 15:02:33 | efried | sean-k-mooney: we're 100% virtual here, there is no TPM on the host. | |
| 15:02:33 | sean-k-mooney | all of the logic is implemetne in the libvirt deamon | |
| 15:02:46 | sean-k-mooney | efried: well there could be | |
| 15:02:54 | efried | for coding purposes, there isn't. | |
| 15:03:07 | efried | jroll: but the fact that it's just sitting around there on the disk means that your disk thief could just... boot up the VM? | |
| 15:03:22 | efried | and would then have to have root access to the VM I guess | |
| 15:03:55 | jroll | efried: the TPM state is in an encrypted file. there is a passphrase to decrypt the file, which we give to libvirt via `virsh secret-set-value` or the API. I'm wondering where libvirt stores that secret, is that also in a file? how does libvirt encrypt that file? (these are rhetorical questions, fwiw, digging now) | |
| 15:04:15 | sean-k-mooney | efried: shoudl we maybe look at barbican to store the secreat rather then libvirt | |
| 15:04:33 | sean-k-mooney | i havent really looked at how this worksin in libvirt yet | |
| 15:04:49 | sean-k-mooney | but ideally i think we dont want it sotred on the compute host right | |
| 15:05:00 | efried | jroll: I'm still not 100% on any of this, but my understanding is that libvirt uses whatever's in the "secret" to encrypt/decrypt the contents of the vTPM. | |
| 15:05:25 | efried | but once you've done the secret-set-value... that's it. | |
| 15:05:47 | jroll | efried: right, trying to figure out where "whatever's in the secret" is stored | |
| 15:05:51 | jroll | where/how | |
| 15:06:01 | sean-k-mooney | it might just be in memory | |
| 15:06:16 | sean-k-mooney | not everythin you do to a libvirt domain has to be stored to disk | |
| 15:06:30 | efried | -rw------- 1 root root 211 Nov 9 12:36 d3e91e0e-20a5-4f60-ae85-9c8bfed6939f.xml | |
| 15:06:30 | efried | -rw------- 1 root root 4 Nov 9 12:36 d3e91e0e-20a5-4f60-ae85-9c8bfed6939f.base64 | |
| 15:06:30 | efried | total 8 | |
| 15:06:30 | efried | stack@breakfast:~/nova$ sudo ls -l /etc/libvirt/secrets/ | |
| 15:06:30 | efried | jroll: | |
| 15:06:45 | jroll | oh goody | |
| 15:06:47 | jroll | thanks. | |
| 15:07:00 | sean-k-mooney | efried: is that encrypted or plain text? | |
| 15:07:10 | jroll | I'm gonna go find a table or three. definitely not to flip. | |
| 15:07:27 | efried | The .base64 is just the b64-encoded value of the passphrase I set | |
| 15:07:43 | efried | the XML is the XML chunk I started with. | |
| 15:07:46 | sean-k-mooney | so plain texted effectivly | |
| 15:07:56 | efried | yup | |
| 15:08:19 | efried | So I've been thinking of a model where we secret-set-value just long enough to boot the VM, then blow away the secret. | |
| 15:08:24 | sean-k-mooney | so you might as well not encrypt the tpm at that point | |
| 15:08:39 | lyarwood | that isn't passed as plain text to QEMU btw | |
| 15:08:42 | efried | ...assuming the tpm stays "unencrypted" while the domain is running. | |
| 15:08:54 | lyarwood | it's the same as with LUKS, it's encypted using the master key for the domain | |
| 15:08:56 | dansmith | efried: ahh, so... fake security then? :D | |
| 15:09:05 | efried | but .... what dansmith said. | |
| 15:09:09 | dansmith | heh | |
| 15:09:16 | efried | that doesn't seem like real security. | |
| 15:09:24 | Erdosip | I think it's under /etc/libvirt/security | |
| 15:09:27 | efried | I mean, I guess your disk thief would have to steal the disk while the VM is booting. | |
| 15:10:29 | sean-k-mooney | im not sure the vm woudl have to be running | |
| 15:10:44 | sean-k-mooney | there are cases were we leave the domain intact | |
| 15:10:52 | sean-k-mooney | such as a showdown form inside the vm | |
| 15:11:01 | sean-k-mooney | or suspend/pause | |
| 15:11:09 | sean-k-mooney | maybe even stop | |
| 15:11:31 | efried | sean-k-mooney: the secret in the domain xml is just the uuid of the secret. So presumably (hopefully) the decryption happens in-memory when the xml is loaded up to actually start the guest. | |
| 15:11:36 | sean-k-mooney | start calls power on which calls reboot which recreates the domain | |
| 15:12:20 | sean-k-mooney | sure but the issue is the secret is not encrypted on disk | |
| 15:12:29 | efried | so regardless of whether the domain xml is there or needs to be recreated, it's when the guest starts up that we would need the secret to be present. | |
| 15:12:53 | lyarwood | again, the secret isn't provided to QEMU as a plaintext string | |
| 15:13:01 | sean-k-mooney | efried: im wondering is there a way to pass it at that point and never save it to disk | |
| 15:13:27 | efried | lyarwood: but it's on disk in cleartext. (base-64 encoded, but effectively plaintext) | |
| 15:13:34 | sean-k-mooney | lyarwood: sure but efried just said it in /etc/libvirt/secrets/ and is just base64 encoded | |