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
Maybe that's useful, but probably moreso for guests than networks.
The "virbr0" solution is fine, IMHO.
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.
It's a default configuration choice which admins can change, and I
don't see it causing huge problems in practice, so I'm not overly
concerned.
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.
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.
IMHO, it's something we can fix later if it turns out to be
important.
Cheers,
Mark.