10:44 a.m.
qemu in SLIRP mode offers DHCP services to the appliance. We don't
use them, but use a fixed IP address intead. This changes the
appliance to get its IP address using DHCP.
Note: This is only used when the network is enabled. dhclient is
somewhat slower, but the penalty (a few seconds) is only paid for
network users. We could consider using the faster systemd dhcp client
instead.
---
appliance/init | 9 +++------
appliance/packagelist.in | 1 +
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/appliance/init b/appliance/init
index 6d62338..d688a52 100755
--- a/appliance/init
+++ b/appliance/init
@@ -79,12 +79,9 @@ hwclock -u -s
ip addr add 127.0.0.1/8 brd + dev lo scope host
ip link set dev lo up
-ip addr add 169.254.2.10/16 brd + dev eth0 scope global
-ip link set dev eth0 up
-
-ip route add default via 169.254.2.2
-
-echo nameserver 169.254.2.3 > /etc/resolv.conf
+if grep -sq guestfs_network=1 /proc/cmdline; then
+ dhclient
+fi
# Scan for MDs.
mdadm -As --auto=yes --run
diff --git a/appliance/packagelist.in b/appliance/packagelist.in
index 276b4c2..4e93eaf 100644
--- a/appliance/packagelist.in
+++ b/appliance/packagelist.in
@@ -210,6 +210,7 @@ binutils
bzip2
coreutils
cpio
+dhclient
diffutils
dosfstools
e2fsprogs
--
2.0.4
10:44 a.m.
New subject: [PATCH 2/2] launch: libvirt: Use qemu-bridge-helper to implement a full network (RHBZ#1148012).
When using the libvirt backend, don't use the SLIRP. Use
qemu-bridge-helper via libvirt to give us a full network connection.
One consequence of this is that 'ping' works in virt-builder
--run-command.
Note unfortunately this does not fix virt-rescue (since it overrides
the default backend and uses 'direct' for various reasons).
---
src/launch-libvirt.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c
index 706ae38..50c3f9d 100644
--- a/src/launch-libvirt.c
+++ b/src/launch-libvirt.c
@@ -1236,6 +1236,19 @@ construct_libvirt_xml_devices (guestfs_h *g,
} end_element ();
} end_element ();
+ /* Connect to libvirt bridge virbr0 (see: RHBZ#1148012). */
+ if (g->enable_network) {
+ start_element ("interface") {
+ attribute ("type", "bridge");
+ start_element ("source") {
+ attribute ("bridge", "virbr0");
+ } end_element ();
+ start_element ("model") {
+ attribute ("type", "virtio");
+ } end_element ();
+ } end_element ();
+ }
+
} end_element (); /* </devices> */
return 0;
@@ -1617,27 +1630,6 @@ construct_libvirt_xml_qemu_cmdline (guestfs_h *g,
attribute ("value", tmpdir);
} end_element ();
- /* Workaround because libvirt user networking cannot specify "net="
- * parameter.
- */
- if (g->enable_network) {
- start_element ("qemu:arg") {
- attribute ("value", "-netdev");
- } end_element ();
-
- start_element ("qemu:arg") {
- attribute ("value", "user,id=usernet,net=169.254.0.0/16");
- } end_element ();
-
- start_element ("qemu:arg") {
- attribute ("value", "-device");
- } end_element ();
-
- start_element ("qemu:arg") {
- attribute ("value", VIRTIO_NET ",netdev=usernet");
- } end_element ();
- }
-
/* The qemu command line arguments requested by the caller. */
for (hp = g->hv_params; hp; hp = hp->next) {
start_element ("qemu:arg") {
--
2.0.4
11:21 a.m.
New subject: [PATCH 2/2] launch: libvirt: Use qemu-bridge-helper to implement a full network (RHBZ#1148012).
On Tue, Sep 30, 2014 at 04:44:05PM +0100, Richard W.M. Jones wrote:
When using the libvirt backend, don't use the SLIRP. Use
qemu-bridge-helper via libvirt to give us a full network connection.
One consequence of this is that 'ping' works in virt-builder
--run-command.
Note unfortunately this does not fix virt-rescue (since it overrides
the default backend and uses 'direct' for various reasons).
---
src/launch-libvirt.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c
index 706ae38..50c3f9d 100644
--- a/src/launch-libvirt.c
+++ b/src/launch-libvirt.c
@@ -1236,6 +1236,19 @@ construct_libvirt_xml_devices (guestfs_h *g,
} end_element ();
} end_element ();
+ /* Connect to libvirt bridge virbr0 (see: RHBZ#1148012). */
+ if (g->enable_network) {
+ start_element ("interface") {
+ attribute ("type", "bridge");
+ start_element ("source") {
+ attribute ("bridge", "virbr0");
+ } end_element ();
+ start_element ("model") {
+ attribute ("type", "virtio");
+ } end_element ();
+ } end_element ();
+ }
+
} end_element (); /* </devices> */
Looks fine for a default config. I wonder if there's mileage in having
a LIBGUESTFS_LIBVIRT_BRIDGE env variable to override virbr0 ?
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11:30 a.m.
New subject: [PATCH 2/2] launch: libvirt: Use qemu-bridge-helper to implement a full network (RHBZ#1148012).
On Wed, Oct 01, 2014 at 05:21:34PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 30, 2014 at 04:44:05PM +0100, Richard W.M. Jones wrote:
> When using the libvirt backend, don't use the SLIRP. Use
> qemu-bridge-helper via libvirt to give us a full network connection.
> One consequence of this is that 'ping' works in virt-builder
> --run-command.
>
> Note unfortunately this does not fix virt-rescue (since it overrides
> the default backend and uses 'direct' for various reasons).
> ---
> src/launch-libvirt.c | 34 +++++++++++++---------------------
> 1 file changed, 13 insertions(+), 21 deletions(-)
>
> diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c
> index 706ae38..50c3f9d 100644
> --- a/src/launch-libvirt.c
> +++ b/src/launch-libvirt.c
> @@ -1236,6 +1236,19 @@ construct_libvirt_xml_devices (guestfs_h *g,
> } end_element ();
> } end_element ();
>
> + /* Connect to libvirt bridge virbr0 (see: RHBZ#1148012). */
> + if (g->enable_network) {
> + start_element ("interface") {
> + attribute ("type", "bridge");
> + start_element ("source") {
> + attribute ("bridge", "virbr0");
> + } end_element ();
> + start_element ("model") {
> + attribute ("type", "virtio");
> + } end_element ();
> + } end_element ();
> + }
> +
> } end_element (); /* </devices> */
Looks fine for a default config. I wonder if there's mileage in having
a LIBGUESTFS_LIBVIRT_BRIDGE env variable to override virbr0 ?
Yes, I suspect it'll be better not to hard-code this.
Using libguestfs backend settings though :-)
http://libguestfs.org/guestfs.3.html#backend-settings
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
11:20 a.m.
On Tue, Sep 30, 2014 at 04:44:04PM +0100, Richard W.M. Jones wrote:
qemu in SLIRP mode offers DHCP services to the appliance. We
don't
use them, but use a fixed IP address intead. This changes the
appliance to get its IP address using DHCP.
Note: This is only used when the network is enabled. dhclient is
somewhat slower, but the penalty (a few seconds) is only paid for
network users. We could consider using the faster systemd dhcp client
instead.
Little known fact - the kernel has a built-in DHCP server.
I wonder if it is possible to use 'ip=dhcp' as a kernel boot
arg ? Apparently the kernel provides a /proc/net/pnp file which
you'd symlink to /etc/resolv.conf for DNS setup.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
2 p.m.
On Wed, Oct 01, 2014 at 05:20:28PM +0100, Daniel P. Berrange wrote:
On Tue, Sep 30, 2014 at 04:44:04PM +0100, Richard W.M. Jones wrote:
> qemu in SLIRP mode offers DHCP services to the appliance. We don't
> use them, but use a fixed IP address intead. This changes the
> appliance to get its IP address using DHCP.
>
> Note: This is only used when the network is enabled. dhclient is
> somewhat slower, but the penalty (a few seconds) is only paid for
> network users. We could consider using the faster systemd dhcp client
> instead.
Little known fact - the kernel has a built-in DHCP [client].
I wonder if it is possible to use 'ip=dhcp' as a kernel boot
arg ? Apparently the kernel provides a /proc/net/pnp file which
you'd symlink to /etc/resolv.conf for DNS setup.
Thinking about this for a while, I suspect we probably don't want to
use this. Long-running appliance instances ought to have a process
(dhclient) which constantly renews the lease, if only to stop another
client from taking the same IP address that we are using. Looking at
the kernel implementation, it does not do this. (In fact this is
potentially a bug for kickstarts etc.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
3519
days inactive
3520
days old
5 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Richard W.M. Jones