[Libvir] [RFC] Linux-VServer support
Daniel Hokka Zakrisson
daniel at hozac.com
Wed Oct 31 13:24:58 UTC 2007
Daniel P. Berrange wrote:
> On Tue, Oct 30, 2007 at 04:28:59PM +0100, Daniel Hokka Zakrisson wrote:
>> This is an initial stab at adding Linux-VServer support to libvirt.
>> There are still a couple of things missing, like scheduler support in
>> the XML parsing, and proper network support.
> Great to see interest in adding more drivers ! I've not had time to look
> at your patch in great detail yet, but I'll give some more detailed
> feedback in the next day or so. My first comment though - why the
> <xid>123</xid> field in the XML - the unique integer ID for a domain
> should really be in the 'id' attribute <domain id='123'>. There are a
> couple of other small XML format consistency issues like that to check
> up on.
Yeah, the only reason I did it with a separate element was that I really
don't know XPath, so I hadn't figured out how to get the id in that case.
> NB, in most cases there is no need to implement network support in each
> driver. The libvirt networking APIs happen to be implemented in the QEMU
> driver codebase, but they're not really dependant on QEMU - the same
> functionality is shared across all drivers. If you connect to the Xen
> hypervisor, libvirt will auto-magically hook up the networking APIs to
> go via the QEMU driver. The same should work OK for VServer without
> you needing todo anything special.
Well, Linux-VServer is different from most (all?) other virtualization
technologies in that we do IP isolation, rather than virtualizing the
network stack. This means that guests are merely limited to a subset of
the IP addresses assigned to the host, so there's no routing or bridging
>> I've got a few questions though. virsh's schedinfo hardcodes the
>> available options, should I be adding new ones there? Would better
>> introspection from getSchedulerType make this a non-issue? How do the
>> network domains interact and associate with the regular domains?
> Yes, the virsh schedinfo command is broken in this respect. Rather
> than hardcoding params, it should simply allow
> virsh schedinfo --set foo=bar --set wizz=123
> To determine the data types for each param, it can simply query the existing
> values with getSchedularInfo and then update them accordingly.
Daniel Hokka Zakrisson
More information about the libvir-list