[libvirt] Bridge interface and script
With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional? We use the bridge type with Solaris virtual NICs, and need to specify the correct script to use. Suggestions on how to fix this? Should I just add script handling to this net type? thanks john
On Fri, Jan 09, 2009 at 10:26:52PM +0000, John Levon wrote:
With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional?
That's intentional - if you want to use a generic network script then use the type=ethernet style of network config instead of type=bridge
We use the bridge type with Solaris virtual NICs, and need to specify the correct script to use.
Internally when sending the SEXPR to XenD for type=bridge, we do include the (script) argument automatically with a value 'vif-bridge'. Likewise when parsing the SEXPR into XML, we set the 'type=bridge' attribute if the script name is 'vif-bridge', otherwise we set type=ethernet to indicate a custom, admin defined networking setup.
Suggestions on how to fix this? Should I just add script handling to this net type?
If the Solaris VIF setup script isn't called 'vif-bridge', then we can just #ifdef the alternate name required for Solaris & everything else should just work Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jan 12, 2009 at 10:54:58AM +0000, Daniel P. Berrange wrote:
With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional?
That's intentional - if you want to use a generic network script then use the type=ethernet style of network config instead of type=bridge
OK, why? Is there a reason for this restriction?
Suggestions on how to fix this? Should I just add script handling to this net type?
If the Solaris VIF setup script isn't called 'vif-bridge', then we can just #ifdef the alternate name required for Solaris & everything else should just work
Nope, since we have at least two standard scripts that are usable. Also, this is a back-compat issue (presumably, even for Linux...) that I don't think we can avoid. regards john
On Mon, Jan 12, 2009 at 09:09:32PM +0000, John Levon wrote:
On Mon, Jan 12, 2009 at 10:54:58AM +0000, Daniel P. Berrange wrote:
With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional?
That's intentional - if you want to use a generic network script then use the type=ethernet style of network config instead of type=bridge
OK, why? Is there a reason for this restriction?
Take Xen on Linux as an example. There are 3 scripts that ship with Xen - vif-bridge - vif-route - vif-nat Only one of those scripts provides bridging of the VMs. There's no easy way for libvirt to determine which script is bridging the VM and which is doing something entirely different. So we have little practical choice but to determine type=ethernet vs type=bridge based on the name of the script.
Suggestions on how to fix this? Should I just add script handling to this net type?
If the Solaris VIF setup script isn't called 'vif-bridge', then we can just #ifdef the alternate name required for Solaris & everything else should just work
Nope, since we have at least two standard scripts that are usable. Also, this is a back-compat issue (presumably, even for Linux...) that I don't think we can avoid.
What's the functional difference between the scripts ? Converting from Xen -> SEXPR is the easy part - we can accept type=bridge and an arbitrary script name without, but when we go back in the other direction we need to be accurate about what we generate in the XML. We don't want to report type=bridge if the VM is in fact being setup with routed networking. Hence we have to check for certain known script names Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Jan 12, 2009 at 09:38:42PM +0000, Daniel P. Berrange wrote:
With current libvirt, it's not possible to specify a script for VIR_DOMAIN_NET_TYPE_BRIDGE. Is this just an oversight, or intentional?
That's intentional - if you want to use a generic network script then use the type=ethernet style of network config instead of type=bridge
OK, why? Is there a reason for this restriction?
Take Xen on Linux as an example. There are 3 scripts that ship with Xen
- vif-bridge - vif-route - vif-nat
Only one of those scripts provides bridging of the VMs. There's no easy way for libvirt to determine which script is bridging the VM and which is doing something entirely different. So we have little practical choice but to determine type=ethernet vs type=bridge based on the name of the script.
I'm not complaining about that. Although I would note that perhaps xend needs fixing to store the type instead of this guessing based on a script name. I'm complaining about the other direction, where it is ignoring my explicit XML: <interface type='bridge'> ... <script path='vif-vnic'/> ... </interface> This change has broken backwards compatibility - all installed domains are broken on Solaris!
Nope, since we have at least two standard scripts that are usable. Also, this is a back-compat issue (presumably, even for Linux...) that I don't think we can avoid.
What's the functional difference between the scripts ?
Different virtual NIC internals - one dedicates a NIC to the domain, the other is similar to ethernet bridging.
Converting from Xen -> SEXPR is the easy part - we can accept type=bridge
I think you mean XML not 'Xen' here?
and an arbitrary script name without, but when we go back in the other direction we need to be accurate about what we generate in the XML. We don't want to report type=bridge if the VM is in fact being setup with routed networking. Hence we have to check for certain known script names
First, you presumably have to default to bridged mode when you don't know the script name, since otherwise you've broken compatibility. And in that case, there shouldn't be anything wrong with allowing different script names for the bridge type. regards john
participants (2)
-
Daniel P. Berrange -
John Levon