October 2012 - Devel - libvirt List Archives

[libvirt] [ANNOUNCE] libvirt-designer 0.0.1 release
by Daniel P. Berrange 09 Oct '12

09 Oct '12

I am pleased to announce that the first release of the libvirt-designer package, version 0.0.1, is now available from ftp://ftp.libvirt.org/libvirt/designer/ The packages are GPG signed with Key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF (4096R) New in this release: - Everything ! The libvirt-designer package provides a library that integrates libosinfo and libvirt-gconfig. Given an operating system identifier and libvirt host capabilities, it queries the libosinfo database to determine optimal hardware configuration and uses this information to design suitable domain XML for running the OS as a guest. In a similar manner it facilitates the setup of guest hardware devices such as disks, network interfaces, video cards, etc. These APIs are inspired by experience creating internal APIs for similar tasks in the virt-install/virt-manager projects. Since it builds on libosinfo and libvirt-gconfig, the libvirt-designer library relies on GObject introspection to provide access to its APIs for non-C programming languages. In addition it explicitly avoids a direct depedancy on libvirt.so, to enable usage by applications using alternative SNMP, CIM, etc bindings to libvirt, or those applications which simply need to construct libvirt XML without actually booting the guests afterwards. These early releases of libvirt-designer should be considered experimental. While we don't actively plan to change/break the API/ABI, we are not going to guarantee API/ABI stability of libvirt-designer at this time. Follow up comments about libvirt-designer should be directed to the regular libvir-list(a)redhat.com development list. Thanks to all the people involved in contributing to this release, in particular Michal who is actually doing the vast majority of the hard work here. 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 :|

1 0

[libvirt] [PATCH] qemu: Fix QMP detection of QXL graphics
by Jiri Denemark 09 Oct '12

09 Oct '12

With the recent introduction of QMP capabilities probing, libvirt failed to detect support for QXL graphics in QEMU 1.2 and newer. In addition to fixing that, this patch also causes libvirt to detect QXL support for qemu-kvm-0.13.0, which doesn't advertise it in -help output but mentions it in device list. Since qemu-kvm-0.13.0 supported -spice, it looks like not having qxl in -help was a bug. --- src/qemu/qemu_capabilities.c | 1 + tests/qemuhelptest.c | 1 + 2 files changed, 2 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index d16a7bc..982b875 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1276,6 +1276,7 @@ struct qemuCapsStringFlags qemuCapsObjectTypes[] = { { "virtio-scsi-pci", QEMU_CAPS_VIRTIO_SCSI_PCI }, { "spicevmc", QEMU_CAPS_DEVICE_SPICEVMC }, { "qxl-vga", QEMU_CAPS_DEVICE_QXL_VGA }, + { "qxl", QEMU_CAPS_VGA_QXL }, { "sga", QEMU_CAPS_SGA }, { "scsi-block", QEMU_CAPS_SCSI_BLOCK }, { "scsi-cd", QEMU_CAPS_SCSI_CD }, diff --git a/tests/qemuhelptest.c b/tests/qemuhelptest.c index 681f425..df30ac1 100644 --- a/tests/qemuhelptest.c +++ b/tests/qemuhelptest.c @@ -467,6 +467,7 @@ mymain(void) QEMU_CAPS_NESTING, QEMU_CAPS_NAME_PROCESS, QEMU_CAPS_SMBIOS_TYPE, + QEMU_CAPS_VGA_QXL, QEMU_CAPS_SPICE, QEMU_CAPS_VGA_NONE, QEMU_CAPS_MIGRATE_QEMU_FD, -- 1.7.12

3 3

[libvirt] [PATCH 0/3] non-shared migration without target disk images
by liguang 09 Oct '12

09 Oct '12

by now, if you want a non-shared migration, you have to create same files at target as source side, which seems intorlerable! this issue was reported by Reinier Schoof http://www.redhat.com/archives/libvir-list/2011-December/msg00451.html These patches try to let migrate --copy-storage-* work without pre-exist disk image files at target side. we may also hope qemu to aware of this issue hooks/qemu | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/Makefile.am | 3 ++ src/util/hooks.c | 2 +- 3 files changed, 59 insertions(+), 1 deletions(-)

3 7

[libvirt] [libvirt-list] question about the commands: domhostname and hostname
by Li Zhang 09 Oct '12

09 Oct '12

Hi all, I am testing the virsh commands, and I found that these two commands: * domhostname * hostname >From the manual of virsh commands: * hostname Print the hypervisor hostname. * domhostname domain Returns the hostname of a domain, if the hypervisor makes it available It seems that both of them want to get the host name. What's the difference between them? >From the source code, domhostname only is supported for openvz on 0.10.1. Will this be only for openvz in the future? Any idea? Thanks a lot in advance. -:) -- Best Regards -Li

3 7

[libvirt] virsh blockcommit tests (w/ libvirt & qemu git)
by Kashyap Chamarthy 09 Oct '12

09 Oct '12

Hi, Here are a few tests I've done over the weekend to test blockcommit w/ Eric's block commit patches: - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html - https://www.redhat.com/archives/libvir-list/2012-October/msg00091.html Most of these are from an earlier disscussion from Eric. (1) (POSITIVE-TEST) Commit data from 3 backing image files into 'base' (top to base) using blockcommit, w/ base & resulting overlays as qcow2: actual state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [active-layer] desired state: [base] <-- [act-f17-base.qcow2] (resulting in invalidating snap1, snap2, snap3) #======================# [root@moon libvirt]# virsh blockcommit --domain f17-base vda --wait --base /export/vmimgs2/f17-base.qcow2 --top /export/vmimgs2/snap3-f17-base.qcow2 --verbose Block Commit: [100 %] Commit complete [root@moon libvirt]# #======================# [root@moon ~]# qemu-img info /export/vmimgs2/act-f17-base.qcow2 image: /export/vmimgs2/act-f17-base.qcow2 file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 648K cluster_size: 65536 backing file: /export/vmimgs2/f17-base.qcow2 [root@moon ~]# #======================# (2) (POSITIVE-TEST) Commit data from 2 backing image files into 'base' (top to base) using blockcommit, w/ base as raw & resulting overlays as qcow2: actual state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [active-layer] desired state: [base] <--- [snap-3] <--- [active-layer] (resulting in invalidating snap1, snap2) #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --top /var/lib/ libvirt/images/snap3-of-test-f17base.qcow2 --verbose Block Commit: [100 %] Commit complete [root@moon qemu]# #======================# [root@moon qemu]# qemu-img info /var/lib/libvirt/images/snap4-of-test-f17base.qcow2 image: /var/lib/libvirt/images/snap4-of-test-f17base.qcow2 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 2.3M cluster_size: 65536 backing file: /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 [root@moon qemu]# #======================# (3) (NEGATIVE-TEST) Try blockcommit to a base image which is a 'raw' device - Question: I assume the below is expected, right? We cannot do blockcommit into a NON-qcow2 base file? #======================# [root@moon qemu]# virsh blockcommit --domain raw-base vda --wait --base /export/vmimgs2/raw-base.img --top /var/lib/libvirt/images/snap3-b-raw-base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Could not open '/export/vmimgs2/raw-base.img' [root@moon qemu]# #======================# (4) (NEGATIVE-TEST) Try blockcommit while the guest is 'offline' #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17-base.qcow2 --top /var/lib/libvirt/images/snap3-of-test-f17-base.qcow2 --verbose error: Requested operation is not valid: domain is not running #======================# (5) (NEGATIVE-TEST) Provide a non-existent file path for base or top(and both) #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --top /var/lib/libvirt/images/snap3-of--f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Top image file /var/lib/libvirt/images/snap3-of--f17base.qcow2 not found #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of--f17base.qcow2 --top /var/lib/libvirt/images/snap3-of-test-f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap1-of--f17base.qcow2' not found #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap1-of--f17base.qcow2 --top /var/lib/libvirt/images/snap3-of--f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap1-of--f17base.qcow2' not found #======================# (6) (NEGATIVE-TEST) Provide --base & --top values out of order: #======================# [root@moon qemu]# virsh blockcommit --domain test-f17base vda --wait --base /var/lib/libvirt/images/snap3-of-test-f17base.qcow2 --top /var/lib/libvirt/images/snap1-of-test-f17base.qcow2 --verbose error: internal error unable to execute QEMU command 'block-commit': Base '/var/lib/libvirt/images/snap3-of-test-f17base.qcow2' not found [root@moon qemu]# #======================# NOTES: ----- (a) To quickly check differences between the snapshot image files, I added a text file in each of the snapshot images, just before taking a snapshot. And, when I do a commit operation, I just check w/ 'guestfish' on the relevant disk image if all the expected content reflect. $ guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help on commands 'man' to read the manual 'quit' to quit the shell Operating system: Fedora release 17 (Beefy Miracle) /dev/sda1 mounted on / ><fs> ls /export file2.txt file3.txt file4.txt ><fs> Is there a simpler way? (b) The snapshot-create command I use is something like below: # virsh snapshot-create-as --domain raw-base snap4 snap4-desc --disk-only --diskspec vda,snapshot=external,file=/var/lib/libvirt/images/snap4-b-raw-base.qcow2 --atomic Question: At this point in time, I guess 'snapshot-revert' command is not uhelpful for any practical purposes while dealing with external snapshots,right? - To rephrase, is there a way(in future?),a coherent way to use 'blockcommit'(or blockpull) in conjunction with 'snapshot-revert' command? Yet to test: (1) Use a raw block device(LVM, or direct block /dev/sda1) as backing file (2) Try testing the case of a backing file smaller than the top file being committed ( with data located at various offsets) + In-progress: I'm testing this by adding a 'virsh attach-device' Thanks -- /kashyap

2 4

[libvirt] [PATCH] fix-up an implicit build dead-loop in cfg.mk
by liguang 09 Oct '12

09 Oct '12

if gnulib submodule happened to be dirty, build process will fall into '_autogen' target trap in cfg.mk recursively, so break this dead-loop. Signed-off-by: liguang <lig.fnst(a)cn.fujitsu.com> --- cfg.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cfg.mk b/cfg.mk index bbfd4a2..92966d5 100644 --- a/cfg.mk +++ b/cfg.mk @@ -699,7 +699,7 @@ ifeq (0,$(MAKELEVEL)) test "$$stamp" = "$$actual"; echo $$?) _clean_requested = $(filter %clean,$(MAKECMDGOALS)) ifeq (1,$(_update_required)$(_clean_requested)) - $(info INFO: gnulib update required; running ./autogen.sh first) + $(error ERR: gnulib update required; running ./autogen.sh first) Makefile: _autogen endif endif -- 1.7.2.5

3 3

[libvirt] [PATCH] virsh: add qemu-monitor-command --pretty
by Eric Blake 08 Oct '12

08 Oct '12

I was using qemu-monitor-command during development, and found it quite hard to use. Compare the results of this patch on ease of reading: $ virsh qemu-monitor-command dom '{"execute":"query-version"}' {"return":{"qemu":{"micro":1,"minor":12,"major":0},"package":"(qemu-kvm-0.12.1.2)"},"id":"libvirt-7683"} $ virsh qemu-monitor-command --pretty dom '{"execute":"query-version"}' { "return": { "qemu": { "micro": 1, "minor": 12, "major": 0 }, "package": "(qemu-kvm-0.12.1.2)" }, "id": "libvirt-7674" } * tools/virsh-host.c (cmdQemuMonitorCommand): New option. * tools/virsh.pod (qemu-monitor-command): Document it. --- Note that 'qemu-monitor-command dom --pretty --hmp info version' happens to truncate 0.12.1(qemu-kvm-0.12.1.2) into just 0.12 (since that is the portion of the prefix of the string that forms a valid JSON subsequence); we probably have a bug in virJSONValueFromString for not rejecting trailing junk, but that's a matter for another patch; for now, I just documented that --hmp and --pretty don't make sense together in the man page. tools/virsh-host.c | 15 +++++++++++++++ tools/virsh.pod | 10 ++++++---- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/tools/virsh-host.c b/tools/virsh-host.c index 2c46336..40ad8de 100644 --- a/tools/virsh-host.c +++ b/tools/virsh-host.c @@ -38,6 +38,7 @@ #include "virsh-domain.h" #include "xml.h" #include "virtypedparam.h" +#include "json.h" /* * "capabilities" command @@ -529,6 +530,8 @@ static const vshCmdInfo info_qemu_monitor_command[] = { static const vshCmdOptDef opts_qemu_monitor_command[] = { {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")}, {"hmp", VSH_OT_BOOL, 0, N_("command is in human monitor protocol")}, + {"pretty", VSH_OT_BOOL, 0, + N_("pretty-print any qemu monitor protocol output")}, {"cmd", VSH_OT_ARGV, VSH_OFLAG_REQ, N_("command")}, {NULL, 0, 0, NULL} }; @@ -544,6 +547,7 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) const vshCmdOpt *opt = NULL; virBuffer buf = VIR_BUFFER_INITIALIZER; bool pad = false; + virJSONValuePtr pretty = NULL; dom = vshCommandOptDomain(ctl, cmd, NULL); if (dom == NULL) @@ -567,6 +571,16 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, flags) < 0) goto cleanup; + if (vshCommandOptBool(cmd, "pretty")) { + char *tmp; + pretty = virJSONValueFromString(result); + if (pretty && (tmp = virJSONValueToString(pretty, true))) { + VIR_FREE(result); + result = tmp; + } else { + vshResetLibvirtError(); + } + } vshPrint(ctl, "%s\n", result); ret = true; @@ -574,6 +588,7 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) cleanup: VIR_FREE(result); VIR_FREE(monitor_cmd); + virJSONValueFree(pretty); if (dom) virDomainFree(dom); diff --git a/tools/virsh.pod b/tools/virsh.pod index c02ffe8..ac8a00f 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -2910,15 +2910,17 @@ attaching to an externally launched QEMU process. There may be issues with the guest ABI changing upon migration, and hotunplug may not work. -=item B<qemu-monitor-command> I<domain> [I<--hmp>] I<command>... +=item B<qemu-monitor-command> I<domain> { [I<--hmp>] | [I<--pretty>] } +I<command>... Send an arbitrary monitor command I<command> to domain I<domain> through the qemu monitor. The results of the command will be printed on stdout. If I<--hmp> is passed, the command is considered to be a human monitor command and libvirt will automatically convert it into QMP if needed. In that case -the result will also be converted back from QMP. If more than one argument -is provided for I<command>, they are concatenated with a space in between -before passing the single command to the monitor. +the result will also be converted back from QMP. If I<--pretty> is given, +and the monitor uses QMP, then the output will be pretty-printed. If more +than one argument is provided for I<command>, they are concatenated with a +space in between before passing the single command to the monitor. =back -- 1.7.11.4

2 2

[libvirt] Fwd: Failed to get host power management capabilities
by David Torres 08 Oct '12

08 Oct '12

Hi all, My name is David Torres, I am from Costa Rica. See this is the problem I have with the KVM instalation: 2012-10-03 20:28:17.395+0000: 25793: warning : qemuCapsInit:856 : Failed to get host power management capabilities 2012-10-03 20:28:17.661+0000: 25793: error : virExecWithHook:328 : Cannot find 'pm-is-supported' in path: No such file or directory And this error from the kern.log: Oct 4 21:50:53 kvm kernel: [22727.849902] device vnet0 entered promiscuous mode Oct 4 21:50:53 kvm kernel: [22727.883686] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22727.883692] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22728.130242] br0: port 2(vnet0) entering forwarding state Oct 4 21:50:53 kvm kernel: [22728.134443] br0: port 2(vnet0) entering disabled state Oct 4 21:50:53 kvm kernel: [22728.135238] device vnet0 left promiscuous mode Oct 4 21:50:53 kvm kernel: [22728.135242] br0: port 2(vnet0) entering disabled state Oct 4 21:50:54 kvm kernel: [22728.673620] type=1400 audit(1349409054.320:42): apparmor="STATUS" operation="profile_remove" name="libvirt-9b75f498-7959-7321-9461-d729d9c60668" pid=6349 comm="apparmor_parser" And when I try to create a Virtual Machine from the Virtual Machine Monitor, I got this error message: 2012-10-04 22:59:32.154+0000: 1333: error : qemuProcessReadLogOutput:1006 : internal error Process exited while reading console log output: char device redirected to /dev/pts/2 Could not access KVM kernel module: Is a directory failed to initialize KVM: Is a directory No accelerator found! I already enabled the virtualization feature on the BIOS and run the modprobe kvm-intel command also. No error message was received during the instalation process. So I am stuck on this problem :(.... I will appreciate sooo much any help. Thank you so much in advanced Regards

2 1

[libvirt] [PATCH] Call curl_global_init from virInitialize to avoid thread-safety issues
by Matthias Bolte 08 Oct '12

08 Oct '12

curl_global_init is not thread-safe. curl_easy_init might call curl_global_init when it was no called before. But curl_easy_init can be called from different threads by the ESX driver. Therefore, call curl_global_init from virInitialize to stop curl_easy_init from calling it. Reported by Benjamin Wang. --- configure.ac | 10 +++++++++- src/libvirt.c | 8 ++++++++ src/xenapi/xenapi_driver.c | 1 - 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 6d50985..0013d9d 100644 --- a/configure.ac +++ b/configure.ac @@ -2299,9 +2299,12 @@ dnl LIBCURL_CFLAGS="" LIBCURL_LIBS="" +have_curl=no if test "$with_esx" = "yes" || test "$with_esx" = "check" || test "$with_xenapi" = "yes" || test "$with_xenapi" = "check"; then PKG_CHECK_MODULES(LIBCURL, libcurl >= $LIBCURL_REQUIRED, [ + have_curl=yes + if test "$with_esx" = "check"; then with_esx=yes fi @@ -2326,6 +2329,11 @@ if test "$with_esx" = "yes" || test "$with_esx" = "check" || test "$with_xenapi" ]) fi +if test "$have_curl" = "yes" ; then + AC_DEFINE_UNQUOTED([HAVE_LIBCURL], 1, [whether libcurl is available]) +fi +AM_CONDITIONAL([HAVE_LIBCURL], [test "$have_curl" = "yes"]) + if test "$with_esx" = "yes" ; then AC_DEFINE_UNQUOTED([WITH_ESX], 1, [whether ESX driver is enabled]) @@ -3081,7 +3089,7 @@ AC_MSG_NOTICE([Libraries]) AC_MSG_NOTICE([]) AC_MSG_NOTICE([ libxml: $LIBXML_CFLAGS $LIBXML_LIBS]) AC_MSG_NOTICE([ dlopen: $DLOPEN_LIBS]) -if test "$with_esx" = "yes" ; then +if test "$have_curl" = "yes" ; then AC_MSG_NOTICE([ libcurl: $LIBCURL_CFLAGS $LIBCURL_LIBS]) else AC_MSG_NOTICE([ libcurl: no]) diff --git a/src/libvirt.c b/src/libvirt.c index ada9a86..76e4401 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -41,6 +41,10 @@ # include <winsock2.h> #endif +#ifdef HAVE_LIBCURL +# include <curl/curl.h> +#endif + #include "virterror_internal.h" #include "logging.h" #include "datatypes.h" @@ -418,6 +422,10 @@ virInitialize(void) virNetTLSInit(); +#if HAVE_LIBCURL + curl_global_init(CURL_GLOBAL_DEFAULT); +#endif + VIR_DEBUG("register drivers"); #if HAVE_WINSOCK2_H diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index 2fac561..d60ad23 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -171,7 +171,6 @@ xenapiOpen (virConnectPtr conn, virConnectAuthPtr auth, xmlInitParser(); xmlKeepBlanksDefault(0); xen_init(); - curl_global_init(CURL_GLOBAL_ALL); privP->session = xen_session_login_with_password(call_func, privP, username, password, xen_api_latest_version); -- 1.7.4.1

2 2

[libvirt] [PATCH 0/2] extend virGetUserID and virGetGroupID
by Marcelo Cerri 08 Oct '12

08 Oct '12

This patch series moves the logic for parsing users and groups in a similar way to coreutils' chown from security_dac.c to util.c, as suggested by Eric Blake. This change has two majors side effects: 1. Some error messages that were issued when security_dac.c tried to parse an ID as a name are no longer issued. 2. The keys `user` and `group` in qemu.conf can now be defined in the same way that in DAC security labels. Marcelo Cerri (2): util: extend virGetUserID and virGetGroupID to support names and IDs security: update user and group parsing in security_dac.c src/security/security_dac.c | 40 ++++++--------------- src/util/util.c | 87 ++++++++++++++++++++++++++++++++++++++------- 2 files changed, 84 insertions(+), 43 deletions(-) -- 1.7.12

3 18