[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] [RFC] Linux-VServer support

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.


Daniel Hokka Zakrisson

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]