<div><div dir="auto">Why would a large memory footprint server like Redis benefit from sharing memory with other kernels running on the box? I would expect it’s memory requirements to dwarf the savings.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">EJ</div><br><div class="gmail_quote"><div>On Fri, Feb 23, 2018 at 8:32 AM Ricardo Aravena <<a href="mailto:raravena80@gmail.com">raravena80@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 23, 2018 at 5:55 AM, Tao Peng <span><<a href="mailto:bergwolf@hyper.sh" target="_blank">bergwolf@hyper.sh</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Feb 23, 2018 at 12:32 AM, Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>> wrote:<br>
> Ah! Yes, live migration of encrypted guests is supported by the hardware. Qemu support is still being actively developed though. The details of migrating encrypted VMs are discussed in our Secure Encrypted Virtualization API [1]. Basically, the AMD Secure Processor re-encrypts and integrity-protects the guest memory into discrete "packets" that can be sent to the destination machine. The transport/integrity keys used for migration are ephemeral keys negotiated with the receiving machine using a Diffie-Hellman exchange.<br>
><br>
> Live migration is useful for VMs that need to be stateful. However, my impression of container use cases is that they are encouraged to be stateless. For stateless containers, it would most likely be quicker to simply throw away the container and start a new one on the destination machine. Do you have specific use cases that require the ability to migrate containers?<br>
><br>
Yes. We have an optimization [1] based on the qemu live migration<br>
feature which let us share the initial part of guest memory among<br>
guests on the same host. It's a quite useful feature for vm-based<br>
container workload because the kernel and initramfs are most likely<br>
the same for all guests on the host.<br></blockquote><div><br></div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>My two cents here:</div><div><br></div><div>It's also quite useful at a higher level when you are dealing with stateful services, that are not heavily containerized in prod yet. First ones that pop in my head are redis/memchached. Then there's also big data stateful type of dbs that require a lot memory, say Cassandra, or Scylla. </div></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1]: <a href="https://github.com/hyperhq/qemu/commit/162b05b38ddb8505c209cf3c570d70c76427c8a5" rel="noreferrer" target="_blank">https://github.com/hyperhq/qemu/commit/162b05b38ddb8505c209cf3c570d70c76427c8a5</a><br>
<br>
Cheers,<br>
Tao<br>
<br>
> [1] Secure Encrypted Virtualization API v0.16:<br>
> <a href="https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf" rel="noreferrer" target="_blank">https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf</a><br>
><br>
> Sincerely,<br>
> Jesse<br>
><br>
>> -----Original Message-----<br>
>> From: Tao Peng [mailto:<a href="mailto:bergwolf@hyper.sh" target="_blank">bergwolf@hyper.sh</a>]<br>
>> Sent: Thursday, February 22, 2018 5:15 AM<br>
>> To: Larrew, Jesse <<a href="mailto:Jesse.Larrew@amd.com" target="_blank">Jesse.Larrew@amd.com</a>><br>
>> Cc: <a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a>; Hollingsworth, Brent<br>
>> <<a href="mailto:brent.hollingsworth@amd.com" target="_blank">brent.hollingsworth@amd.com</a>>; Kaplan, David <<a href="mailto:David.Kaplan@amd.com" target="_blank">David.Kaplan@amd.com</a>>;<br>
>> Woller, Thomas <<a href="mailto:thomas.woller@amd.com" target="_blank">thomas.woller@amd.com</a>><br>
>> Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)<br>
>><br>
>> Hi Larrew,<br>
>><br>
>> > I’m not familiar with qemu VM clone. Is there any documentation or source<br>
>> files I could browse to learn more?<br>
>> ><br>
>> Sorry I meant to say live migration instead of clone since qemu clone is<br>
>> mostly used to mean guest image cloning. Here is some background I can find<br>
>> online:<br>
>> <a href="https://developers.redhat.com/blog/2015/03/24/live-migrating-qemu-kvm-" rel="noreferrer" target="_blank">https://developers.redhat.com/blog/2015/03/24/live-migrating-qemu-kvm-</a><br>
>> virtual-machines/<br>
>><br>
>> Cheers,<br>
>> Tao<br>
<span class="m_-1391979697752765179HOEnZb"><font color="#888888">>> --<br>
>> bergwolf@hyper.sh<br>
<br>
<br>
<br>
--<br>
bergwolf@hyper.sh<br>
<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</font></span></blockquote></div></div></div>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div></div>