[Libvir] Inconsistent networking between Xen & QEMU

[Mark McLoughlin]

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.