[libvirt] [PATCH 00/17] Supports for hypervisor-pin and hypervisor-bandwidth

[Hu Tao]

On Tue, Aug 07, 2012 at 06:35:32PM +0100, Daniel P. Berrange wrote:
> On Tue, Aug 07, 2012 at 10:13:19AM -0600, Eric Blake wrote:
> > On 08/07/2012 09:47 AM, Daniel P. Berrange wrote:
> > > On Fri, Aug 03, 2012 at 02:36:02PM +0800, Hu Tao wrote:
> > >> This series is a merge of
> > >>
> > >>   1) "Support hypervisor-threads-pin in vcpupin"
> > >>      (https://www.redhat.com/archives/libvir-list/2012-July/msg01361.html)
> > >>   2) "support to set cpu bandwidth for hypervisor threads"
> > >>      (https://www.redhat.com/archives/libvir-list/2012-June/msg01161.html)
> > >>
> > >> to make life easier because of the two share some patches.
> > > 
> > > This series is really focusing on pinning threads associated
> > > with the <emulator> element, rather than the hypervisor. The
> > > hypervisor is a separate entity that is shared.
> > > 
> > > So I'm thinking that this entire patch series could replace
> > > 'hypervisor' with 'emulator' everywhere.  Any one has agree
> > > or disagree ?
> > 
> > I definitely agree - when I hear 'hypervisor', I think 'qemu:///system',
> > which is the technology used to run multiple guests, but when I hear
> > 'emulator', I think of a subset of a domain, namely the specific qemu
> > pid_t running a given guest.  Also, we're not pinning all of the
> > hypervisor's threads, but just the threads that are associated with
> > emulation but not a specific vcpu.
> > 
> > That is, marking up your comment in 1/17:
> > 
> > cgroup mount point
> > +--libvirt                <= setting up a namespace (*)
> >    +--qemu                <= hypervisor level
> >       +--domain name      <= domain level
> >          +--vcpu0         <= vcpu level
> >          ...
> >          +--vcpuN
> >          +--"hypervisor"  <= emulator
> > 
> > so a domain really is made up of an 'emulator' and 'vcpu' threads, and a
> > 'hypervisor' contains domains, rather than making up a portion of a domain.
> 
> Also note that LXC has an emulator "/usr/libexec/libvirt_lxc" for
> which all these new APIs apply, but the term 'hypervisor' is
> meaningless for container based virt.

Thank you for your advice on the naming. I'll change hypervisor into
emulator all through the series.

-- 
Thanks,
Hu Tao