February 2015 - Devel - libvirt List Archives

[libvirt] [PATCH] docs: add a note that attr 'managed' is only used by PCI devices
by Erik Skultety 02 Mar '15

02 Mar '15

Our documentation isn't 100% clear about hostdev 'managed' attribute usage, because it only makes sense to use it with PCI devices, yet we format this attribute to all hostdev devices. By adding a note into the docs, we can possibly avoid confusion from customer's side and also avoid a solution using ternary logic. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1155887 --- docs/formatdomain.html.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index fb0a0d1..6276a61 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -3110,6 +3110,12 @@ then this setting not required. </dd> </dl> + <p> + Note: The <code>managed</code> attribute is only used with PCI devices + and is ignored by all the other device types, thus setting + <code>managed</code> explicitly with other than PCI device has the same + effect as omitting it. + </p> </dd> <dt><code>source</code></dt> <dd>The source element describes the device as seen from the host using -- 1.9.3

2 2

[libvirt] [libvirt-test-API][PATCH 0/2] Add freepages test cases
by Jincheng Miao 02 Mar '15

02 Mar '15

Add freepages test cases. Jincheng Miao (2): Add freepage test Add freepage test case to test_connection.conf cases/test_connection.conf | 6 +++ repos/virconn/free_pages.py | 97 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 103 insertions(+), 0 deletions(-) create mode 100644 repos/virconn/free_pages.py

2 3

[libvirt] [PATCH] docs: Add mist.io as libvirt-based application
by Michal Privoznik 01 Mar '15

01 Mar '15

As reported on the libvirt-users list [1], there's new web application called mist.io which uses libvirt as one of its backends. Lets add it into our list of libivrt based applications. 1: https://www.redhat.com/archives/libvirt-users/2015-February/msg00096.html Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/apps.html.in | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/apps.html.in b/docs/apps.html.in index 4403ce6..79ee73a 100644 --- a/docs/apps.html.in +++ b/docs/apps.html.in @@ -404,6 +404,14 @@ functions, such as live migration that allows for load balancing between cluster nodes, monitoring CPU, memory. </dd> + <dt><a href="http://mist.io/">mist.io</a></dt> + <dd> + Mist.io is an open source project and a service that can assist you in + managing your virtual machines on a unified way, providing a simple + interface for all of your infrastructure (multiple public cloud + providers, OpenStack based public/private clouds, Docker servers, bare + metal servers and now KVM hypervisors). + </dd> </dl> <h2><a name="mobile">Mobile applications</a></h2> -- 2.0.5

2 2

[libvirt] new warning from ar on rawhide systems
by Eric Blake 27 Feb '15

27 Feb '15

When compiling libvirt (and probably other packages) on Fedora rawhide systems, I'm seeing a new warning message on every link line. # rpm -q libtool gcc binutils libtool-2.4.6-1.fc23.x86_64 gcc-5.0.0-0.16.fc23.x86_64 binutils-2.25-6.fc23.x86_64 For an example of the warning during a 'make V=1': > libtool: link: rm -fr .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la > libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o > ar: `u' modifier ignored since `D' is the default (see `U') > libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a Reading 'man ar', it looks like a relatively new binutils invention, one that Fedora chose to flip on by default, but also one that might be worth using even when ar is built with 'U' rather than 'D' as the default: > D Operate in deterministic mode. When adding files and the archive > index use zero for UIDs, GIDs, timestamps, and use consistent file > modes for all files. When this option is used, if ar is used with > identical options and identical input files, multiple runs will > create identical output files regardless of the input files' > owners, groups, file modes, or modification times. > > If binutils was configured with --enable-deterministic-archives, > then this mode is on by default. It can be disabled with the U > modifier, below. Is it worth teaching libtool to change ARFLAGS to be 'crD' instead of 'cru' when it is detected that ar is new enough to support deterministic libraries, in part to shut up the warning message being printed on every single libtool link line? (Note that I would explicitly include 'D', because even though Fedora chose to make 'D' the default, other distros may choose to make 'U' the default). Or conversely, do we want ARFLAGS to be 'cruU', to force non-deterministic mode, since any speedups made possible by timestamp comparison ('u') are only possible in non-deterministic mode? Does the use of 'u' buy us much measurable time when repeatedly and incrementally linking large libraries, where the new 'D' mode is forced to link everything instead of just the new inputs? And of course there's the question of how easy is it to detect that ar is new enough to understand the 'D'/'U' dichotomy? Is this something I should redirect to automake instead of libtool? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 1

[libvirt] [PATCH 0/3] Only talk to qemu guest agent when the domain is running
by Ján Tomko 27 Feb '15

27 Feb '15

Previously, only virDomainObjIsActive() was used to check domain liveness. This includes states like 'VIR_DOMAIN_PMSUSPENDED', where QEMU is running, but the guest is not. Explicitly check the state against VIR_DOMAIN_RUNNING and refuse to communicate with the agent if it does not match. https://bugzilla.redhat.com/show_bug.cgi?id=872424 Ján Tomko (3): Check for qemu guest agent availability after getting the job Pass virDomainObjPtr to qemuDomainAgentAvailable Check if domain is running in qemuDomainAgentIsAvailable src/qemu/qemu_domain.c | 11 ++++++++++- src/qemu/qemu_domain.h | 2 +- src/qemu/qemu_driver.c | 49 +++++++++++++++++++++++++------------------------ 3 files changed, 36 insertions(+), 26 deletions(-) -- 2.0.5

2 4

Re: [libvirt] [Xen-devel] [xen-unstable test] 35257: regressions - FAIL
by Jim Fehlig 27 Feb '15

27 Feb '15

Ian Campbell wrote: > On Thu, 2015-02-26 at 20:14 +0000, xen.org wrote: > >> flight 35257 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34629 >> > > logs: > http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-lib… > > http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-lib… > 2015-02-23 20:21:48 Z executing ssh ... root(a)10.80.229.106 virsh domxml-from-native xen-xl /etc/xen/debian.guest.osstest.cfg > /etc/xen/debian.guest.osstest.cfg.xml > error: failed to connect to the hypervisor > error: no valid connection > error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Connection refused > > http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-lib… > appears to show no libvirtd process. > > http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-lib… > says: > 2015-02-23 20:13:15.556+0000: 2133: info : libvirt version: 1.2.13 > 2015-02-23 20:13:15.556+0000: 2133: error : dnsmasqCapsRefreshInternal:726 : Cannot check dnsmasq binary dnsmasq: No such file or directory > > 2015-02-23 20:13:15.845+0000: 2133: error : > virFirewallValidateBackend:193 : direct firewall backend requested, > but /sbin/ebtables is not available: No such file or directory Odd, since ebtables was found when building checking for ebtables... /sbin/ebtables But AFAICT, that wont prevent libvirtd from starting. > > I think these are just spurious. > > 2015-02-23 20:13:15.845+0000: 2133: error : virFirewallApply:936 : out of memory > > > 2015-02-23 20:13:16.092+0000: 2133: error : virExec:491 : Cannot find 'pm-is-supported' in path: No such file or directory > 2015-02-23 20:13:16.092+0000: 2133: warning : virQEMUCapsInit:999 : Failed to get host power management capabilities > > As are these two. > > 2015-02-23 20:13:16.400+0000: 2133: error : virFirewallApply:936 : out of memory > > Has these OOM messages resulted in libvirtd exiting? No, I don't think so. The related code is int virFirewallApply(virFirewallPtr firewall) { size_t i, j; int ret = -1; virMutexLock(&ruleLock); if (!firewall || firewall->err == ENOMEM) { virReportOOMError(); goto cleanup; ... } I suspect 'firewall' is null, so OOM error is reported and the function returns -1. But I also don't see this preventing libvirtd from starting. I've cc'd the libvirt list for verification that these errors won't prevent libvirtd from starting. > I don't see any > evidence of a crash elsewhere in the logs (i.e. no "process segfaulted" > in dmesg, no OOM killing going on etc). > > We don't seem to collect dom0 freemem info, but that most likely > wouldn't help given the libvirtd process has exited. > > > Any ideas where to look next? Can you access the test environment and try starting libvirtd in the foreground? Or enable debug log level in /etc/libvirt/libvirtd.conf? Regards, Jim

2 1

[libvirt] [PATCH] Really fix XML formatting flags in SaveImageUpdateDef
by Ján Tomko 27 Feb '15

27 Feb '15

Commit cf2d4c6 used a logical or instead of bitwise or, effectively passing 1, that is VIR_DOMAIN_XML_INACTIVE. Yep, that's right. This was caught by a warning when building with clang. https://bugzilla.redhat.com/show_bug.cgi?id=1183869 --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index e9aa0b5..e282464 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5734,7 +5734,7 @@ qemuDomainSaveImageUpdateDef(virQEMUDriverPtr driver, if (!(newdef_migr = qemuDomainDefCopy(driver, newdef, - QEMU_DOMAIN_FORMAT_LIVE_FLAGS || + QEMU_DOMAIN_FORMAT_LIVE_FLAGS | VIR_DOMAIN_XML_MIGRATABLE))) goto cleanup; -- 2.0.5

3 2

[libvirt] [PATCH 0/4] add support for graphics to get a IPv6 address
by Luyao Huang 27 Feb '15

27 Feb '15

https://bugzilla.redhat.com/show_bug.cgi?id=1192318 We already support add a IPv6 address to graphics listen address and xml like this: <graphics type='spice' port='5900' autoport='yes' listen='2001b8:ca2:2::1' keymap='en-us'> <listen type='address' address='2001b8:ca2:2::1'/> </graphics> However we do not support get a IPv6 address for the network. add some helpers and rework networkGetNetworkAddress to make it can get a IPv6 address when we need. Luyao Huang (4): util: introduce a new helper for get interface IPv6 address conf: introduce new family attribute in graphics listen for chose IP family network: rework networkGetNetworkAddress to make it can get IPv6 address qemu: fix a error coverd issue in 2 place docs/formatdomain.html.in | 10 +++- docs/schemas/domaincommon.rng | 9 +++ src/conf/domain_conf.c | 21 +++++++ src/conf/domain_conf.h | 10 ++++ src/conf/network_conf.c | 2 +- src/conf/network_conf.h | 1 + src/libvirt_private.syms | 2 + src/network/bridge_driver.c | 50 +++++++++++----- src/network/bridge_driver.h | 6 +- src/qemu/qemu_command.c | 18 ++---- src/util/virnetdev.c | 70 ++++++++++++++++++++++ src/util/virnetdev.h | 2 + .../qemuxml2argv-graphics-listen-network.xml | 2 +- .../qemuxml2argv-graphics-listen-network2.xml | 2 +- .../qemuxml2xmlout-graphics-listen-network2.xml | 2 +- 15 files changed, 174 insertions(+), 33 deletions(-) -- 1.8.3.1

5 22

[libvirt] [PATCH 0/5] Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flag
by Ján Tomko 27 Feb '15

27 Feb '15

Add a flag to virConnectBaselineCPU to filter out features that block migration. Ján Tomko (5): Also store features blocking migration as CPUx86Data in the cpu map Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flag Implement VIR_CONNECT_BASELINE_CPU_MIGRATABLE in the x86 cpu driver Trivially implement VIR_CONNECT_BASELINE_CPU_MIGRATABLE for non-x86 cpus Add --migratable support to virsh cpu-baseline include/libvirt/libvirt-host.h | 1 + src/bhyve/bhyve_driver.c | 3 +- src/cpu/cpu_aarch64.c | 3 +- src/cpu/cpu_arm.c | 3 +- src/cpu/cpu_generic.c | 3 +- src/cpu/cpu_powerpc.c | 3 +- src/cpu/cpu_x86.c | 47 ++++++++++++++++++++++++- src/libvirt-host.c | 3 ++ src/qemu/qemu_driver.c | 3 +- tests/cputest.c | 6 ++++ tests/cputestdata/x86-baseline-6-migratable.xml | 10 ++++++ tests/cputestdata/x86-baseline-6-result.xml | 11 ++++++ tests/cputestdata/x86-baseline-6.xml | 37 +++++++++++++++++++ tools/virsh-domain.c | 6 ++++ tools/virsh.pod | 5 +-- 15 files changed, 135 insertions(+), 9 deletions(-) create mode 100644 tests/cputestdata/x86-baseline-6-migratable.xml create mode 100644 tests/cputestdata/x86-baseline-6-result.xml create mode 100644 tests/cputestdata/x86-baseline-6.xml -- 2.0.5

2 11

[libvirt] [PATCH] qemu: snapshot: post error when create internal system checkpoint snapshot with rbd backend
by Shanzhi Yu 27 Feb '15

27 Feb '15

When create internel system checkpoint snapshot with source file based on rbd backend, libvirt miss to check if the format of source file support internal snapshot. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1179533 Signed-off-by: Shanzhi Yu <shyu(a)redhat.com> --- src/qemu/qemu_driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 26fc6a2..6dd0a5c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13423,8 +13423,7 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, goto cleanup; if (dom_disk->src->type == VIR_STORAGE_TYPE_NETWORK && - (dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_SHEEPDOG || - dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_RBD)) { + dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_SHEEPDOG) { break; } if (vm->def->disks[i]->src->format > 0 && -- 2.1.0

2 2