Open Stack

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.

Thanks,
EJ

On Fri, Feb 23, 2018 at 8:32 AM Ricardo Aravena <raravena80 at gmail.com>
wrote:

> On Fri, Feb 23, 2018 at 5:55 AM, Tao Peng <bergwolf at hyper.sh> wrote:
>
>> On Fri, Feb 23, 2018 at 12:32 AM, Larrew, Jesse <Jesse.Larrew at amd.com>
>> wrote:
>> > 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.
>> >
>> > 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?
>> >
>> Yes. We have an optimization [1] based on the qemu live migration
>> feature which let us share the initial part of guest memory among
>> guests on the same host. It's a quite useful feature for vm-based
>> container workload because the kernel and initramfs are most likely
>> the same for all guests on the host.
>>
>
> My two cents here:
>
> 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.
>
>
>
>>
>> [1]:
>> https://github.com/hyperhq/qemu/commit/162b05b38ddb8505c209cf3c570d70c76427c8a5
>>
>> Cheers,
>> Tao
>>
>> > [1] Secure Encrypted Virtualization API v0.16:
>> > https://support.amd.com/TechDocs/55766_SEV-KM%20API_Specification.pdf
>> >
>> > Sincerely,
>> > Jesse
>> >
>> >> -----Original Message-----
>> >> From: Tao Peng [mailto:bergwolf at hyper.sh]
>> >> Sent: Thursday, February 22, 2018 5:15 AM
>> >> To: Larrew, Jesse <Jesse.Larrew at amd.com>
>> >> Cc: kata-dev at lists.katacontainers.io; Hollingsworth, Brent
>> >> <brent.hollingsworth at amd.com>; Kaplan, David <David.Kaplan at amd.com>;
>> >> Woller, Thomas <thomas.woller at amd.com>
>> >> Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization
>> (SEV)
>> >>
>> >> Hi Larrew,
>> >>
>> >> > I’m not familiar with qemu VM clone. Is there any documentation or
>> source
>> >> files I could browse to learn more?
>> >> >
>> >> Sorry I meant to say live migration instead of clone since qemu clone
>> is
>> >> mostly used to mean guest image cloning. Here is some background I can
>> find
>> >> online:
>> >> https://developers.redhat.com/blog/2015/03/24/live-migrating-qemu-kvm-
>> >> virtual-machines/
>> >>
>> >> Cheers,
>> >> Tao
>> >> --
>> >> bergwolf at hyper.sh
>>
>>
>>
>> --
>> bergwolf at hyper.sh
>>
>> _______________________________________________
>> kata-dev mailing list
>> kata-dev at lists.katacontainers.io
>> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>>
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180223/3bcf229e/attachment.html>