Re: [RFC] Linux-VServer support

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

 



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 :-)

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

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

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]