May 2013 - Devel - libvirt List Archives

[libvirt] Libvirt 1.0.5 with Openvswitch 1.11.90: unable to add bridge br0 port vnet0 operation not supported
by Christopher Paggen (cpaggen) 06 May '13

06 May '13

Howdy, Running the most recent OVS and libvirt I'm running into the following error message with virt-install: root@qemu-kvm:~/libvirt-1.0.5# ovs-vsctl -V ovs-vsctl (Open vSwitch) 1.11.90 Compiled May 6 2013 22:37:22 root@qemu-kvm:~/libvirt-1.0.5# root@qemu-kvm:~/libvirt-1.0.5# virt-install --connect qemu:///system --name DSL2 --ram 1024 --vcpus 1 --disk path=/tmp/dsl2,size=1,bus=virtio,cache=none --network=bridge:br0 --vnc --os-type=linux --cdrom /dev/sr0 Starting install... ERROR Unable to add bridge br0 port vnet0: Operation not supported Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start DSL2 otherwise, please restart your installation. root@qemu-kvm:~/libvirt-1.0.5# ovs-vsctl del-port br0 vnet0 root@qemu-kvm:~/libvirt-1.0.5# libvirtd --version libvirtd (libvirt) 1.0.5 root@qemu-kvm:~/libvirt-1.0.5# virsh --version 1.0.5 root@qemu-kvm:~/libvirt-1.0.5# virt-install --connect qemu:///system --name DSL2 --ram 1024 --vcpus 1 --disk path=/tmp/dsl2,size=1,bus=virtio,cache=none --network=bridge:br0 --vnc --os-type=linux --cdrom /dev/sr0 Starting install... ERROR Unable to add bridge br0 port vnet0: Operation not supported Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start DSL2 otherwise, please restart your installation. root@qemu-kvm:~/libvirt-1.0.5# root@qemu-kvm:~/libvirt-1.0.5# ovs-vsctl show b81788a2-f45d-4fad-aad2-f423e6e70bad Bridge "br0" Port "eth1" Interface "eth1" Port "br0" Interface "br0" type: internal Port "tap0" Interface "tap0" root@qemu-kvm:~/libvirt-1.0.5#<mailto:root@qemu-kvm:~/libvirt-1.0.5#> Even if I create a new OVS switch I get the same result: root@qemu-kvm:~/libvirt-1.0.5# ovs-vsctl add-br b1 root@qemu-kvm:~/libvirt-1.0.5# virt-install --connect qemu:///system --name DSL2 --ram 1024 --vcpus 1 --disk path=/tmp/dsl2,size=1,bus=virtio,cache=none --network=bridge:b1 --vnc --os-type=linux --cdrom /dev/sr0 Starting install... ERROR Unable to add bridge b1 port vnet0: Operation not supported Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///system start DSL2 otherwise, please restart your installation. root@qemu-kvm:~/libvirt-1.0.5# Nothing in the openvswitch log file (OVS itself works fine, I can start VMs with the kvm command line). Any clues? I'm not too sure how to trace libvirt calls to OVS (according to the release notes, versions 1.0+ of libvirtd should work with OVS. Note: I am not using brcompat, I believe it's obsolete in the OVS version I'm running). Thanks, Chris.

1 0

[libvirt] [PATCHv2] qemu: Do fake auto-allocation of ports when generating native command
by Peter Krempa 06 May '13

06 May '13

When attempting to generate the native command line from an XML file that uses graphics port auto allocation, the generated commandline wouldn't be valid. This patch adds fake autoallocation of ports as done when starting the actual machine. --- Notes: Version 2: - rebased after context-conflict with 11fc1beab6e018a88182f80056d35217c150b3de src/qemu/qemu_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9492850..45fcf05 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5274,6 +5274,58 @@ static char *qemuConnectDomainXMLToNative(virConnectPtr conn, if (qemuDomainAssignAddresses(def, qemuCaps, NULL) < 0) goto cleanup; + /* do fake auto-alloc of graphics ports, if such config is used */ + for (i = 0 ; i < def->ngraphics; ++i) { + virDomainGraphicsDefPtr graphics = def->graphics[i]; + if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC && + !graphics->data.vnc.socket && graphics->data.vnc.autoport) { + graphics->data.vnc.port = 5900; + } else if (graphics->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) { + int j; + bool needTLSPort = false; + bool needPort = false; + int defaultMode = graphics->data.spice.defaultMode; + + if (graphics->data.spice.autoport) { + /* check if tlsPort or port need allocation */ + for (j = 0 ; j < VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_LAST ; j++) { + switch (graphics->data.spice.channels[j]) { + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_SECURE: + needTLSPort = true; + break; + + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_INSECURE: + needPort = true; + break; + + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_ANY: + switch (defaultMode) { + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_SECURE: + needTLSPort = true; + break; + + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_INSECURE: + needPort = true; + break; + + case VIR_DOMAIN_GRAPHICS_SPICE_CHANNEL_MODE_ANY: + needTLSPort = true; + needPort = true; + break; + } + break; + } + } + } + + if (needPort || graphics->data.spice.port == -1) + graphics->data.spice.port = 5901; + + if (needTLSPort || graphics->data.spice.tlsPort == -1) + graphics->data.spice.tlsPort = 5902; + } + } + if (!(cmd = qemuBuildCommandLine(conn, driver, def, &monConfig, monitor_json, qemuCaps, NULL, -1, NULL, VIR_NETDEV_VPORT_PROFILE_OP_NO_OP))) -- 1.8.2.1

3 4

[libvirt] Static Route for IPv6
by Gene Czarcinski 06 May '13

06 May '13

In the process of adding the code to support static routes for IPv4 and IPv6, I hit a problem when I tried to specify a static route for ::/0 (that is "default") ... the error was "file exists." and the problem is that this is a feature and not a bug. Here is the comment from the bugzilla report which explains things: ------------------------------------------------------------------------------------------------------------- yeah, this isn't a bug as far as I can see. The magic that your looking for is in fib6_add_rt2node(). When adding a new route, we search for duplicate routes, and should we find one, we compare them to ensure that when the ipv6 stack does a route lookup, they have some way to select which route should be used. To do that they use the metric/preference number (I admit that use of the term metric in the iproute2 tool is a bit misleading, but if you check the ip-route(8) man page, you'll see its a synonym for preference). At any rate, since you already have a default gateway (which the stack sees as a duplicate for the one your adding), and the existing route has the same metric/preference as the one you are adding, you get the EXIST error. Ways to work around this: 1) Use the src option in the ip route add command to differentiate and prevent the existing default gw from being used (might be useful if you want different virt guests to use different default gw). 2) instead of using ip route add, use ip route replace, which will overwrite the existing default gw. 3) Use a different metric value than the existing default gw. Both routes will be added, but only the higest priority route will be used. ----------------------------------------------------------------------------------------- As I understand the situation now, the error I got for ::/0 was valid and should not be ignored or overriden by default. However, there is bound to be someone who has a valid reason to do this so there needs to be a way to do it. Proposal: Add a new attribute metric to the <route> subelement. The default for metric will be metric='1' so that it will be the same as it is now. However, the use will be able to specify an arbitrary unsigned 32 bit number. There are two other suggestions up there. Any comments? When I started this, my goal was simply to get some static routes for "regular" networks so that the virtualization host would know where to route packets. I am not sure that it is a good idea that folks fiddle with default routes in libvirt virtual-network definitions but I am sure that someone, sometime will have a valid reason to do so. BTW, just because some static route variation is not implemented as part of the libvirt definition does not mean that a user cannot issue the ip-route-add command manually. Gene

2 1

[libvirt] [PATCH 0/2] spec file fixups
by Eric Blake 06 May '13

06 May '13

Here's a couple of spec file cleanups that should go in prior to 1.0.5, particularly since the FPC recently changed packaging guidelines because of an issue highlighted in libvirt's spec file. Eric Blake (2): spec: collect all BuildRequires into one area spec: proper soft static allocation of qemu uid libvirt.spec.in | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) -- 1.8.1.4

3 6

[libvirt] [PATCH] build: always include libvirt_lxc.syms in tarball
by Eric Blake 06 May '13

06 May '13

On a mingw build, 'make distcheck' fails with: GEN libvirt_qemu.def make[3]: *** No rule to make target `../../src/libvirt_lxc.syms', needed by `libvirt_lxc.def'. Stop. I traced it to a missing entry in EXTRA_DIST. But rather than keep the entire list in sync, it is easier to list the three syms files that drive .so files directly, and then reuse existing makefile variables for the remaining files (that is, I validated that all remaining files are added to SYM_FILES, possibly via USED_SYM_FILES, according to makefile conditionals). * src/Makefile.am (EXTRA_DIST): Ensure all syms files are shipped. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/Makefile.am | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 299b8fd..6c2788c 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1548,20 +1548,11 @@ SYM_FILES += $(srcdir)/libvirt_atomic.syms endif EXTRA_DIST += \ - libvirt_public.syms \ - libvirt_private.syms \ - libvirt_atomic.syms \ - libvirt_driver_modules.syms \ - libvirt_daemon.syms \ - libvirt_linux.syms \ - libvirt_esx.syms \ - libvirt_openvz.syms \ - libvirt_qemu.syms \ - libvirt_sasl.syms \ - libvirt_gnutls.syms \ - libvirt_vmx.syms \ - libvirt_xenxs.syms \ - libvirt_libssh2.syms + libvirt_public.syms \ + libvirt_lxc.syms \ + libvirt_qemu.syms \ + $(SYM_FILES) \ + $(NULL) GENERATED_SYM_FILES = \ libvirt.syms libvirt.def libvirt_qemu.def libvirt_lxc.def -- 1.8.1.4

2 6

[libvirt] [PATCH qom-cpu-next 0/3] X86CPU: "feature-words"/"filtered-features" properties (v12)
by Eduardo Habkost 06 May '13

06 May '13

Resubmitting after a rebase and a few trivial changes. Changes v11 -> v12: * Remove unnecessary entries from .gitignore * Fix indentation of x86_cpu_get_feature_words() declaration * Rebase on top of qom-cpu-next (commit bd87d2a - target-i386: Use FeatureWord loop on filter_features_for_kvm()) Git tree for reference: git://github.com/ehabkost/qemu-hacks.git work/cpu-raw-features.v12 Eduardo Habkost (3): target-i386: Add "feature-words" property target-i386: Introduce X86CPU.filtered_features field target-i386: Add "filtered-features" property to X86CPU Makefile.objs | 7 ++++- qapi-schema.json | 32 ++++++++++++++++++++ target-i386/cpu-qom.h | 3 ++ target-i386/cpu.c | 82 +++++++++++++++++++++++++++++++++++++++++---------- 4 files changed, 108 insertions(+), 16 deletions(-) -- 1.8.1.4

2 4

[libvirt] Requested operation is not valid: domain is not running but exactly vm is running
by yue 06 May '13

06 May '13

hi,all requested operation is not valid: domain is not running but exactly vm is running when call getCPUStats,interfaceStats... system: centos6.3 libvirt-0.9.10-21.el6_3.7.x86_64 libvirt-python-0.9.10-21.el6_3.7.x86_64 thanks

2 1

[libvirt] [PATCH qom-cpu 0/9] x86: feature words array (v11) + "feature-words" property
by Eduardo Habkost 06 May '13

06 May '13

This series includes the previous "replace cpuid_*features fields with a feature word array" series. The first 4 patches already have a Reviewed-by from Igor, they correspond to v10 plus a small indent fix requested by him. As the cpuid_*features series was holding my "feature-words"/"filtered-features" series (previously sent as RFC), I am now sending both as a single series, to try to get "feature-words"/"filtered-features" some attention and try to get it included in 1.5. The "feature-words"/"filtered-features" mechanism is very important for libvirt, to allow it to ensure the guest is getting the required set of CPU features, as configured by the user. Eduardo Habkost (9): target-i386: cleanup: Group together level, xlevel, xlevel2 fields target-i386/kvm.c: Code formatting changes target-i386/cpu.c: Break lines so they don't get too long target-i386: Replace cpuid_*features fields with a feature word array target-i386: Add ECX information to FeatureWordInfo target-i386: Add "feature-words" property target-i386: Use FeatureWord loop on filter_features_for_kvm() target-i386: Introduce X86CPU.filtered_features field target-i386: Add "filtered-features" property to X86CPU .gitignore | 2 + Makefile.objs | 7 +- bsd-user/elfload.c | 2 +- bsd-user/main.c | 4 +- hw/i386/kvm/clock.c | 2 +- linux-user/elfload.c | 2 +- linux-user/main.c | 4 +- qapi-schema.json | 31 +++ target-i386/cpu-qom.h | 3 + target-i386/cpu.c | 501 +++++++++++++++++++++++++++++----------------- target-i386/cpu.h | 15 +- target-i386/helper.c | 4 +- target-i386/kvm.c | 5 +- target-i386/misc_helper.c | 14 +- target-i386/translate.c | 10 +- 15 files changed, 385 insertions(+), 221 deletions(-) -- 1.8.1.4

4 31

[libvirt] IPv6 iscsi targets
by Ján Tomko 06 May '13

06 May '13

Hello. Before running iscsiadm, libvirt translates the source host to an IP address for the --portal option. However, it only resolves to IPv4 and only uses the first address. iscsiadm allows a hostname to be specified [1][2], but specifying a hostname instead of the address doesn't work if the hostname translates to an unreachable IPv6 address first. Would it be reasonable to go through all the addresses returned by getaddrinfo() in libvirt, try to connect() to it and pass the address to iscsiadm when the connection succeeds? Or we should just pass the hostname and make iscsiadm deal with it? Jan [1] https://github.com/mikechristie/open-iscsi/commit/4d045cd [2] https://bugzilla.redhat.com/show_bug.cgi?id=624437

1 0

[libvirt] [PATCH v1 0/8] Chardev hotplug
by Michal Privoznik 06 May '13

06 May '13

The first round. For some reasons, I am still unable to hotplug any king of chardev. For instance: <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> Doesn't work. On the other hand, any domain with such device coldpluged refuse to start anyway :) Michal Privoznik (8): domain_conf: Introduce chardev hotplug helpers qemu: Implement chardev hotplug on config level qemu_monitor_json: Move InetSocketAddress build to a separate function qemu_monitor: Introduce qemuMonitorAttachCharDev qemu_monitor: Introduce qemuMonitorDetachCharDev qemu_command: Honour chardev alias assignment with a function qemu: Introduce qemuBuildChrDeviceStr qemu: Implement chardev hotplug on live level src/conf/domain_conf.c | 174 +++++++++++++++++++++++++++- src/conf/domain_conf.h | 11 ++ src/libvirt_private.syms | 4 + src/qemu/qemu_command.c | 262 +++++++++++++++++++++++++++++++++++-------- src/qemu/qemu_command.h | 14 ++- src/qemu/qemu_driver.c | 43 ++++++- src/qemu/qemu_hotplug.c | 97 ++++++++++++++++ src/qemu/qemu_hotplug.h | 6 + src/qemu/qemu_monitor.c | 41 +++++++ src/qemu/qemu_monitor.h | 5 + src/qemu/qemu_monitor_json.c | 261 +++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_monitor_json.h | 5 + 12 files changed, 850 insertions(+), 73 deletions(-) -- 1.8.1.5

1 8