Open Stack

On Fri, Nov 27, 2015 at 01:01:15PM +0000, Koniszewski, Pawel wrote:
> > -----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?

The compression runs in the migration thread of QEMU. This is not a vCPU
thread, but one of the QEMU emulator threads. So CPU usage policy set
against the QEMU emulator threads applies to the compression CPU overhead.

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

No, its not QEMU's job to respect that. If you want to reserve resources
for only the host OS, then you need to setup suitable cgroup partitions
to separate VM from non-VM processes. The Nova reserved memory setting
is merely a hint to the schedular - it has no functional effect on its
own.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|