- Devel - libvirt List Archives

[libvirt] [PATCH] docs: Drop useless </p> in drvphyp.html.in
by Michal Privoznik 09 Oct '12

09 Oct '12

--- Pushing under trivial rule. docs/drvphyp.html.in | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/docs/drvphyp.html.in b/docs/drvphyp.html.in index 0bd20dd..50e26b2 100644 --- a/docs/drvphyp.html.in +++ b/docs/drvphyp.html.in @@ -43,6 +43,5 @@ phyp://user@ivm/system (IVM connection) <pre> phyp://[username@]{hmc|ivm}/managed_system </pre> - </p> </body></html> -- 1.7.8.6

1 0

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

09 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. Peter Krempa's fix for correctly handling errors returned by getpwnam_r and getgrnam_r is squashed into this patch series. 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 | 45 +++----------- src/util/util.c | 143 ++++++++++++++++++++++++++++++++------------ 2 files changed, 112 insertions(+), 76 deletions(-) -- 1.7.12

2 4

[libvirt] [PATCH 0/3] Cleanly save session VMs on logout/shutdown
by Alexander Larsson 09 Oct '12

09 Oct '12

Atm, when you exit the sessin (via logout or shutdown for instance) we just leave the qemu:///session handling libvirtd process around, including any running VMs. This is not particularly nice, as there is no way to know that the VMs are running, and you risk data loss if you shutdown while the VMs are running. This patch series adds a babysitter to the session that will track session lifetime and shutdown events and save running VMs as needed. Outstanding questions: Can this code be inside libvirtd itself? I.E. is it possible to do VM management calls like virDomainManagedSave() from inside libvirtd itself. If not, who will launch the babysitter? Alexander Larsson (3): Fix typo in HAVE_DBUS automake conditional virdbus: Add virDBusGetSessionBus helper Add new libvirt-babysitter tool configure.ac | 2 +- src/util/virdbus.c | 84 ++++++++++---- src/util/virdbus.h | 1 + tools/Makefile.am | 21 ++++ tools/libvirt-babysitter.c | 276 +++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 363 insertions(+), 21 deletions(-) create mode 100644 tools/libvirt-babysitter.c -- 1.7.12.1

4 9

[libvirt] [PATCH 00/12] Structured syslog (Lumberjack/CEE) support
by Miloslav Trmač 09 Oct '12

09 Oct '12

This patch set adds structured syslog support to libvirt. In short, the idea is to embed JSON in a syslog record. This format is used in a new log output type called "syslog/json". Example "syslog/json" record (line-wrapped for readability): Sep 20 19:59:40 kulicka libvirt: @cee: {"msg":"libvirt version: 0.10.1", "category":"../../src/test/test_driver.c","priority":"info", "funcname":"virLogVMessage","line":769, "timestamp":"2012-09-20 17:59:40.853+0000"} compared with existing "syslog" record format: Sep 20 20:02:24 kulicka libvirt: 5896: info : libvirt version: 0.10.1 This JSON embedding format is defined by the Lumberjack project led by the major Open Source syslog implementations (https://fedorahosted.org/lumberjack/) The format is also a base for a future MITRE CEE standard. Some of the fields are specified at https://fedorahosted.org/lumberjack/wiki/FieldList , but applications are free to use whatever fields make sense for them. The JSON structure makes easy to process logs by programs without writing code that understands the specific format used by each application, or using unreliable regexps (https://fedorahosted.org/ceelog/ is a companion project that allows processing such logs). Current systems will store and these records unmodified and present them to users unmodified, but tools (and probably /var/log/messages) will be able to show only the "msg" field; this allows us to add more detailed information without worsening the user experience (the example above already shows added information that is currently being thrown away when logging to syslog). The patch set, aside from building the required infrastructure, has two main components: * Add the "syslog/json" output type, and use it to record all information passed to virLogMessage. The example result is shown above. This primarily makes it easier to parse the message. * Allow callers of virLogMessage to add arbitrary additional JSON fields, and use it in virRaiseErrorFull and its callers. Because the additional fields for errors include virErrorDomain and virErrorNumber, this allows _programs_ to _automatically_ detect the event and react to it, perhaps alerting the user about a situation that requires immediate attention, or automatically suggesting a solution. This has not been possible until now because the current logs contain only a translated error message, so the log record doesn't contain anything stable that could be detected by a program. It is assumed that other parts of libvirt may add more event-specific JSON fields in the future, based on demand by applications that process the logs; I have, however, no immediate plans to add more. Miloslav Trmač (12): Drop unused return value of virLogOutputFunc Add JSON API for preallocated objects. Split yajl_gen allocation into a separate function. Split adding object properties from virJSONValueToStringOne Add a JSON generator API. Pass the "raw" log message to each virLogOutputFunc Split priority conversion from virLogOutputToSyslog Add "syslog/json" log output format. Add a JSON properties parameter to virLog{,V}Message Add a JSON properties parameter to virLogOutputFunc Add detailed error information to JSON syslog Add a test for the new error reporting mechanism. docs/logging.html.in | 3 + src/libvirt_private.syms | 4 + src/uml/uml_conf.c | 2 +- src/util/json.c | 232 +++++++++++++++++++++++++++++++++++++++++----- src/util/json.h | 26 ++++++ src/util/logging.c | 233 ++++++++++++++++++++++++++++++++++------------- src/util/logging.h | 35 +++---- src/util/viraudit.c | 4 +- src/util/virterror.c | 32 ++++++- tests/Makefile.am | 6 +- tests/errorjsontest.c | 211 ++++++++++++++++++++++++++++++++++++++++++ tests/testutils.c | 7 +- 12 files changed, 684 insertions(+), 111 deletions(-) create mode 100644 tests/errorjsontest.c -- 1.7.11.4

4 24

[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