[Libvir] [PATCH] Add a default network

[Daniel P. Berrange]

On Mon, Feb 26, 2007 at 04:09:58PM +0000, Mark McLoughlin wrote:
> Hey,
> 	So, we want to install a default network which guests can connect to.
> This can be seen as e.g. a replacement for xenbr0 as the default bridge
> for xen guests.
> 
> 	A few things concern me about the patch, see below for my thinking.
> However, I'm happy to punt on all of these issues for now and  go ahead
> with the patch.
> 
>   1) Ordering - we want the default network to have a predictable bridge
>      name, so instead of relying on it being the first network and 
>      ending up auto-allocated vnet0, we use virbr0.
> 
>      The alternative is to actually have an ordering scheme, e.g.
> 
>        #define LIBVIRT_AUTOSTART_PRIORITY_DISABLE -1
>        #define LIBVIRT_AUTOSTART_PRIORITY_FIRST   0
>        #define LIBVIRT_AUTOSTART_PRIORITY_LAST    99
>        #define LIBVIRT_AUTOSTART_PRIORITY_DEFAULT 50
> 
>        int virNetworkSetAutostart(virDomainPtr domain,
>                                   int priority);
> 
>        autostart/00-default.xml -> ../default.xml
>        autostart/99-MyNetwork.xml -> ../MyNetwork.xml

I think its fine to let the ordering be done based on network name.
eg if the user wants an explicit ordering, then they can name
their network '00default', rather than us munging the names.

>      Maybe that's useful, but probably moreso for guests than networks. 
>      The "virbr0" solution is fine, IMHO.

Hmm, in guests more explicit dependancy info 'web1' requires 'db1',
except that this is pretty much an impossible problem to solve. eg, you
can start 'db1' first, but how do you know how long it takes for db1
to boot up & start accepting connections. So I think ordering is prety
much an impossible problem to solve in a generally useful case.

>   2) IP address choice - I've randomly chosen 192.168.122.1/24 as the 
>      IP address for the network, and this could happen to clash with
>      an existing network. Since we masquerade outgoing traffic, I think
>      the only problem this would cause in practice would be where the
>      host machine is already on a 192.168.122/24 subnet and it could 
>      find itself connecting to a guest rather than another machine on 
>      the physical subnet.

Picking a range like that is fine, if its easy for the admin to change
it in a config file - just need to make sure if the admin changes it
(or say wants to disable it entirely), it doesn't get reverted / renable
during an RPM upgrade. The former can be dealt with by marking %config,
but not sure how we'd prevent deletion of the default network being
reverted upon update.

>      If it did turn out to be a problem, I'd probably add something 
>      like:
> 
>        <ip type="auto" />
> 
>      But I'm not anxious to go down that route right now.

Thats really just moving the problem elsewhere - we'd just need another
config option somewhere else to spec what the 'auto' range mapped to.

>   3) UUID generation - there's no UUID specified, so the default 
>      network will have a different UUID across reboots.
> 
>      We could trivially save the UUID at first boot, but we'd really
>      need to put it in /var then.

Generate it in %post and write it into the config file ? That's the
approach DBus uses for its auto-generated UUID

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