Open Stack

Sorry, wasn't specific enough, I didn't mean sharing memory on same
physical box to improve performance by sharing bits. I meant live migration
in general from one physical machine to another (aka VMotion), in where you
could have a containerized Redis (in a VM) and move it to another machine
with minimal downtime.

A containerized Redis wouldn't benefit from another containerized instance
of Redis on the same machine unless they were replicas (which would defeat
the purpose of having replicas; you generally want them in different
datacenters) . Hope it helps.

Cheers,
Ricardo


On Fri, Feb 23, 2018 at 9:00 AM, EJ Campbell <ejc3 at oath.com> wrote:

> 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/53636d66/attachment.html>