4:26 p.m.
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
4:54 a.m.
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 :|
3:09 p.m.
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
3:38 p.m.
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 :|
4:26 p.m.
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
5793
days inactive
5796
days old
4 comments
2 participants
participants (2)
-
Daniel P. Berrange -
John Levon