[Libvir] [RFC] Linux-VServer support

[Daniel Hokka Zakrisson]

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 
involved.

>> 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.
> 
> Dan.


-- 
Daniel Hokka Zakrisson