Re: [Libvir] [PATCH] Add a default network
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 -=|