<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 January 2018 at 22:57, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/22/2018 8:22 AM, Lee Yarwood wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
With M3 and FF rapidly approaching this week I wanted to post a brief<br>
overview of the QEMU native LUKS series.<br>
<br>
The full series is available on the following topic, I'll go into more<br>
detail on each of the changes below:<br>
<br>
<a href="https://review.openstack.org/#/q/topic:bp/libvirt-qemu-native-luks+status:open" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/topic:bp/libvirt-qemu-nativ<wbr>e-luks+status:open</a><br>
<br>
libvirt: Collocate encryptor and volume driver calls<br>
<a href="https://review.openstack.org/#/c/460243/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/460243/</a> (Missing final +2 and +W)<br>
<br>
This refactor of the Libvirt driver connect and disconnect volume code<br>
has the added benefit of also correcting a number of bugs around the<br>
attaching and detaching of os-brick encryptors. IMHO this would be<br>
useful in Queens even if the rest of the series doesn't land.<br>
<br>
libvirt: Introduce disk encryption config classes<br>
<a href="https://review.openstack.org/#/c/464008/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/464008/</a> (Missing final +2 and +W)<br>
<br>
This is the most straight forward change of the series and simply<br>
introduces the required config classes to wire up native LUKS decryption<br>
within the domain XML of an instance. Hopefully nothing controversial.<br>
<br>
libvirt: QEMU native LUKS decryption for encrypted volumes<br>
<a href="https://review.openstack.org/#/c/523958/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/523958/</a> (Missing both +2s and +W)<br>
<br>
This change carries the bulk of the implementation, wiring up encrypted<br>
volumes during their initial attachment. The commit message has a<br>
detailed run down of the various upgrade and LM corner cases we attempt<br>
to handle here, such as LM from a P to Q compute, detaching a P attached<br>
encrypted volume after upgrading to Q etc.<br>
<br>
Upgrade and LM testing is enabled by the following changes:<br>
<br>
fixed_key: Use a single hardcoded key across devstack deployments<br>
<a href="https://review.openstack.org/#/c/536343/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/536343/</a><br>
<br>
compute: Introduce an encrypted volume LM test<br>
<a href="https://review.openstack.org/#/c/536177/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/536177/</a><br>
<br>
This is being tested by tempest-dsvm-multinode-live-mi<wbr>gration and<br>
grenade-dsvm-neutron-multinode<wbr>-live-migration in the following DNM Nova<br>
change, enabling volume backed LM tests:<br>
<br>
DNM: Test LM with encrypted volumes<br>
<a href="https://review.openstack.org/#/c/536350/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/536350/</a><br>
<br>
Hopefully that covers everything but please feel free to ping if you<br>
would like more detail, background etc. Thanks in advance,<br>
<br>
Lee<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</blockquote>
<br>
The patch is already approved, and I asked melwitt to write a release note, at which point it was noted that swap volume will not work with native luks encrypted volumes. That's a regression.<br></blockquote><div><br></div><div>It's only a regression since swap_volume with encrypted volumes was fixed in <a href="https://review.openstack.org/#/c/460243/">https://review.openstack.org/#/c/460243/</a>, which landed on Monday as part of this series. Prior to Monday, swap_volume with encrypted volumes would result in the raw encrypted volume being presented to the guest after the swap.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We need to at least report a nova bug for this so we can work on some kind of fallback to the non-native decryption until there is a libvirt/qemu fix upstream and we can put version conditionals in place for when we can support swap volume with a native luks-encrypted volume.<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>In the context of the above, I don't think this is a priority as clearly nobody is currently doing it. There's already a bug to track the problem in libvirt, which is linked in a code comment. Admittedly that BZ is unnecessarily private, which I noted in review, but we've reached out to the author to ask them to open it up as there's nothing sensitive going on in there.<br><br>In general, anything qemu can do natively makes Nova both simpler and more robust because we don't have to modify the host configuration. This eliminates a whole class of error states and race conditions, because when we kill qemu there's nothing left to clean up.<br><br></div><div>Matt<br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">Matthew Booth</span><br></div><div>Red Hat OpenStack Engineer, Compute DFG</div><div><br></div><div>Phone: +442070094448 (UK)</div><div><br></div></div></div></div></div></div></div>
</div></div>