Open Stack

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Friday, November 27, 2015 1:24 PM
> To: Koniszewski, Pawel
> Cc: OpenStack Development Mailing List (not for usage questions); ???; Feng,
> Shaohe; Xiao, Guangrong; Ding, Jian-feng; Dong, Eddie; Wang, Yong Y; Jin,
> Yuntong
> Subject: Re: [openstack-dev] [nova] [RFC] how to enable xbzrle compress for
> live migration
>
> On Fri, Nov 27, 2015 at 12:17:06PM +0000, Koniszewski, Pawel wrote:
> > > -----Original Message-----
> > > > > Doing this though, we still need a solution to the host OOM
> > > > > scenario problem. We can't simply check free RAM at start of
> > > > > migration and see if there's enough to spare for compression
> > > > > cache, as the schedular can spawn a new guest on the compute
> > > > > host at any time, pushing us into OOM. We really need some way
> > > > > to indicate that there is a (potentially very large) extra RAM
> > > > > overhead for the guest during
> > > migration.
> >
> > What about CPU? We might end up with live migration that degrades
> > performance of other VMs on source and/or destination node. AFAIK CPUs
> > are heavily oversubscribed in many cases and this does not help.
> > I'm not sure that this thing fits into Nova as it requires resource
> > monitoring.
>
> Nova already has the ability to set CPU usage tuning rules against each VM.
> Since the CPU overhead is attributed to the QEMU process, these existing
> tuning rules will apply. So there would only be impact on other VMs, if you
> do
> not have any CPU tuning rules set in Nova.

Not sure I understand it correctly, I assume that you are talking about CPU
pinning. Does it mean that compression/decompression runs as part of VM
threads?

If not then, well, it will require all VMs to be pinned on both hosts, source
and destination (and in the whole cluster because of static configuration...).
Also what about operating system performance? Will QEMU distinct OS processes
somehow and won't affect them?

Also, nova can reserve some memory for the host. Will QEMU also respect it?

I like all this stuff about XBZRLE, but in my understanding it is very
resource-sensitive feature.

Kind Regards,
Pawel Koniszewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6499 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151127/61c236af/attachment.bin>