[Libvir] Inconsistent networking between Xen & QEMU

[Daniel P. Berrange]

On Fri, Mar 09, 2007 at 04:44:17PM +0000, Mark McLoughlin wrote:
> 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:
> > > 
> > > 	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.

Pretty much, yes.

> 	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?

How they configure the network XML is a completely separate issue - we could
easily have UI in virt-manager for creating/deleteing/editing networks in
the same way we have UI for creating/deleting/editing domains. So while today
they'd have to edit the XML to bridge to the physical network, that need only
be a short term issue.

> 	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 ...

So yes, we need list of physical interfaces / networks, in addition to the
existing list of virtual networks. Perhaps the same libvirt API can be
used to provide both listings, or maybe we need separate APIs. Even if
we used a single API at the libvirt level for listing virtual & physical
networks, we can have the option of displaying a dialog with the struture
you outline above - just key off some attribute in the XML to determine
whether to put a particular virNetworkPtr in the 'Network' drop down
vs the 'physical interface' drop down (or whatever they end up being called).


> > 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.

Just because the different bridge vs routed confoigs are represented in the
libvirt XML one way, doesn't force our hand in our we present it to the user.
Any network with a '<device name='eth0'> tag could be displayed in the 
'physical interfaces' drop down, while any without that tag would be
in the 'Network' drop down. My concerns at this stage are really about the
being able to use a consistent API in libvirt for everything we ever want to
do with networking, and not ever have to call out to non-libvirt APIs ourselves.

> > 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 ...

In my example I'm not configuring any address for the network - after initial
enslaving, the only device which would have an address would be eth0 which
preserved its address config from before it was enslaved. If that's possible -
i've not actually tested this theory ? I know Xen has horrible manual address
copying, but I figure that is only a result of the need to add in netloop.

> 	Also, what if you try and bridge multiple networks out over the
> physical interface?

That'd be impossible because eth0 can only be in one bridge at once - it
only really makes sense to bridge one network into any physical device in
any case. Semantically bridging multiple networks is just the same has 
having one larger network, so there'd be no point in trying to bridge
multiple networks into one physical device.

> 	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 ...

ie, if the user has create /etc/sysconfig/networking-scripts/ifcrg-br5 for
whatever reason, then we can automatically instantiate a network at the
libvirt level to represent this externally created network.

Semantically an admin creating arbitrary bridge devices with their regular
distro specific network init scripts is no different to libvirt createing
bridge devices. In both cases you end up with a bridge device, to which
you'd like to connect guests. In both cases you may or may not have a
physical interface enslaved in the bridge. So if the admin has created
some bridge device I'd like it to appear when doing 'virsh net-list'.

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  -=|