[Libvir] [RFC] Linux-VServer support
Daniel Hokka Zakrisson
daniel at hozac.com
Wed Oct 31 13:39:05 UTC 2007
Daniel Veillard wrote:
> On Wed, Oct 31, 2007 at 04:09:54AM +0000, 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
> Definitely, welcome aboard ! I'm just a bit worried that it's Yet
> Another Daniel in the project, confusion guaranteed :-)
Hehe, sorry about that ;-)
>> 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.
> I looked at the code, that seems clean but I have a concern about the
> overall XML format. Could you paste a couple of examples. Also I think
> Linux-VServer and OpenVZ kind of configuration may end up with the same
> kind of limitations or differences, so I would like to try to harmonize
> both format when possible.
Currently, the XML format is really limited. Are there any docs on what
should be there, or should I just look at the other drivers? As far as
harmonizing with the OpenVZ driver, I'm fine with that, but it seems to
be pretty limited and, to some degree at least, ugly.
Here's an example:
virsh # dumpxml etch
<domain type='vserver' id='40001'>
>>> 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.
> the scheduling side of the API is probably the part where it's the
> harder to keep a coherent access between hypervisors, that's the reason
> why Rich designed a very flexible mechanism but drivers should use some
> introspection by looking at parameters names to process them, and
> provide good error reporting.
> virsh command can certainly be improved as Dan suggested, yes.
> thanks for the patch, but let's discuss and fix the XML format before
> trying to finish and push that first version :-)
Daniel Hokka Zakrisson
More information about the libvir-list