[Libvir] [RFC] Linux-VServer support
Hi, 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. 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? -- Daniel Hokka Zakrisson
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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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'> <name>etch</name> <uuid>c81f40f2-7e72-606d-7d07-097c1d56a5b5</uuid> <memory>500000</memory> <scheduler> <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> </scheduler> </domain>
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
-- Daniel Hokka Zakrisson
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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.
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
Here's an example: virsh # dumpxml etch <domain type='vserver' id='40001'> <name>etch</name> <uuid>c81f40f2-7e72-606d-7d07-097c1d56a5b5</uuid> <memory>500000</memory> <scheduler> <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> </scheduler> </domain>
I'm surprized there is no path or storage informations at all. Are the parameters for the scheduler all integers ? If you really never end up with an information set more structured than that then <scheduler fill_rate1='100' interval1='1000' fill_rate2='25' interval2='1000' idle_time='1'/> would probably be simpler. The question is would other kind of scheduler use more structured parameters ? Seems to me it's not the case and that ad-hoc parsing to convert {name, value} pairs would just work. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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.
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
Okay, I'll add the relevant pieces.
Here's an example: virsh # dumpxml etch <domain type='vserver' id='40001'> <name>etch</name> <uuid>c81f40f2-7e72-606d-7d07-097c1d56a5b5</uuid> <memory>500000</memory> <scheduler> <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> </scheduler> </domain>
I'm surprized there is no path or storage informations at all.
Right, that's all handled internally right now. There's a default path created when domainDefineXML is called.
Are the parameters for the scheduler all integers ? If you really never end up with an information set more structured than that then
<scheduler fill_rate1='100' interval1='1000' fill_rate2='25' interval2='1000' idle_time='1'/>
would probably be simpler. The question is would other kind of scheduler use more structured parameters ? Seems to me it's not the case and that ad-hoc parsing to convert {name, value} pairs would just work.
Actually, the same settings can be applied to the CPUs separately, e.g. <scheduler> <param name='fill_rate1'>100</param> <param name='interval1'>1000</param> <cpu id='0'> <param name='idle_time'>1</param> <param name='fill_rate2'>25</param> <param name='interval2'>1000</param> </cpu> </scheduler> should at some point be possible (it's not in the current patch).
Daniel
-- Daniel Hokka Zakrisson
On Wed, Oct 31, 2007 at 05:14:10PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
Are the parameters for the scheduler all integers ? If you really never end up with an information set more structured than that then
<scheduler fill_rate1='100' interval1='1000' fill_rate2='25' interval2='1000' idle_time='1'/>
would probably be simpler. The question is would other kind of scheduler use more structured parameters ? Seems to me it's not the case and that ad-hoc parsing to convert {name, value} pairs would just work.
Actually, the same settings can be applied to the CPUs separately, e.g. <scheduler> <param name='fill_rate1'>100</param> <param name='interval1'>1000</param> <cpu id='0'> <param name='idle_time'>1</param> <param name='fill_rate2'>25</param> <param name='interval2'>1000</param> </cpu> </scheduler> should at some point be possible (it's not in the current patch).
Hum, I see, first time I see such fine grained scheduling, good to know, thanks ! I still find that <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' idle_time='1' fill_rate2='25' interval2='1000'/> </scheduler> would be better than adding the arbitrary <param> element. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Oct 31, 2007 at 01:36:48PM -0400, Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 05:14:10PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
Are the parameters for the scheduler all integers ? If you really never end up with an information set more structured than that then
<scheduler fill_rate1='100' interval1='1000' fill_rate2='25' interval2='1000' idle_time='1'/>
would probably be simpler. The question is would other kind of scheduler use more structured parameters ? Seems to me it's not the case and that ad-hoc parsing to convert {name, value} pairs would just work.
Actually, the same settings can be applied to the CPUs separately, e.g. <scheduler> <param name='fill_rate1'>100</param> <param name='interval1'>1000</param> <cpu id='0'> <param name='idle_time'>1</param> <param name='fill_rate2'>25</param> <param name='interval2'>1000</param> </cpu> </scheduler> should at some point be possible (it's not in the current patch).
Hum, I see, first time I see such fine grained scheduling, good to know, thanks ! I still find that
<scheduler fill_rate1='100' interval1='1000'> <cpu id='0' idle_time='1' fill_rate2='25' interval2='1000'/> </scheduler>
would be better than adding the arbitrary <param> element.
I don't think so - it makes it harder for an app to process, since they need to know the nams of all the backend specific parameters in order to extract the attribute. By having individual <params> you can easily access them all with XPath - eg /domain/schedular/param/@name can give you a list of all param names very nicely. it also maps to the virSchedInfo data struct nicely 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 -=|
On Wed, Oct 31, 2007 at 05:43:47PM +0000, Daniel P. Berrange wrote:
On Wed, Oct 31, 2007 at 01:36:48PM -0400, Daniel Veillard wrote:
Actually, the same settings can be applied to the CPUs separately, e.g. <scheduler> <param name='fill_rate1'>100</param> <param name='interval1'>1000</param> <cpu id='0'> <param name='idle_time'>1</param> <param name='fill_rate2'>25</param> <param name='interval2'>1000</param> </cpu> </scheduler> should at some point be possible (it's not in the current patch).
Hum, I see, first time I see such fine grained scheduling, good to know, thanks ! I still find that
<scheduler fill_rate1='100' interval1='1000'> <cpu id='0' idle_time='1' fill_rate2='25' interval2='1000'/> </scheduler>
would be better than adding the arbitrary <param> element.
I don't think so - it makes it harder for an app to process, since they need to know the nams of all the backend specific parameters in order to extract the attribute. By having individual <params> you can easily access them all with XPath - eg /domain/schedular/param/@name can give you a list of all param names very nicely. it also maps to the virSchedInfo data struct nicely
I don't see what is nice with that approach. You the get a node set of attribute coming from different nodes, you need to scan the full tree to get them, then for each attribute you need to find out the value to get the parameter name, then you need to extract the value of the parent. What do you do then with attributes you don't know ? I think code which looks for the set of attributes it knows directly with something like '/domain/scheduler[1]/@fill_rate1' will go straight to the value from an XPath perspective, and make code more readable. But maybe I didn't understood your use case... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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.
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
<snip>
After looking at the various drivers, this is what I propose: <domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain> I realize this is not at all similar to what the OpenVZ driver does, but if necessary I could update that to use a similar scheme (though limited in testing). -- Daniel Hokka Zakrisson
On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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.
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
<snip>
After looking at the various drivers, this is what I propose:
<domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain>
That looks mostly fine to me except a few doubts about: - <scheduler> this is tuning and we need a global discussion about this we allowed something similar for OpenVZ but this need to be discussed more globally. - what are the ranges for the values of <container> elements and attributes <uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that. - some of the <ip> args are new, i.e. have no equivalent in existing config file uses: + family: that looks okay to me, is that mandatory ? Could that be guessed from one of the addresses given ? + address2: what does that mean ? I understand one IP address being served but since there is not really a notion of physical interface why attach 2 address instead of defining 2 <interface> ? + prefix: could you explain what this means ? if it's a netmask let's use something like netmask="255.255.255.0" instead of prefix="24"
I realize this is not at all similar to what the OpenVZ driver does, but if necessary I could update that to use a similar scheme (though limited in testing).
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel Would you give me a pointer about discussion of OpenVZ (scheduler parameter config)? I searched the ML archive but I cannot find the discussion. Thanks Atushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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.
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
<snip>
After looking at the various drivers, this is what I propose:
<domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain>
That looks mostly fine to me except a few doubts about: - <scheduler> this is tuning and we need a global discussion about this we allowed something similar for OpenVZ but this need to be discussed more globally. - what are the ranges for the values of <container> elements and attributes <uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that. - some of the <ip> args are new, i.e. have no equivalent in existing config file uses: + family: that looks okay to me, is that mandatory ? Could that be guessed from one of the addresses given ? + address2: what does that mean ? I understand one IP address being served but since there is not really a notion of physical interface why attach 2 address instead of defining 2 <interface> ? + prefix: could you explain what this means ? if it's a netmask let's use something like netmask="255.255.255.0" instead of prefix="24"
I realize this is not at all similar to what the OpenVZ driver does, but if necessary I could update that to use a similar scheme (though limited in testing).
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Nov 05, 2007 at 07:57:36PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
Would you give me a pointer about discussion of OpenVZ (scheduler parameter config)? I searched the ML archive but I cannot find the discussion.
some of it there http://www.redhat.com/archives/libvir-list/2007-July/msg00346.html for example
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
I don't think we added scheduler informations to OpenVZ format in the end but clearly that was discussed. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel Thank you for your information. Anyway, This mail is written in July. Does any progress exist? I am afraid that the discussion takes long time. Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Mon, Nov 05, 2007 at 07:57:36PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
Would you give me a pointer about discussion of OpenVZ (scheduler parameter config)? I searched the ML archive but I cannot find the discussion.
some of it there
http://www.redhat.com/archives/libvir-list/2007-July/msg00346.html for example
Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
I don't think we added scheduler informations to OpenVZ format in the end but clearly that was discussed.
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Nov 05, 2007 at 05:33:02AM -0500, Daniel Veillard wrote:
On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
After looking at the various drivers, this is what I propose:
<domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain>
That looks mostly fine to me except a few doubts about: - <scheduler> this is tuning and we need a global discussion about this we allowed something similar for OpenVZ but this need to be discussed more globally. - what are the ranges for the values of <container> elements and attributes <uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that. - some of the <ip> args are new, i.e. have no equivalent in existing config file uses: + family: that looks okay to me, is that mandatory ? Could that be guessed from one of the addresses given ?
Trivially - IPv4 is guarenteed to have a '.', and IPv6 is guarentted to have ':'.
+ address2: what does that mean ? I understand one IP address being served but since there is not really a notion of physical interface why attach 2 address instead of defining 2 <interface> ?
I'd go for multiple <ip> tags inside the single <interface> tag, because this works in scenario where ythe 2nd address is a different family, or needs a different prefix
+ prefix: could you explain what this means ? if it's a netmask let's use something like netmask="255.255.255.0" instead of prefix="24"
Prefix is now preferred nomenculture for what used to be called netmask. The use of netmask is impratical in IPv6 world. You can trivially convert between the two in an app if you need the legacy netmask. Basically, prefix refers to the number of bits in the address which are significant. eg, the number of bits set to 1, in the netmask. I'd add that 'interface' should be in a separate <targe> element for consistency, and 'type=vserver' is probably redundant. We typically use just type='ethernet' for a plain interface (ie one not bridged) <inteface type='ethernet'> <ip address="1.2.3.4" prefix='24'/> <target dev='eth0'/> </interface> <inteface type='ethernet'> <ip address="1.2.3.4" prefix='24'/> <ip address="dead:beef:dead:beed::1" prefix='48'/> <target dev='eth0'/> </interface> Regards, 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 -=|
On Mon, Nov 05, 2007 at 01:17:11PM +0000, Daniel P. Berrange wrote:
On Mon, Nov 05, 2007 at 05:33:02AM -0500, Daniel Veillard wrote:
On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
After looking at the various drivers, this is what I propose:
<domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain>
That looks mostly fine to me except a few doubts about: - <scheduler> this is tuning and we need a global discussion about this we allowed something similar for OpenVZ but this need to be discussed more globally. - what are the ranges for the values of <container> elements and attributes <uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that. - some of the <ip> args are new, i.e. have no equivalent in existing config file uses: + family: that looks okay to me, is that mandatory ? Could that be guessed from one of the addresses given ?
Trivially - IPv4 is guarenteed to have a '.', and IPv6 is guarentted to have ':'.
So maybe we can avoid that family selector
+ address2: what does that mean ? I understand one IP address being served but since there is not really a notion of physical interface why attach 2 address instead of defining 2 <interface> ?
I'd go for multiple <ip> tags inside the single <interface> tag, because this works in scenario where ythe 2nd address is a different family, or needs a different prefix
Agreed
+ prefix: could you explain what this means ? if it's a netmask let's use something like netmask="255.255.255.0" instead of prefix="24"
Prefix is now preferred nomenculture for what used to be called netmask. The use of netmask is impratical in IPv6 world. You can trivially convert between the two in an app if you need the legacy netmask.
Basically, prefix refers to the number of bits in the address which are significant. eg, the number of bits set to 1, in the netmask.
okay, makes sense, I'm just old fashionned :-) Let's use prefix then
I'd add that 'interface' should be in a separate <targe> element for consistency, and 'type=vserver' is probably redundant. We typically use just
unless within a vserver domain other kind of interfaces are possible, then yes that's redundant and can probably be avoided.
type='ethernet' for a plain interface (ie one not bridged)
<inteface type='ethernet'> <ip address="1.2.3.4" prefix='24'/> <target dev='eth0'/> </interface>
<inteface type='ethernet'> <ip address="1.2.3.4" prefix='24'/> <ip address="dead:beef:dead:beed::1" prefix='48'/> <target dev='eth0'/> </interface>
okay Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Thu, Nov 01, 2007 at 03:09:00AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
On Wed, Oct 31, 2007 at 02:39:05PM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
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. Harmonizing the XML formats shouldn't be that hard ... We discussed the OpenVZ format there http://www.redhat.com/archives/libvir-list/2007-July/msg00347.html and around there earlier: http://www.redhat.com/archives/libvir-list/2007-March/msg00193.html For network settings http://www.redhat.com/archives/libvir-list/2007-July/msg00366.html
<snip> After looking at the various drivers, this is what I propose:
<domain type='vserver' id='2000'> <name>testvm</name> <memory>500000</memory> <scheduler fill_rate1='100' interval1='1000'> <cpu id='0' fill_rate1='0'/> <cpu id='1' fill_rate1='250' interval1='1000' idle_time='1' fill_rate2='250' interval2='1000'/> </scheduler> <container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> <devices> <disk type='path' device='path'> <source path='/vservers/testvm'/> <target path='/'/> </disk> <disk type='block' device='path'> <source dev='/dev/hda4'/> <target path='/var'/> </disk> <disk type='path' device='path'> <source path='/home/testvm'/> <target path='/home'/> </disk> <interface type='vserver'> <ip family='IPv4' address='1.2.3.4' prefix='24' interface='eth0'/> </interface> <interface type='vserver'> <ip family='IPv4' address='4.3.2.1' address2='4.3.2.200' prefix='24' type='range'/> </interface> <interface type='vserver'> <ip family='IPv6' address='dead:beef:dead:beef::1' prefix='64' interface='eth0'/> </interface> </devices> </domain>
That looks mostly fine to me except a few doubts about: - <scheduler> this is tuning and we need a global discussion about this we allowed something similar for OpenVZ but this need to be discussed more globally.
Okay.
- what are the ranges for the values of <container> elements and attributes
I don't understand what this question means.
<uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that.
Ah, yes, I missed that. How about: <os> <type machine='i586'>vserver</type> <hostname>testvm</hostname> <release>2.6.12</release> <distribution method='debootstrap'>etch</distribution> </os>
- some of the <ip> args are new, i.e. have no equivalent in existing config file uses: + family: that looks okay to me, is that mandatory ? Could that be guessed from one of the addresses given ?
Yes.
+ address2: what does that mean ? I understand one IP address being served but since there is not really a notion of physical interface why attach 2 address instead of defining 2 <interface> ?
This is only valid for the type='range' IPs, meaning all addresses in the range address-address2 are assigned to the guest.
+ prefix: could you explain what this means ? if it's a netmask let's use something like netmask="255.255.255.0" instead of prefix="24"
I realize this is not at all similar to what the OpenVZ driver does, but if necessary I could update that to use a similar scheme (though limited in testing).
-- Daniel Hokka Zakrisson
On Tue, Nov 06, 2007 at 11:23:22AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote: [...]
<container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> [...] - what are the ranges for the values of <container> elements and attributes
I don't understand what this question means.
<uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that.
Ah, yes, I missed that. How about: <os> <type machine='i586'>vserver</type> <hostname>testvm</hostname> <release>2.6.12</release> <distribution method='debootstrap'>etch</distribution> </os>
Looks far better to me compared to other formats already in use, yes I guess that's fine. <release> still looks a bit weird to me because in an OS you may see an awful lot of different releases, and it's hard to guess what it is about (the linux kernel one ?) Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Tue, Nov 06, 2007 at 11:23:22AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote: [...]
<container> <uts hostname='testvm' machine='i586'/> <distribution method='debootstrap' release='etch'/> </container> [...] - what are the ranges for the values of <container> elements and attributes I don't understand what this question means.
<uts> seems to be OS metadata, we already have an <os> element in existing configs why not reuse that.
Ah, yes, I missed that. How about: <os> <type machine='i586'>vserver</type> <hostname>testvm</hostname> <release>2.6.12</release> <distribution method='debootstrap'>etch</distribution> </os>
Looks far better to me compared to other formats already in use, yes I guess that's fine. <release> still looks a bit weird to me because in an OS you may see an awful lot of different releases, and it's hard to guess what it is about (the linux kernel one ?)
Yeah, but it's not a very common option, so it is not going to be used very often (or at all). If you have another name that might describe it better (the OS-release, as per uname(2)), please let me know.
Daniel
-- Daniel Hokka Zakrisson
On Tue, Nov 06, 2007 at 11:23:22AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
Ah, yes, I missed that. How about: <os> <type machine='i586'>vserver</type> <hostname>testvm</hostname> <release>2.6.12</release> <distribution method='debootstrap'>etch</distribution> </os>
Do we really think boot strapping should be part of the domain description? It feels very wrong to me, because this isn't information describing a guest domain configuration. It is installation information. To me it makes more sense to keep that separate & just refer to the disk (or directory) where the results are. It could well be that we need new APIs to enumerate the list of available guest OS distributions (and the method of install, eg boot ISO, direct kenrel and initrd, or bootstrap). And perhaps an API for performing a bootstrap tasks against a disk volue (as managed by the storage APis we're developing). Regards, 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 -=|
Daniel P. Berrange wrote:
On Tue, Nov 06, 2007 at 11:23:22AM +0100, Daniel Hokka Zakrisson wrote:
Daniel Veillard wrote:
Ah, yes, I missed that. How about: <os> <type machine='i586'>vserver</type> <hostname>testvm</hostname> <release>2.6.12</release> <distribution method='debootstrap'>etch</distribution> </os>
Do we really think boot strapping should be part of the domain description? It feels very wrong to me, because this isn't information describing a guest domain configuration. It is installation information. To me it makes more sense to keep that separate & just refer to the disk (or directory) where the results are.
I totally agree, I don't think it belongs there either, but I just didn't see any alternative ;-)
It could well be that we need new APIs to enumerate the list of available guest OS distributions (and the method of install, eg boot ISO, direct kenrel and initrd, or bootstrap). And perhaps an API for performing a bootstrap tasks against a disk volue (as managed by the storage APis we're developing).
This sounds good to me, but it complicates matters by not having it available at define time. I guess that's workaroundable though.
Regards, Dan.
-- Daniel Hokka Zakrisson
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.
Dan.
-- Daniel Hokka Zakrisson
On Wed, Oct 31, 2007 at 02:24:58PM +0100, Daniel Hokka Zakrisson wrote:
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.
prefix the name with @ to say your accessing an attribute children instead of an element children e.g.: '/domain/@id' if XPath is the only real problem that can be solved easilly, grab me on IRC ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Oct 31, 2007 at 02:24:58PM +0100, Daniel Hokka Zakrisson wrote:
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.
Ok, well the virNetwork APIs have a pretty well defined semantics - It provides a bridge device in the host with an IP from admin defined range (typically IPv4 private range, but not restricted) - The bridge is connected to the public nework via NAT - Guest VMs have a tap device enslaved in the bridge which is connected to the emulated NIC inside the guest. - Guest NIC gets assigned an IP via DHCP Some container technologies enable each container to have private 'tap' style interfaces which are plumbed through to the host networking. If this is the case for VServer, then it would be possible to connect a VServer container to one or more of the libvirt virtual networks. In any case there is no need to implement the virNetwork* APIs specifically within the VServer driver to do the guest <-> network connectiion. The virNetwork* APIs are merely concerned with configuring & managing the bridge device in the host. The drivers take care of adding the tap device per guest themselves as part of the virDomainCreate/Start APis. 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 -=|
(Sorry about the resend, missed the list and DV the first time.) Daniel P. Berrange wrote:
On Wed, Oct 31, 2007 at 02:24:58PM +0100, Daniel Hokka Zakrisson wrote:
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.
Ok, well the virNetwork APIs have a pretty well defined semantics
- It provides a bridge device in the host with an IP from admin defined range (typically IPv4 private range, but not restricted) - The bridge is connected to the public nework via NAT - Guest VMs have a tap device enslaved in the bridge which is connected to the emulated NIC inside the guest. - Guest NIC gets assigned an IP via DHCP
Some container technologies enable each container to have private 'tap' style interfaces which are plumbed through to the host networking. If this is the case for VServer, then it would be possible to connect a VServer container to one or more of the libvirt virtual networks. In
No, everything is shared with the host, the guest is just restricted to a subset of the assigned IP addresses. We don't deal with interfaces at all, other than to bring up the necessary addresses on the right one when it's started (if requested).
any case there is no need to implement the virNetwork* APIs specifically within the VServer driver to do the guest <-> network connectiion. The virNetwork* APIs are merely concerned with configuring & managing the bridge device in the host. The drivers take care of adding the tap device per guest themselves as part of the virDomainCreate/Start APis.
Okay, so I'll just remove all of that.
Dan.
-- Daniel Hokka Zakrisson
participants (4)
-
Atsushi SAKAI -
Daniel Hokka Zakrisson -
Daniel P. Berrange -
Daniel Veillard