[Libvir] Inconsistent networking between Xen & QEMU
by Daniel P. Berrange
In Xen it is possible to configure a VIF to enslave with an arbitrary
bridge device using a fragment of XML like:
<interface type='bridge'>
<source bridge='xenbr0'/>
<mac address='00:16:3E:66:94:9C'/>
</interface>
In this example I've enslaved to xenbr0 which is created by the Xen networking
script, but this will work with any bridge device really.
In QEMU the only bridging is available via the 'virtual networks' support
in libvirt, by referencing a named bridge. For example
<interface type='network'>
<source network='default'/>
<mac address='00:16:3E:66:94:9C'/>
</interface>
Now 'default' is merely defined to be backed by a bridge device 'virbr0'
(although it does not neccessary get backed by a bridge) so the basic
impl is basically just enslaving a TAP device.
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.
To improve life for the tools though I'd like to do two things as a high
priority
- Support managed networks in Xen - we can simply lookup the bridge
device associated with a network and tell Xen to use vif-bridge with
this device. For the reverse Xen will tell us what bridge device a
guest is using, and we can reverse lookup the corresponding network
- Support non-managed networks in QEMU - we can simply enslave the
QEMU tap device to an arbitrary user specific bridge device.
Until one of these two options is done, its going to be a PITA to support
networking across QEMU & Xen in virt-manager/virt-install.
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 -=|
17 years, 9 months
[Libvir] [PATCH] Add a default network
by Mark McLoughlin
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.
17 years, 9 months
[Libvir] Restarting of libvirt_qemud daemon
by Daniel P. Berrange
Thinking about later RPM upgrades I think we need to think about whether it
will be possible to restart the libvirt_qemud while guests & networks are
running. There's a couple of issues:
- We do waitpid() to cleanup qemu & dnsmasq processes when we stop domains
& networks, or to detect when they crash. For the former, we could may
they daemons to avoid waitpid() cleanup, but we'd still need waitpid to
be able to detect shutdowns. There is also the issue of enumerating
running instances.
- We always try to re-create a bridge device at startup, even if it already
exists. Likewise we always try to add the IPtables rules & start dnsmasq.
We can easily detect if the bridge already exists. I think we can probably
double check iptables rulles too., The tricky one is figuring out whether
a dnsmasq instance is still running.
Dealing with theses not only helps planned restarts, but will also make it
possible start up the daemon again after a crash without having to kill off
all guests & networks manually. So I think it is worth investigating what
we can do to enable restarts. It might be worth waiting until we sort out
whether we'll merge libvirt_qemud with the generic libvirtd remote daemon
though so we don't have to do the work twice over.
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 -=|
17 years, 9 months
[Libvir] Stable UUID needed for default network
by Daniel P. Berrange
The UUID for the default network is not included in the example default
config. So every time you restart the libvirt_qemud we get a randomly
generated UUID. This isn't really in keeping with the idea of having a
permanent UID :-) So I think we need to do two things:
- In the 'make install' routine - if-and-only-if the
$prefix/etc/libvirt/networks/default.xml
file was newly installed, then stuff a random UUID into it, eg
UUID=`uuidgen`
sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \
$prefix/etc/libvirt/networks/default.xml
If the system doesn't have uuidgen, we can just ignore this step
- In the RPM %post section we need to stuff in a UUID at install time
if-and-only-if this is a new install - ie leave it alone during upgrades
UUID=`uuidgen`
sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \
%(sysconfdir)/libvirt/networks/default.xml
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 -=|
17 years, 9 months
[Libvir] Alternate dnsmasq command line args ?
by Daniel P. Berrange
Currently we launch dnsmasq with a command line looking like:
dnsmasq --keep-in-foreground
--bind-interfaces
--pid-file
--conf-file
--except-interface lo
--listen-address 192.168.122.1
--dhcp-range 192.168.122.2,192.168.122.254
This causes DNSMASQ to listen on any network interface configured with
an IP address of '192.168.122.1', except for loopback.
I know it would be kind of unusual, but it is possible two interface
might be both configured with the same address. I think it may be
safer if we explicitly tell it to use virbr0 instead eg
--interface virbr0
--except-interface lo
Yes, the --except-interface lo is still needed due to wierd ass dnsmasq
rules which make it always use loopback unless you tell it not to.
I'm also not clear why we use --conf-file - we're not actually telling it
about any config file so this seems redundant ?
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 -=|
17 years, 9 months
[Libvir] Generate python binding for network APIs
by Daniel P. Berrange
I was about to make use of the new networking APIs in virt-manager/virt-install
when I discovered we don't have any python binding for it. Attached is the
quickest patch I could write to support it - I basically copied all the
virDomain related bits & s/Domain/Network/ throughout. A simple demo script
works:
#!/usr/bin/python
import libvirt
con = libvirt.open(None)
n = con.listNetworks()
print str(n)
for name in n:
net = con.lookupByName(name)
print net.XMLDesc(0)
print net.bridgeName()
I think there are a couple more methods which need manual implementations
though - eg UUIDString() is generated incorrectly - in fact the UUIDString()
impl for virDomains is already broken, and so is the binding for VCPU
pinning.
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 -=|
17 years, 9 months
[Libvir] PATCH: Fix QEMU autostart/network behaviour
by Daniel P. Berrange
In my testing there appeared to be a couple of bugs with the QEMU driver
and the interaction with networking
- It was auto-starting the daemon even with qemu://system
- It was opening the QEMU connection twice due to inverted check, and
not opening it at all in the non-QEMU hv case.
- Once that is fixed, then it SEGVs when using a Xen connection
as uri->scheme is NULL
That attached patch rectifies those flaws - Mark can you double check this
just in case I've missed some edge case for the networking stuff - I have
strace'd virsh when doing
virsh list (as root & non-root)
virsh --connect test://default list (as root & non-root)
virsh --connect xen list (as root & non-root)
virsh --connect qemu://session list (as non-root)
virsh --connect qemu://system list (as root)
virsh --connect qemu://session --readonly list (as non-root)
virsh --connect qemu://system --readonly list (as root & non-root)
And it appears to now be making the correct connectiosn to the QEMU daemons
in all cases
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 -=|
17 years, 9 months
[Libvir] [PATCH] libvirt.c: warning: dereferencing type-punned pointer will break strict-aliasing rules
by Richard W.M. Jones
I'm currently trying to get libvirt to compile with -Werror. One
problem which came up early is the warning in $SUBJECT. The gcc info
page (see -fstrict-aliasing) is pretty unclear about what exactly causes
this problem, so the attached patch rewrites the code quite
conservatively to avoid the problem.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 9 months
[Libvir] [RFC] Check host's minimum memory.
by Masayuki Sunou
Hi
The minimum value of the memory guarded with virsh setmem is 4096KB(4MB).
In general, when host's memory is set to 4MB, the host stops.
Therefore, I propose the patch to which host's minimum value of the memory
is guarded by 256MB.
Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com>
Thanks,
Masayuki Sunou.
libvirt-0.2.0
--------------------------------------------------------------------------------
Index: libvirt/src/xend_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xend_internal.c,v
retrieving revision 1.97
diff -u -p -r1.97 xend_internal.c
--- libvirt/src/xend_internal.c 2 Mar 2007 20:19:08 -0000 1.97
+++ libvirt/src/xend_internal.c 6 Mar 2007 01:42:44 -0000
@@ -2243,6 +2243,9 @@ xenDaemonDomainSetMemory(virDomainPtr do
if (domain->id < 0 && domain->conn->xendConfigVersion < 3)
return(-1);
+ if (domain->id == 0 && memory < (256 * 1024))
+ return(-1);
+
snprintf(buf, sizeof(buf), "%lu", memory >> 10);
return xend_op(domain->conn, domain->name, "op", "mem_target_set",
"target", buf, NULL);
Index: libvirt/src/xm_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xm_internal.c,v
retrieving revision 1.14
diff -u -p -r1.14 xm_internal.c
--- libvirt/src/xm_internal.c 23 Feb 2007 08:51:30 -0000 1.14
+++ libvirt/src/xm_internal.c 6 Mar 2007 01:42:46 -0000
@@ -1025,6 +1025,9 @@ int xenXMDomainSetMemory(virDomainPtr do
if (domain->id != -1)
return (-1);
+ if (domain->id == 0 && memory < (256 * 1024))
+ return(-1);
+
if (!(filename = virHashLookup(nameConfigMap, domain->name)))
return (-1);
Index: libvirt/src/xs_internal.c
===================================================================
RCS file: /data/cvs/libvirt/src/xs_internal.c,v
retrieving revision 1.32
diff -u -p -r1.32 xs_internal.c
--- libvirt/src/xs_internal.c 23 Feb 2007 08:51:30 -0000 1.32
+++ libvirt/src/xs_internal.c 6 Mar 2007 01:42:46 -0000
@@ -434,6 +434,10 @@ xenStoreDomainSetMemory(virDomainPtr dom
}
if (domain->id == -1)
return(-1);
+
+ if (domain->id == 0 && memory < (256 * 1024))
+ return(-1);
+
snprintf(value, 19, "%lu", memory);
value[19] = 0;
ret = virDomainDoStoreWrite(domain, "memory/target", &value[0]);
--------------------------------------------------------------------------------
17 years, 9 months
[Libvir] [PATCH] export virConf* symbols (second version)
by Richard W.M. Jones
Second version of that patch.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
17 years, 9 months
