Re: [Libvir] Inconsistent networking between Xen & QEMU
On Fri, 2007-03-09 at 14:40 +0000, Daniel P. Berrange wrote:
On Fri, Mar 09, 2007 at 02:27:02PM +0000, Mark McLoughlin wrote:
> On Fri, 2007-03-09 at 03:03 +0000, Daniel P. Berrange wrote:
>
> > Anyway, we now have two different syntaxes in the XML for defining what
> > is more or less the same thing which is a real PITA for the tools. It
> > is useful to have the distinct representations - one is for 'managed'
> > bridges, and the other is for 'unmanaged' bridges - we can do some
much
> > more interesting things with managed bridges.
>
> As I said in another mail, the way I'd imagined virt-install working
> would be that by default it would connect guest NICs to the default
> network (i.e. not the bridge associated with the default network), but
> you could still use --bridge to explicitly connect the guest to a
> bridge. And we'd have a --network option.
I think we need to explore this a little further - the APIs for virtual
networks are very nice froma tools POV because we can trivially enumerate
networks & connect VMs to them. Its not pleasent to have to enumerate the
regular non-virtual network devices using a different set of APIs - indeed
its impossible if we're talking to a remote libvirt. So I think we need to
look at also exposing the 'shared physical device' style networks via the
libvirt APIs too.
Took me a second to understand you, but what I'm saying implies a
dialog like:
---
Add Virtual Network Interface:
Mac Address : [ ]
Connect to:
* Network : [ Default ]
* Physical Interface : [ eth0 ]
---
And your point is that in order to populate the latter dropdown list,
you need to use a sucky API which doesn't work in the remote case.
Rather you suggest that if people want to use bridging, then they
should modify the default network XML config by hand and not have the
latter option in the UI?
I dunno, the concept of "connect the guest to a physical network"
should be in the UI IMHO, and if you do then you need a list of physical
interfaces ...
This could be expressed with something like:
<network>
<name>default</name>
<bridge name="virbr0" />
<device name="eth0" />
</network>
Which would setup a virbr0 bridge,and enslave eth0 to it. It would assume
that the network eth0 is connected to has DHCP already, so there's no need
to define an IP for the bridge itself, or run dnsmasq in this case.
Yeah, it's like taking your virtual netgear router, turning off IP
forwarding and DHCP and enabling bridging.
That introduces this user visible notion of a bridge vs. a router,
which is just horrible. But, I guess you're saying you wouldn't have it
in the UI.
Is it actually possible to take an already configured eth0 device
and
enslave it to virbr0 without eth0 loosing its address config/routes ?
Well, where would the address from eth0 go if you had an ip address
configured for the network already? It would have to be an either or
thing then ...
Also, what if you try and bridge multiple networks out over the
physical interface?
That's why I'm suggesting that if you want to bridge guests over a
physical interface, then you need to change the interfaces configuration
so that it's "shared" ... which in effect, makes it a bridge which you
can add guest's backend interfaces too.
...
I guess it all comes down to two options:
a) Expose, in the UI, the concept of "either connect the guest to a
virtual network or to a shared physical interface" or
b) Make it an admin decision, not available in the UI, whether the
default network is a private network or bridged to a physical
interface
I prefer a), but I can see the argument for b).
If we have this kind of support could we auto-generate network
configs at
runtime based on any bridge/network device the adminsitrator has already
manually configured via /etc/sysconfig/networking-scripts ?
Not really following ...
Cheers,
Mark.