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.
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.
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.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|