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

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

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'>
    <param name='fill_rate1'>100</param>
    <param name='interval1'>1000</param>
    <param name='fill_rate2'>25</param>
    <param name='interval2'>1000</param>
    <param name='idle_time'>1</param>

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

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