October 2015 - Devel - libvirt List Archives

[libvirt] [PATCH 0/5] qemu: Wait until destination QEMU consumes all migration data
by Jiri Denemark 06 Oct '15

06 Oct '15

Even though QEMU on the source host reports completed migration and thus we move to the Finish phase, QEMU on the destination host may still be processing migration data. Thus before we can start guest CPUs on the destination, we have to wait for a completed migration event. https://bugzilla.redhat.com/show_bug.cgi?id=1265902 Jiri Denemark (5): qemu: Always update migration times on destination qemu: Copy completed migration stats only on success qemu: Introduce flags in qemuMigrationCompleted qemu: Make updating stats in qemuMigrationCheckJobStatus optional qemu: Wait until destination QEMU consumes all migration data src/qemu/qemu_migration.c | 86 ++++++++++++++++++++++++++++++++++------------- 1 file changed, 63 insertions(+), 23 deletions(-) -- 2.6.0

2 11

[libvirt] [PATCH] tests: Check GIC-related XMLs in qemuxml2xmltest
by Martin Kletzander 06 Oct '15

06 Oct '15

Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- This is based on the GIC-support series from Pavel Fedin with the fixups mentioned there as well: https://www.redhat.com/archives/libvir-list/2015-September/msg01067.html .../qemuxml2argvdata/qemuxml2argv-aarch64-gic.xml | 30 +++++++++++++--------- .../qemuxml2argv-aarch64-gicv3.xml | 30 +++++++++++++--------- tests/qemuxml2xmltest.c | 3 +++ 3 files changed, 39 insertions(+), 24 deletions(-) diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic.xml index 08d3d714b8c2..cb595e4a7a6b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gic.xml @@ -1,26 +1,32 @@ -<domain type="qemu"> +<domain type='qemu'> <name>aarch64test</name> <uuid>6ba410c5-1e5c-4d57-bee7-2228e7ffa32f</uuid> - <memory>1048576</memory> - <currentMemory>1048576</currentMemory> - <vcpu>1</vcpu> - <features> - <acpi/> - <gic version='2'/> - </features> - <cpu match='exact'> - <model>cortex-a53</model> - </cpu> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> <os> - <type arch="aarch64" machine="virt">hvm</type> + <type arch='aarch64' machine='virt'>hvm</type> <kernel>/aarch64.kernel</kernel> <initrd>/aarch64.initrd</initrd> <cmdline>console=ttyAMA0</cmdline> + <boot dev='hd'/> </os> + <features> + <acpi/> + <gic version='2'/> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>cortex-a53</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <interface type='user'> <mac address='52:54:00:09:a4:37'/> + <model type='virtio'/> </interface> </devices> </domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml index f8d63c337755..72aaaf7fe5cd 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-aarch64-gicv3.xml @@ -1,26 +1,32 @@ -<domain type="qemu"> +<domain type='qemu'> <name>aarch64test</name> <uuid>6ba410c5-1e5c-4d57-bee7-2228e7ffa32f</uuid> - <memory>1048576</memory> - <currentMemory>1048576</currentMemory> - <vcpu>1</vcpu> - <features> - <acpi/> - <gic version='3'/> - </features> - <cpu match='exact'> - <model>cortex-a53</model> - </cpu> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> <os> - <type arch="aarch64" machine="virt">hvm</type> + <type arch='aarch64' machine='virt'>hvm</type> <kernel>/aarch64.kernel</kernel> <initrd>/aarch64.initrd</initrd> <cmdline>console=ttyAMA0</cmdline> + <boot dev='hd'/> </os> + <features> + <acpi/> + <gic version='3'/> + </features> + <cpu mode='custom' match='exact'> + <model fallback='allow'>cortex-a53</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu-system-aarch64</emulator> <interface type='user'> <mac address='52:54:00:09:a4:37'/> + <model type='virtio'/> </interface> </devices> </domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index eae153c5e763..5a9c67df7e02 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -625,6 +625,9 @@ mymain(void) DO_TEST("smbios-multiple-type2"); DO_TEST("aarch64-aavmf-virtio-mmio"); + DO_TEST("aarch64-gic"); + DO_TEST("aarch64-gicv3"); + DO_TEST("memory-hotplug"); DO_TEST("memory-hotplug-nonuma"); DO_TEST("memory-hotplug-dimm"); -- 2.6.0

2 1

[libvirt] [PATCH] conf: Remove <metadata> elements with no namespace
by Peter Krempa 06 Oct '15

06 Oct '15

Our docs state that subelements of <metadata> shall have a namespace and the medatata APIs expect that too. To avoid inaccessible <metadata> sub-elements, just remove those that don't conform to the documentation. Apart from adding the new condition this patch renames the function and refactors the code flow to allow the changes. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1245525 --- src/conf/domain_conf.c | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 29e55f2..65e0d8e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -3688,27 +3688,40 @@ virDomainDefRejectDuplicateControllers(virDomainDefPtr def) /** - * virDomainDefRemoveDuplicateMetadata: - * @def: Remove duplicate metadata for this def + * virDomainDefMetadataSanitize: + * @def: Sanitize metadata for this def * * This function removes metadata elements in @def that share the namespace. - * The first metadata entry of every duplicate namespace is kept. + * The first metadata entry of every duplicate namespace is kept. Additionally + * elements with no namespace are deleted. */ static void -virDomainDefRemoveDuplicateMetadata(virDomainDefPtr def) +virDomainDefMetadataSanitize(virDomainDefPtr def) { xmlNodePtr child; xmlNodePtr next; + xmlNodePtr dupl; if (!def || !def->metadata) return; - for (child = def->metadata->children; child; child = child->next) { + child = def->metadata->children; + while (child) { + /* remove metadata entries that don't have any namespace at all */ + if (!child->ns || !child->ns->href) { + dupl = child; + child = child->next; + + xmlUnlinkNode(dupl); + xmlFreeNode(dupl); + continue; + } + /* check that every other child of @root doesn't share the namespace of * the current one and delete them possibly */ next = child->next; while (next) { - xmlNodePtr dupl = NULL; + dupl = NULL; if (child->ns && next->ns && STREQ_NULLABLE((const char *) child->ns->href, @@ -3722,6 +3735,8 @@ virDomainDefRemoveDuplicateMetadata(virDomainDefPtr def) xmlFreeNode(dupl); } } + + child = child->next; } } @@ -3956,7 +3971,7 @@ virDomainDefPostParseInternal(virDomainDefPtr def, } /* clean up possibly duplicated metadata entries */ - virDomainDefRemoveDuplicateMetadata(def); + virDomainDefMetadataSanitize(def); return 0; } -- 2.4.5

2 2

[libvirt] [PATCH] apparmor: differentiate between error and unconfined profiles
by Cédric Bosdonnat 06 Oct '15

06 Oct '15

profile_status function was not making any difference between error cases and unconfined profiles. The problem with this approach is that dominfo was throwing an error on unconfined domains. --- src/security/security_apparmor.c | 30 +++++++++++++++++++++--------- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/src/security/security_apparmor.c b/src/security/security_apparmor.c index 16b8f87..2cf333d 100644 --- a/src/security/security_apparmor.c +++ b/src/security/security_apparmor.c @@ -66,10 +66,11 @@ struct SDPDOP { }; /* - * profile_status returns '-1' on error, '0' if loaded + * profile_status returns '-2' on error, '-1' if not loaded, '0' if loaded * - * If check_enforcing is set to '1', then returns '-1' on error, '0' if - * loaded in complain mode, and '1' if loaded in enforcing mode. + * If check_enforcing is set to '1', then returns '-2' on error, '-1' if + * not loaded, '0' if loaded in complain mode, and '1' if loaded in + * enforcing mode. */ static int profile_status(const char *str, const int check_enforcing) @@ -77,7 +78,7 @@ profile_status(const char *str, const int check_enforcing) char *content = NULL; char *tmp = NULL; char *etmp = NULL; - int rc = -1; + int rc = -2; /* create string that is '<str> \0' for accurate matching */ if (virAsprintf(&tmp, "%s ", str) == -1) @@ -100,6 +101,8 @@ profile_status(const char *str, const int check_enforcing) if (strstr(content, tmp) != NULL) rc = 0; + else + rc = -1; /* return -1 if not loaded */ if (check_enforcing != 0) { if (rc == 0 && strstr(content, etmp) != NULL) rc = 1; /* return '1' if loaded and enforcing */ @@ -262,6 +265,9 @@ use_apparmor(void) goto cleanup; rc = profile_status(libvirt_daemon, 1); + /* Error or unconfined should all result in -1*/ + if (rc < 0) + rc = -1; cleanup: VIR_FREE(libvirt_daemon); @@ -517,23 +523,29 @@ AppArmorGetSecurityProcessLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED, virSecurityLabelPtr sec) { int rc = -1; + int status; char *profile_name = NULL; if ((profile_name = get_profile_name(def)) == NULL) return rc; - if (virStrcpy(sec->label, profile_name, - VIR_SECURITY_LABEL_BUFLEN) == NULL) { + status = profile_status(profile_name, 1); + if (status < -1) { virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("error copying profile name")); + "%s", _("error getting profile status")); goto cleanup; + } else if (status == -1) { + profile_name[0] = '\0'; } - if ((sec->enforcing = profile_status(profile_name, 1)) < 0) { + if (virStrcpy(sec->label, profile_name, + VIR_SECURITY_LABEL_BUFLEN) == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, - "%s", _("error calling profile_status()")); + "%s", _("error copying profile name")); goto cleanup; } + + sec->enforcing = status == 1; rc = 0; cleanup: -- 2.1.4

2 1

Re: [libvirt] [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration
by Eduardo Habkost 06 Oct '15

06 Oct '15

On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote: > When a vcpu is created in KVM, its TSC rate is initially identical to > the host TSC rate. If its state is migrated to a vcpu on another > machine (target machine) which may uses a different host TSC rate, QEMU > on the target machine should notice KVM of the migrated vcpu's TSC > rate. In case that KVM on the target machine supports TSC scaling, guest > programs running on the migrated vcpu will observe the same TSC rate > before and after the migration. > > Signed-off-by: Haozhong Zhang <haozhong.zhang(a)intel.com> > --- > kvm-all.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/kvm-all.c b/kvm-all.c > index 0be4615..e8de038 100644 > --- a/kvm-all.c > +++ b/kvm-all.c > @@ -1769,6 +1769,19 @@ void kvm_cpu_synchronize_post_reset(CPUState *cpu) > static void do_kvm_cpu_synchronize_post_init(void *arg) > { > CPUState *cpu = arg; > + CPUX86State *env = &X86_CPU(cpu)->env; > + int r; > + > + /* > + * XXX: KVM_SET_TSC_KHZ must be done before kvm_arch_put_registers(). Could you explain where this requirement comes from? > + */ > + r = kvm_check_extension(cpu->kvm_state, KVM_CAP_TSC_CONTROL); > + if (r && env->tsc_khz) { > + r = kvm_vcpu_ioctl(cpu, KVM_SET_TSC_KHZ, env->tsc_khz); > + if (r < 0) { > + fprintf(stderr, "KVM_SET_TSC_KHZ failed\n"); > + } > + } This is duplicating the existing KVM_SET_TSC_KHZ call at kvm_arch_init_vcpu(). I wonder if there's a way to avoid this duplication. Should we set TSC KHz only at do_kvm_cpu_synchronize_post_init(), and remove the call from kvm_arch_init_vcpu()? Or maybe we shouldn't treat this as VM state, but as configuration, and let management configure the TSC frequency explicitly if the user really needs it to stay the same during migration. (CCing libvir-list to see if they have feedback) -- Eduardo

2 5

[libvirt] Cannot write data: Broken pipe when accesing libvirt from a forked process
by Josef Stribny 05 Oct '15

05 Oct '15

Hi all, I am trying to add vagrant-libvirt support for landrush plugin[0] and found out that libvirt fails for me with: Call to virConnectNumOfNetworks failed: Cannot write data: Broken pipe (Libvirt::RetrieveError) I created a minimal reproducer that causes this: ``` #!/usr/bin/ruby require 'libvirt' conn = Libvirt::open("qemu:///system") fork do puts conn.list_networks end puts conn.list_networks ``` This works just fine on my host, but fails on my virtualized guest (when using nested KVM). The journal shows the following lines in logs: Failed to acquire pid file '/run/user/1001/libvirt/libvirtd.pid': Resource temporarily unavailable So the forked process here tries to access not-existing libvirtd pid file for root (1001 on the VM). Is this a feature/bug? How can one avoid it? Thanks everyone Josef [0] https://github.com/phinze/landrush/pull/124

3 2

[libvirt] [sandbox v2 0/5] virt-builder source for virt-sandbox-image
by Cédric Bosdonnat 05 Oct '15

05 Oct '15

Hi all, Here is the new version of the virt-builder source with the download command removed and the format parameter too. Cédric Bosdonnat (5): virt-sandbox-image: remove the download command virt-image-sandbox: tarball extracting function to be reusable virt-sandbox-image: remove the format parameter virt-sandbox-image: automatically call create if needed virt-sandbox-image: add a virt-builder source libvirt-sandbox.spec.in | 1 + libvirt-sandbox/image/cli.py | 29 +++----- libvirt-sandbox/image/sources/DockerSource.py | 61 ++++++++-------- libvirt-sandbox/image/sources/Makefile.am | 1 + libvirt-sandbox/image/sources/Source.py | 29 ++++++-- libvirt-sandbox/image/sources/VirtBuilderSource.py | 84 ++++++++++++++++++++++ libvirt-sandbox/image/template.py | 2 + 7 files changed, 149 insertions(+), 58 deletions(-) create mode 100644 libvirt-sandbox/image/sources/VirtBuilderSource.py -- 2.1.4

3 11

[libvirt] CharUDP - Connection refused
by poma 05 Oct '15

05 Oct '15

Hi Fi With or without the patch[1] the same result - "Connection refused". UDP network console, the character device acts as a UDP netconsole service, sending and receiving packets. This is a lossy service. = HOST: virt-manager: Add New Virtual Serial Device Device Type: UDP net cosnole (udp) Host: 127.0.0.1 Port: 4555 Bind Host: Server mode (bind) Serial Device 1 (Primary Console) Device Type: udp Source host: 127.0.0.1:4555 Bind host: 127.0.0.1:4556 /etc/libvirt/qemu/domain.xml ... <serial type='udp'> <source mode='bind' host='127.0.0.1' service='4556'/> <source mode='connect' host='127.0.0.1' service='4555'/> <target port='0'/> </serial> <console type='udp'> <source mode='bind' host='127.0.0.1' service='4556'/> <source mode='connect' host='127.0.0.1' service='4555'/> <target type='serial' port='0'/> </console> qemu-system-x86_64 ... \ -chardev udp,id=charserial0,host=127.0.0.1,port=4555,localaddr=127.0.0.1,localport=4556 \ -device isa-serial,chardev=charserial0,id=serial0 # netstat -an | grep 4555 udp 0 0 127.0.0.1:4556 127.0.0.1:4555 ESTABLISHED # nc -vv -u 127.0.0.1 4555 Ncat: Version 6.47 ( http://nmap.org/ncat ) libnsock nsi_new2(): nsi_new (IOD #1) libnsock nsock_connect_udp(): UDP connection requested to 127.0.0.1:4555 (IOD #1) EID 8 libnsock nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [127.0.0.1:4555] Ncat: Connected to 127.0.0.1:4555. libnsock nsi_new2(): nsi_new (IOD #2) libnsock nsock_read(): Read request from IOD #1 [127.0.0.1:4555] (timeout: -1ms) EID 18 libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 26 libnsock nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 26 [peer unspecified] (1 bytes): . libnsock nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 35 [127.0.0.1:4555] libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 42 libnsock nsock_trace_handler_callback(): Callback: READ ERROR [Connection refused (111)] for EID 18 [127.0.0.1:4555] Ncat: Connection refused. # nc -vv -u 127.0.0.1 4556 Ncat: Version 6.47 ( http://nmap.org/ncat ) libnsock nsi_new2(): nsi_new (IOD #1) libnsock nsock_connect_udp(): UDP connection requested to 127.0.0.1:4556 (IOD #1) EID 8 libnsock nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [127.0.0.1:4556] Ncat: Connected to 127.0.0.1:4556. libnsock nsi_new2(): nsi_new (IOD #2) libnsock nsock_read(): Read request from IOD #1 [127.0.0.1:4556] (timeout: -1ms) EID 18 libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 26 libnsock nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 26 [peer unspecified] (1 bytes): . libnsock nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 35 [127.0.0.1:4556] libnsock nsock_readbytes(): Read request for 0 bytes from IOD #2 [peer unspecified] EID 42 libnsock nsock_trace_handler_callback(): Callback: READ ERROR [Connection refused (111)] for EID 18 [127.0.0.1:4556] Ncat: Connection refused. # socat -d -d UDP:127.0.0.1:4555 - 2015/10/04 13:18:29 socat[5655] N opening connection to AF=2 127.0.0.1:4555 2015/10/04 13:18:29 socat[5655] N successfully connected from local address AF=2 127.0.0.1:40785 2015/10/04 13:18:29 socat[5655] N reading from and writing to stdio 2015/10/04 13:18:29 socat[5655] N starting data transfer loop with FDs [3,3] and [0,1] 2015/10/04 13:18:34 socat[5655] E read(3, 0x557184904210, 8192): Connection refused 2015/10/04 13:18:34 socat[5655] N exit(1) # socat -d -d UDP:127.0.0.1:4556 - 2015/10/04 13:18:47 socat[5658] N opening connection to AF=2 127.0.0.1:4556 2015/10/04 13:18:47 socat[5658] N successfully connected from local address AF=2 127.0.0.1:49650 2015/10/04 13:18:47 socat[5658] N reading from and writing to stdio 2015/10/04 13:18:47 socat[5658] N starting data transfer loop with FDs [3,3] and [0,1] 2015/10/04 13:18:51 socat[5658] E read(3, 0x561b414be210, 8192): Connection refused 2015/10/04 13:18:51 socat[5658] N exit(1) How is it supposed to work? = DOMAIN: $ hostnamectl status | egrep Chassis\|Virtualization Chassis: vm Virtualization: kvm $ cat /proc/cmdline BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Rawhide-Xfce-Live-1003 rootfstype=auto ro rd.live.image console=tty0 console=ttyS0 $ systemctl status serial-getty(a)ttyS0.service ● serial-getty(a)ttyS0.service - Serial Getty on ttyS0 Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2015-10-04 09:02:06 EDT; 48s ago Docs: man:agetty(8) man:systemd-getty-generator(8) http://0pointer.de/blog/projects/serial-console.html Main PID: 1109 (agetty) CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty(a)ttyS0.service └─1109 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220 Oct 04 09:02:06 localhost systemd[1]: Started Serial Getty on ttyS0. = SW VERSIONS: $ qemu-system-x86_64 -version QEMU emulator version 2.4.0.1 (qemu-2.4.0.1-2.fc24), Copyright (c) 2003-2008 Fabrice Bellard $ libvirtd --version libvirtd (libvirt) 1.2.20 $ virt-manager --version 1.2.1 $ rpm -q qemu libvirt virt-manager qemu-2.4.0.1-2.fc24.x86_64 libvirt-1.2.20-1.fc24.x86_64 virt-manager-1.2.1-3.fc24.noarch [1] char: udp chardev shouldn't require an explicit open. http://patchwork.ozlabs.org/patch/311730

2 2

[libvirt] [PATCH RESEND] Distribute only generated virkeymaps.h
by Martin Kletzander 05 Oct '15

05 Oct '15

We are distributing virkeymaps.h and all the tools needed to rebuild that file. On top of that, we are generating that file into the $(srcdir) and that sometimes fails for me when trying to do make dist in VPATH on rawhide fedora. And we don't clean the file when maintainer-clean make target is requested. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- No change since the first version, just rebased. There was a discussion about another way of doing it, but I figured that that's not the way to go and the discussion stopped there: https://www.redhat.com/archives/libvir-list/2015-September/msg00271.html src/Makefile.am | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 07d587904f54..8ac20f491e35 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -173,15 +173,13 @@ UTIL_SOURCES = \ $(NULL) -EXTRA_DIST += $(srcdir)/util/virkeymaps.h $(srcdir)/util/keymaps.csv \ - $(srcdir)/util/virkeycode-mapgen.py - BUILT_SOURCES += util/virkeymaps.h +MAINTAINERCLEANFILES += util/virkeymaps.h util/virkeymaps.h: $(srcdir)/util/keymaps.csv \ $(srcdir)/util/virkeycode-mapgen.py $(AM_V_GEN)$(PYTHON) $(srcdir)/util/virkeycode-mapgen.py \ - <$(srcdir)/util/keymaps.csv >$(srcdir)/util/virkeymaps.h + <$(srcdir)/util/keymaps.csv >util/virkeymaps.h # Internal generic driver infrastructure NODE_INFO_SOURCES = nodeinfo.h nodeinfo.c nodeinfopriv.h -- 2.6.0

3 4

[libvirt] [PATCH] network: avoid existing bridges during rpm install of default network
by Laine Stump 05 Oct '15

05 Oct '15

When we install the libvirt-daemon-config-network package from an rpm, the specfile checks that the subnet used for the default network isn't already used, but blindly assumes that virbr0 is available. This is almost always the case, but there could be a situation where someone was already using virbr0 for their own network, then decided to install libvirt-daemon-config-network, leading to a failure when they tried to start the default network. This patch adds a bit to the %post script for the daemon-network-config package (in the specfile, used only for .rpm packages) that checks "ip link show" and the existing libvirt network xml files in a loop to find the lowest numbered virbrN that is currently unused by either. (note that we already check for in-use bridge devices when defining a network in libvirt's network driver, but the rpm install bypasses libvirt (which may not yet be fully functional) and creates the xml file itself). --- I found this sitting in a source tree, written a few months ago and forgotten. It is a followup to commit 37b8bc6f, which added a similar check in the network driver during virNetworkDefineXML(). I vaguely recall someone reporting this problem on IRC or maybe on one of the mailing lists (they had created a bridge manually using the name virbr0, then when they installed libvirt, it happily made a network definition using virbr0). Yes, not very common, but possible. libvirt.spec.in | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 78a4cc3..931c5b9 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1793,8 +1793,24 @@ if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; ;; esac + # find an unused bridge device named virbrN (this assumes that the + # original name in default.xml is exactly "virbr0", so do not + # change it there without also changing orig_br). + orig_br=0 + br=${orig_br} + while ip link show virbr${br} >/dev/null 2>&1 ||\ + (grep '<bridge ' %{_sysconfdir}/libvirt/qemu/networks/*.xml |\ + grep virbr${br} >/dev/null 2>&1); do + br=$(expr ${br} + 1) + # safety to prevent an endless loop + if test ${br} -gt 256; then + break; + fi + done + UUID=`/usr/bin/uuidgen` sed -e "s/${orig_sub}/${sub}/g" \ + -e "s/virbr${orig_br}/virbr${br}/" \ -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ < %{_datadir}/libvirt/networks/default.xml \ > %{_sysconfdir}/libvirt/qemu/networks/default.xml -- 2.4.3

2 1