- Devel - libvirt List Archives

[libvirt] [PATCH 0/7] qemu: PCI bridge support
by Ján Tomko 18 Apr '13

18 Apr '13

This series allows PCI bridges to be added and used. After patch 6/7 more buses are usable if the bridges and addresses are explicitly specified in the XML. After 7/7 bridges are auto-added and the new buses are used automatically. (This only works if there is enough space on bus 0 for the bridges, otherwise they need to be specified manually). (Documentation, tests and bridge hotplug is still missing) Contains slightly modified li guang's patches 1-3: https://www.redhat.com/archives/libvir-list/2013-February/msg00981.html and reworked address allocation for multiple buses https://www.redhat.com/archives/libvir-list/2013-February/msg00793.html Ján Tomko (5): qemu: QEMU_PCI constant consistency qemu: move PCI address check out of qemuPCIAddressAsString qemu: switch PCI address set from hash table to an array qemu: Add support for plugging devices into PCI bridges qemu: auto-add and use bridges liguang (2): add pci-bridge controller type qemu: build command line for pci-bridge device docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 3 +- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 551 ++++++++++++++++++++++++++++++------------ src/qemu/qemu_command.h | 4 +- tests/qemuhelptest.c | 21 +- 8 files changed, 421 insertions(+), 163 deletions(-) -- 1.8.1.5

8 46

[libvirt] [PATCH] Partially revert "cleanup: Don't include libvirt/libvirt.h"
by Eric Blake 17 Apr '13

17 Apr '13

This reverts the changes to remote_protocol.x made in commit 2d25fd4f410f65b40ef1c3d65124775a944f4025. It turns out that if 'dwarves' is installed, 'make check' fails if any *_LAST enum values are visible from within the .o file compiled from a .x file; including <libvirt/libvirt.h> prior to "internal.h" is the documented way to avoid exposing *_LAST enum elements. --- Pushing under the build-breaker rule. src/remote/remote_protocol.x | 1 + 1 file changed, 1 insertion(+) diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x index d384225..b957b8e 100644 --- a/src/remote/remote_protocol.x +++ b/src/remote/remote_protocol.x @@ -36,6 +36,7 @@ * 'REMOTE_'. This makes names quite long. */ +%#include <libvirt/libvirt.h> %#include "internal.h" %#include <arpa/inet.h> -- 1.8.1.4

2 1

[libvirt] [PATCH 00/10 v2] Cleanup: About header including
by Osier Yang 17 Apr '13

17 Apr '13

The public headers libvirt/libvirt.h, libvirt/virterror.h, libvirt/libvirt-qemu.h, and libvirt/libvirt-lxc.h shouldn't be included in internal source directly. Osier Yang (10): cleanup: Remove the duplicate header cleanup: Only include testutils.h once cleanup: Don't include libvirt/libvirt.h cleanup: Don't include libvirt/virterror.h syntax-check: Don't include duplicate header syntax-check: Don't include "libvirt.h" and "virterror.h" in "" form syntax-check: Include libvirt.h and virterror.h in <> form only in external tools syntax-check: Don't include libvirt-{qemu,lxc}.h internally syntax-check: Include libvirt-{qemu,lxc}.h in <> form only in external tools docs: Update hacking cfg.mk | 106 ++++++++++++++++++++++++++++++++++++++ daemon/libvirtd.c | 1 - daemon/remote.c | 2 - docs/hacking.html.in | 8 +-- include/libvirt/libvirt-lxc.h | 2 +- include/libvirt/libvirt-qemu.h | 2 +- python/libvirt-lxc-override.c | 4 +- python/libvirt-override.c | 4 +- python/libvirt-qemu-override.c | 4 +- python/typewrappers.h | 4 +- src/conf/node_device_conf.c | 1 - src/libvirt-qemu.c | 1 - src/network/bridge_driver.c | 1 - src/nodeinfo.h | 1 - src/openvz/openvz_conf.c | 1 - src/openvz/openvz_driver.c | 1 - src/parallels/parallels_driver.c | 1 - src/phyp/phyp_driver.c | 2 - src/qemu/qemu_capabilities.h | 1 - src/qemu/qemu_driver.c | 1 - src/remote/remote_driver.h | 2 - src/remote/remote_protocol.x | 1 - src/security/security_selinux.c | 1 - src/uml/uml_driver.c | 1 - src/util/virkeycode.h | 1 - src/util/virnetdevtap.c | 1 - src/xen/xen_hypervisor.c | 1 - tests/domainsnapshotxml2xmltest.c | 4 +- tests/esxutilstest.c | 4 +- tests/lxcxml2xmltest.c | 4 +- tests/openvzutilstest.c | 4 +- tests/qemuargv2xmltest.c | 4 +- tests/qemuhelptest.c | 4 +- tests/qemumonitortest.c | 4 +- tests/qemuxml2argvtest.c | 4 +- tests/qemuxml2xmltest.c | 4 +- tests/qemuxmlnstest.c | 4 +- tests/shunloadhelper.c | 2 - tests/shunloadtest.c | 4 +- tests/vmx2xmltest.c | 4 +- tests/xml2vmxtest.c | 4 +- tools/virsh.c | 4 +- 42 files changed, 148 insertions(+), 66 deletions(-) -- 1.8.1.4

3 24

[libvirt] [PATCH] qemu: Allow the disk wwn to have "0x" prefix
by Osier Yang 17 Apr '13

17 Apr '13

The recent qemu requires "0x" prefix for the disk wwn, this patch changes virValidateWWN to allow the prefix, and prepend "0x" if it's not specified. E.g. qemu-kvm: -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,\ drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,wwn=6000c60016ea71ad: Property 'scsi-hd.wwn' doesn't take value '6000c60016ea71ad' --- docs/schemas/basictypes.rng | 2 +- src/qemu/qemu_command.c | 8 ++++++-- src/util/virutil.c | 12 +++++++++--- tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args | 4 ++-- tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml | 2 +- 6 files changed, 20 insertions(+), 10 deletions(-) diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng index adaedd8..34c2254 100644 --- a/docs/schemas/basictypes.rng +++ b/docs/schemas/basictypes.rng @@ -280,7 +280,7 @@ <define name='wwn'> <data type='string'> - <param name='pattern'>[0-9a-fA-F]{16}</param> + <param name='pattern'>(0x)?[0-9a-fA-F]{16}</param> </data> </define> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 63b9350..009d42d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3358,8 +3358,12 @@ qemuBuildDriveDevStr(virDomainDefPtr def, disk->blockio.physical_block_size); } - if (disk->wwn) - virBufferAsprintf(&opt, ",wwn=%s", disk->wwn); + if (disk->wwn) { + if (STRPREFIX(disk->wwn, "0x")) + virBufferAsprintf(&opt, ",wwn=%s", disk->wwn); + else + virBufferAsprintf(&opt, ",wwn=0x%s", disk->wwn); + } if (disk->vendor) virBufferAsprintf(&opt, ",vendor=%s", disk->vendor); diff --git a/src/util/virutil.c b/src/util/virutil.c index 0e4063b..6890362 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -3228,12 +3228,18 @@ bool virIsDevMapperDevice(const char *dev_name ATTRIBUTE_UNUSED) bool virValidateWWN(const char *wwn) { int i; + const char *p = wwn; - for (i = 0; wwn[i]; i++) - if (!c_isxdigit(wwn[i])) + if (STRPREFIX(wwn, "0x")) { + p += 2; + } + + for (i = 0; p[i]; i++) { + if (!c_isxdigit(p[i])) break; + } - if (i != 16 || wwn[i]) { + if (i != 16 || p[i]) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Malformed wwn: %s")); return false; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args index 1633d29..3b9693c 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-ide-wwn.args @@ -2,5 +2,5 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \ /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefaults \ -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -usb \ -drive file=/dev/HostVG/QEMUGuest1,if=none,id=drive-ide0-0-1,serial=WD-WMAP9A966149 \ --device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,wwn=5000c50015ea71ad \ +-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,wwn=0x5000c50015ea71ad \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args index 0393640..0dd2aa9 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.args @@ -5,7 +5,7 @@ LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \ -device lsi,id=scsi1,bus=pci.0,addr=0x4 \ -usb \ -drive file=/dev/HostVG/QEMUGuest1,if=none,id=drive-scsi0-0-1-0 \ --device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0,wwn=5000c50015ea71ac \ +-device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0,wwn=0x5000c50015ea71ac \ -drive file=/dev/HostVG/QEMUGuest2,if=none,id=drive-scsi0-0-0-0 \ --device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,wwn=5000c50015ea71ad \ +-device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,wwn=0x5000c50015ea71ad \ -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml index dc35548..caf957b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-disk-wwn.xml @@ -25,7 +25,7 @@ <source dev='/dev/HostVG/QEMUGuest2'/> <target dev='sdb' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> - <wwn>5000c50015ea71ad</wwn> + <wwn>0x5000c50015ea71ad</wwn> </disk> <controller type='usb' index='0'/> <controller type='scsi' index='0' model='virtio-scsi'/> -- 1.8.1.4

2 3

[libvirt] [PATCH] docs: Add detailed notes snapshots, blockcommit, blockpull
by Kashyap Chamarthy 17 Apr '13

17 Apr '13

More elaborate notes on snapshots, blockpull, blockcommit. Much of this is derived from various dicussions with Eric Blake, Jeff Cody, Kevin Wolf (thanks a lot!) & several others on IRC and mailing lists and a lot of adhoc testing. I didn't wanted this to get lost. I also plan to add notes for 'blockcopy' once I complete testing with upstream libvirt/qemu git. NOTE: This document is formatted using reStructuredText. And can be trivially converted to HTML using: # rst2html snapshots-blockcommit-blockpull.rst > snapshots-blockcommit-blockpull.html ('rst2html' is part of python-docutils package.) I didn't send an html PATCH directly, as I thought, this'd be more readable. Any comments, criticisms more than welcome. --- docs/snapshots-blockcommit-blockpull.rst | 646 ++++++++++++++++++++++++++++++ 1 files changed, 646 insertions(+), 0 deletions(-) create mode 100644 docs/snapshots-blockcommit-blockpull.rst diff --git a/docs/snapshots-blockcommit-blockpull.rst b/docs/snapshots-blockcommit-blockpull.rst new file mode 100644 index 0000000000000000000000000000000000000000..99c30223a004ee5291e2914b788ac7fe04eee3c8 --- /dev/null +++ b/docs/snapshots-blockcommit-blockpull.rst @@ -0,0 +1,646 @@ +.. ---------------------------------------------------------------------- + Note: All these tests were performed with latest qemu-git,libvirt-git (as of + 20-Oct-2012 on a Fedora-18 alpha machine +.. ---------------------------------------------------------------------- + + +Introduction +============ + +A virtual machine snapshot is a view of a virtual machine(its OS & all its +applications) at a given point in time. So that, one can revert to a known sane +state, or take backups while the guest is running live. So, before we dive into +snapshots, let's have an understanding of backing files and overlays. + + + +QCOW2 backing files & overlays +------------------------------ + +In essence, QCOW2(Qemu Copy-On-Write) gives you an ability to create a base-image, +and create several 'disposable' copy-on-write overlay disk images on top of the +base image(also called backing file). Backing files and overlays are +extremely useful to rapidly instantiate thin-privisoned virtual machines(more on +it below). Especially quite useful in development & test environments, so that +one could quickly revert to a known state & discard the overlay. + +**Figure-1** + +:: + + .--------------. .-------------. .-------------. .-------------. + | | | | | | | | + | RootBase |<---| Overlay-1 |<---| Overlay-1A <--- | Overlay-1B | + | (raw/qcow2) | | (qcow2) | | (qcow2) | | (qcow2) | + '--------------' '-------------' '-------------' '-------------' + +The above figure illustrates - RootBase is the backing file for Overlay-1, which +in turn is backing file for Overlay-2, which in turn is backing file for +Overlay-3. + +**Figure-2** +:: + + .-----------. .-----------. .------------. .------------. .------------. + | | | | | | | | | | + | RootBase |<--- Overlay-1 |<--- Overlay-1A <--- Overlay-1B <--- Overlay-1C | + | | | | | | | | | (Active) | + '-----------' '-----------' '------------' '------------' '------------' + ^ ^ + | | + | | .-----------. .------------. + | | | | | | + | '-------| Overlay-2 |<---| Overlay-2A | + | | | | (Active) | + | '-----------' '------------' + | + | + | .-----------. .------------. + | | | | | + '------------| Overlay-3 |<---| Overlay-3A | + | | | (Active) | + '-----------' '------------' + +The above figure is just another representation which indicates, we can use a +'single' backing file, and create several overlays -- which can be used further, +to create overlays on top of them. + + +**NOTE**: Backing files are always opened **read-only**. In other words, once + an overlay is created, its backing file should not be modified(as the + overlay depends on a particular state of the backing file). Refer + below ('blockcommit' section) for relevant info on this. + + +**Example** : + +:: + + [FedoraBase.img] ----- <- [Fedora-guest-1.qcow2] <- [Fed-w-updates.qcow2] <- [Fedora-guest-with-updates-1A] + \ + \--- <- [Fedora-guest-2.qcow2] <- [Fed-w-updates.qcow2] <- [Fedora-guest-with-updates-2A] + +(Arrow to be read as Fed-w-updates.qcow2 has Fedora-guest-1.qcow2 as its backing file.) + +In the above example, say, *FedoraBase.img* has a freshly installed Fedora-17 OS on it, +and let's establish it as our backing file. Now, FedoraBase can be used as a +read-only 'template' to quickly instantiate two(or more) thinly provisioned +Fedora-17 guests(say Fedora-guest-1.qcow2, Fedora-guest-2.qcow2) by creating +QCOW2 overlay files pointing to our backing file. Also, the example & *Figure-2* +above illustrate that a single root-base image(FedoraBase.img) can be used +to create multiple overlays -- which can subsequently have their own overlays. + + + To create two thinly-provisioned Fedora clones(or overlays) using a single + backing file, we can invoke qemu-img as below: :: + + + # qemu-img create -b /export/vmimages/RootBase.img -f qcow2 \ + /export/vmimages/Fedora-guest-1.qcow2 + + # qemu-img create -b /export/vmimages/RootBase.img -f qcow2 \ + /export/vmimages/Fedora-guest-2.qcow2 + + Now, both the above images *Fedora-guest-1* & *Fedora-guest-2* are ready to + boot. Continuting with our example, say, now you want to instantiate a + Fedora-17 guest, but this time, with full Fedora updates. This can be + accomplished by creating another overlay(Fedora-guest-with-updates-1A) - but + this overly would point to 'Fed-w-updates.qcow2' as its backing file (which + has the full Fedora updates) :: + + # qemu-img create -b /export/vmimages/Fed-w-updates.qcow2 -f qcow2 \ + /export/vmimages/Fedora-guest-with-updates-1A.qcow2 + + + Information about a disk image, like virtual size, disk size, backing file(if it + exists) can be obtained by using 'qemu-img' as below: + :: + + # qemu-img info /export/vmimages/Fedora-guest-with-updates-1A.qcow2 + + NOTE: With latest qemu, an entire backing chain can be recursively + enumerated by doing: + :: + + # qemu-img info --backing-chain /export/vmimages/Fedora-guest-with-updates-1A.qcow2 + + + +Snapshot Terminology: +--------------------- + + - **Internal Snapshots** -- A single qcow2 image file holds both the saved state + & the delta since that saved point. This can be further classified as :- + + (1) **Internal disk snapshot**: The state of the virtual disk at a given + point in time. Both the snapshot & delta since the snapshot are + stored in the same qcow2 file. Can be taken when the guest is 'live' + or 'offline'. + + - Libvirt uses QEMU's 'qemu-img' command when the guest is 'offline'. + - Libvirt uses QEMU's 'savevm' command when the guest is 'live'. + + (2) **Internal system checkpoint**: RAM state, device state & the + disk-state of a running guest, are all stored in the same originial + qcow2 file. Can be taken when the guest is running 'live'. + + - Libvirt uses QEMU's 'savevm' command when the guest is 'live' + + + - **External Snapshots** -- Here, when a snapshot is taken, the saved state will + be stored in one file(from that point, it becomes a read-only backing + file) & a new file(overlay) will track the deltas from that saved state. + This can be further classified as :- + + (1) **External disk snapshot**: The snapshot of the disk is saved in one + file, and the delta since the snapshot is tracked in a new qcow2 + file. Can be taken when the guest is 'live' or 'offline'. + + - Libvirt uses QEMU's 'transaction' cmd under the hood, when the + guest is 'live'. + + - Libvirt uses QEMU's 'qemu-img' cmd under the hood when the + guest is 'offline'(this implementation is in progress, as of + writing this). + + (2) **External system checkpoint**: Here, the guest's disk-state will be + saved in one file, its RAM & device-state will be saved in another + new file (This implementation is in progress upstream libvirt, as of + writing this). + + + + - **VM State**: Saves the RAM & device state of a running guest(not 'disk-state') to + a file, so that it can be restored later. This simliar to doing hibernate + of the system. (NOTE: The disk-state should be unmodified at the time of + restoration.) + + - Libvirt uses QEMU's 'migrate' (to file) cmd under the hood. + + + +Creating snapshots +================== + - Whenever an 'external' snapshot is issued, a /new/ overlay image is + created to facilitate guest writes, and the previous image becomes a + snapshot. + + - **Create a disk-only internal snapshot** + + (1) If I have a guest named 'f17vm1', to create an offline or online + 'internal' snapshot called 'snap1' with description 'snap1-desc' :: + + # virsh snapshot-create-as f17vm1 snap1 snap1-desc + + (2) List the snapshot ; and query using *qemu-img* tool to view + the image info & its internal snapshot details :: + + # virsh snapshot-list f17vm1 + # qemu-img info /home/kashyap/vmimages/f17vm1.qcow2 + + + + - **Create a disk-only external snapshot** : + + (1) List the block device associated with the guest. :: + + # virsh domblklist f17-base + Target Source + --------------------------------------------- + vda /export/vmimages/f17-base.qcow2 + + # + + (2) Create external disk-only snapshot (while the guest is *running*). :: + + # virsh snapshot-create-as --domain f17-base snap1 snap1-desc \ + --disk-only --diskspec vda,snapshot=external,file=/export/vmimages/sn1-of-f17-base.qcow2 \ + --atomic + Domain snapshot snap1 created + # + + * Once the above command is issued, the original disk-image + of f17-base will become the backing_file & a new overlay + image is created to track the new changes. Here on, libvirt + will use this overlay for further write operations(while + using the original image as a read-only backing_file). + + (3) Now, list the block device associated(use cmd from step-1, above) + with the guest,again, to ensure it reflects the new overlay image as + the current block device in use. :: + + # virsh domblklist f17-base + Target Source + ---------------------------------------------------- + vda /export/vmimages/sn1-of-f17-base.qcow2 + + # + + + + +Reverting to snapshots +====================== +As of writing this, reverting to 'Internal Snapshots'(system checkpoint or +disk-only) is possible. + + To revert to a snapshot named 'snap1' of domain f17vm1 :: + + # virsh snapshot-revert --domain f17vm1 snap1 + +Reverting to 'external disk snapshots' using *snapshot-revert* is a little more +tricky, as it involves slightly complicated process of dealing with additional +snapshot files - whether to merge 'base' images into 'top' or to merge other way +round ('top' into 'base'). + +That said, there are a couple of ways to deal with external snapshot files by +merging them to reduce the external snapshot disk image chain by performing +either a **blockpull** or **blockcommit** (more on this below). + +Further improvements on this front is in work upstream libvirt as of writing +this. + + + +Merging snapshot files +====================== +External snapshots are incredibly useful. But, with plenty of external snapshot +files, there comes a problem of maintaining and tracking all these inidivdual +files. At a later point in time, we might want to 'merge' some of these snapshot +files (either backing_files into overlays or vice-versa) to reduce the length of +the image chain. To accomplish that, there are two mechanisms: + + + blockcommit: merges data from **top** into **base** (in other + words, merge overlays into backing files). + + + + blockpull: Populates a disk image with data from its backing file. Or + merges data from **base** into **top** (in other words, merge backing files + into overlays). + + +blockcommit +----------- + +Block Commit allows you to merge from a 'top' image(within a disk backing file +chain) into a lower-level 'base' image. To rephrase, it allows you to +merge overlays into backing files. Once the **blockcommit** operation is finished, +any portion that depends on the 'top' image, will now be pointing to the 'base'. + +This is useful in flattening(or collapsing or reducing) backing file chain +length after taking several external snapshots. + + +Let's understand with an illustration below: + +We have a base image called 'RootBase', which has a disk image chain with 4 +external snapshots. With 'Active' as the current active-layer, where 'live' guest +writes happen. There are a few possibilities of resulting image chains that we +can end up with, using 'blockcommit' : + + (1) Data from Snap-1, Snap-2 and Snap-3 can be merged into 'RootBase' + (resulting in RootBase becoming the backing_file of 'Active', and thus + invalidating Snap-1, Snap-2, & Snap-3). + + (2) Data from Snap-1 and Snap-2 can be merged into RootBase(resulting in + Rootbase becoming the backing_file of Snap-3, and thus invalidating + Snap-1 & Snap-2). + + (3) Data from Snap-1 can be merged into RootBase(resulting in RootBase + becoming the backing_file of Snap-2, and thus invalidating Snap-1). + + (4) Data from Snap-2 can be merged into Snap-1(resulting in Snap-1 becoming + the backing_file of Snap-3, and thus invalidating Snap-2). + + (5) Data from Snap-3 can be merged into Snap-2(resulting in Snap-2 becoming + the backing_file for 'Active', and thus invalidating Snap-3). + + (6) Data from Snap-2 and Snap-3 can be merged into Snap-1(resulting in + Snap-1 becoming the backing_file of 'Active', and thus invalidating + Snap-2 & Snap-3). + + NOTE: Eventually(not supported in qemu as of writing this), we can also + merge down the 'Active' layer(the top-most overlay) into its + backing_files. Once it is supported, the 'top' argument can become + optional, and default to active layer. + + +(The below figure illustrates case (6) from the above) + +**Figure-3** +:: + + .------------. .------------. .------------. .------------. .------------. + | | | | | | | | | | + | RootBase <--- Snap-1 <--- Snap-2 <--- Snap-3 <--- Snap-4 | + | | | | | | | | | (Active) | + '------------' '------------' '------------' '------------' '------------' + / | + / | + / commit data | + / | + / | + / | + v commit data | + .------------. .------------. <--------------------' .------------. + | | | | | | + | RootBase <--- Snap-1 |<---------------------------------| Snap-4 | + | | | | Backing File | (Active) | + '------------' '------------' '------------' + +For instance, if we have the below scenario: + + Actual: [base] <- sn1 <- sn2 <- sn3 <- sn4(this is active) + + Desired: [base] <- sn1 <- sn4 (thus invalidating sn2,sn3) + + Any of the below two methods is valid (as of 17-Oct-2012 qemu-git). With + method-a, operation will be faster & correct if we don't care about + sn2(because, it'll be invalidated). Note that, method-b is slower, but sn2 + will remain valid. (Also note that, the guest is 'live' in all these cases). + + **(method-a)**: + :: + + # virsh blockcommit --domain f17 vda --base /export/vmimages/sn1.qcow2 --top /export/vmimages/sn3.qcow2 --wait --verbose + + [OR] + + **(method-b)**: + :: + + # virsh blockcommit --domain f17 vda --base /export/vmimages/sn2.qcow2 --top /export/vmimages/sn3.qcow2 --wait --verbose + # virsh blockcommit --domain f17 vda --base /export/vmimages/sn1.qcow2 --top /export/vmimages/sn2.qcow2 --wait --verbose + + NOTE: If we had to do manually with *qemu-img* cmd, we can only do method-b at the moment. + + +**Figure-4** +:: + + .------------. .------------. .------------. .------------. .------------. + | | | | | | | | | | + | RootBase <--- Snap-1 <--- Snap-2 <--- Snap-3 <--- Snap-4 | + | | | | | | | | | (Active) | + '------------' '------------' '------------' '------------' '------------' + / | | + / | | + / | | + commit data / commit data | | + / | | + / | commit data | + v | | + .------------.<----------------------|-------------' .------------. + | |<----------------------' | | + | RootBase | | Snap-4 | + | |<-------------------------------------------------| (Active) | + '------------' Backing File '------------' + + +The above figure is another representation of reducing the disk image chain +using blockcommit. Data from Snap-1, Snap-2, Snap-3 are merged(/committed) +into RootBase, & now the current 'Active' image now pointing to 'RootBase' as its +backing file(instead of Snap-3, which was the case *before* blockcommit). Note +that, now intermediate images Snap-1, Snap-1, Snap-3 will be invalidated(as they were +dependent on a particular state of RootBase). + +blockpull +--------- +Block Pull(also called 'Block Stream' in QEMU's paralance) allows you to merge +into 'base' from a 'top' image(within a disk backing file chain). To rephrase it +allows merging backing files into an overlay(active). This works in the +opposite side of 'blockcommit' to flatten the snapshot chain. At the moment, +**blockpull** can pull only into the active layer(the top-most image). It's +worth noting here that, intermediate images are not invalidated once a blockpull +operation is complete (while blockcommit, invalidates them). + + +Consider the below illustration: + +**Figure-5** +:: + + .------------. .------------. .------------. .------------. .------------. + | | | | | | | | | | + | RootBase <--- Snap-1 <--- Snap-2 <--- Snap-3 <--- Snap-4 | + | | | | | | | | | (Active) | + '------------' '------------' '------------' '------------' '------------' + | | \ + | | \ + | | \ + | | \ stream data + | | stream data \ + | stream data | \ + | | v + .------------. | '---------------> .------------. + | | '---------------------------------> | | + | RootBase | | Snap-4 | + | | <---------------------------------------- | (Active) | + '------------' Backing File '------------' + + + +The above figure illustrates that, using block-copy we can pull data from +Snap-1, Snap-2 and Snap-3 into the 'Active' layer, resulting in 'RootBase' +becoming the backing file for the 'Active' image (instead of 'Snap-3', which was +the case before doing the blockpull operation). + +The command flow would be: + (1) Assuming a external disk-only snapshot was created as mentioned in + *Creating Snapshots* section: + + (2) A blockpull operation can be issued this way, to achieve the desired + state of *Figure-5*-- [RootBase] <- [Active]. :: + + # virsh blockpull --domain RootBase --path var/lib/libvirt/images/active.qcow2 --base /var/lib/libvirt/images/RootBase.qcow2 --wait --verbose + + + As a follow up, we can do the below to clean-up the snapshot *tracking* + metadata by libvirt (note: the below does not 'remove' the files, it + just cleans up the snapshot tracking metadata). :: + + # virsh snapshot-delete --domain RootBase Snap-3 --metadata + # virsh snapshot-delete --domain RootBase Snap-2 --metadata + # virsh snapshot-delete --domain RootBase Snap-1 --metadata + + + + +**Figure-6** +:: + + .------------. .------------. .------------. .------------. .------------. + | | | | | | | | | | + | RootBase <--- Snap-1 <--- Snap-2 <--- Snap-3 <--- Snap-4 | + | | | | | | | | | (Active) | + '------------' '------------' '------------' '------------' '------------' + | | | \ + | | | \ + | | | \ stream data + | | | stream data \ + | | | \ + | | stream data | \ + | stream data | '------------------> v + | | .--------------. + | '---------------------------------> | | + | | Snap-4 | + '----------------------------------------------------> | (Active) | + '--------------' + 'Standalone' + (w/o backing + file) + +The above figure illustrates, once blockpull operation is complete, by +pulling/streaming data from RootBase, Snap-1, Snap-2, Snap-3 into 'Active', all +the backing files can be discarded and 'Active' now will be a standalone image +without any backing files. + +Command flow would be: + (0) Assuming 4 external disk-only (live) snapshots were created as + mentioned in *Creating Snapshots* section, + + (1) Let's check the snapshot overlay images size *before* blockpull operation (note the image of 'Active'): + :: + + # ls -lash /var/lib/libvirt/images/RootBase.img + 608M -rw-r--r--. 1 qemu qemu 1.0G Oct 11 17:54 /var/lib/libvirt/images/RootBase.img + + # ls -lash /var/lib/libvirt/images/*Snap* + 840K -rw-------. 1 qemu qemu 896K Oct 11 17:56 /var/lib/libvirt/images/Snap-1.qcow2 + 392K -rw-------. 1 qemu qemu 448K Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2 + 456K -rw-------. 1 qemu qemu 512K Oct 11 17:56 /var/lib/libvirt/images/Snap-3.qcow2 + 2.9M -rw-------. 1 qemu qemu 3.0M Oct 11 18:10 /var/lib/libvirt/images/Active.qcow2 + + (2) Also, check the disk image information of 'Active'. It can noticed that + 'Active' has Snap-3 as its backing file. :: + + # qemu-img info /var/lib/libvirt/images/Active.qcow2 + image: /var/lib/libvirt/images/Active.qcow2 + file format: qcow2 + virtual size: 1.0G (1073741824 bytes) + disk size: 2.9M + cluster_size: 65536 + backing file: /var/lib/libvirt/images/Snap-3.qcow2 + + (3) Do the **blockpull** operation. :: + + # virsh blockpull --domain ptest2-base --path /var/lib/libvirt/images/Active.qcow2 --wait --verbose + Block Pull: [100 %] + Pull complete + + (4) Let's again check the snapshot overlay images size *after* + blockpull operation. It can be noticed, 'Active' is now considerably larger. :: + + # ls -lash /var/lib/libvirt/images/*Snap* + 840K -rw-------. 1 qemu qemu 896K Oct 11 17:56 /var/lib/libvirt/images/Snap-1.qcow2 + 392K -rw-------. 1 qemu qemu 448K Oct 11 17:56 /var/lib/libvirt/images/Snap-2.qcow2 + 456K -rw-------. 1 qemu qemu 512K Oct 11 17:56 /var/lib/libvirt/images/Snap-3.qcow2 + 1011M -rw-------. 1 qemu qemu 3.0M Oct 11 18:29 /var/lib/libvirt/images/Active.qcow2 + + + (5) Also, check the disk image information of 'Active'. It can now be + noticed that 'Active' is a standalone image without any backing file - + which is the desired state of *Figure-6*.:: + + # qemu-img info /var/lib/libvirt/images/Active.qcow2 + image: /var/lib/libvirt/images/Active.qcow2 + file format: qcow2 + virtual size: 1.0G (1073741824 bytes) + disk size: 1.0G + cluster_size: 65536 + + (6) We can now clean-up the snapshot tracking metadata by libvirt to + reflect the new reality :: + + # virsh snapshot-delete --domain RootBase Snap-3 --metadata + + (7) Optionally, one can check, the guest disk contents by invoking + *guestfish* tool(part of *libguestfs*) **READ-ONLY** (*--ro* option + below does it) as below :: + + # guestfish --ro -i -a /var/lib/libvirt/images/Active.qcow2 + + +Deleting snapshots (and 'offline commit') +========================================= + +Deleting (live/offline) *Internal Snapshots* (where the originial & all the named snapshots +are stored in a single QCOW2 file), is quite straight forward. :: + + # virsh snapshot-delete --domain f17vm --snapshotname snap6 + + [OR] + + # virsh snapshot-delete f17vm snap6 + +Deleting External snapshots (offline), Libvirt has not acquired the capability. +But, it can be done via *qemu-img* manipulation. + +Say, we have this image chain(the guest is *offline* here): **base <- sn1 <- sn2 <- sn3** +(arrow to be read as 'sn3 has sn2 as its backing file'). + + +And, we want to delete the second snapshot(sn2). It's possible to do it in two +ways: + + + - **Method (1)**: **base <- sn1 <- sn3** (by copying sn2 into sn1) + - **Method (2)**: **base <- sn1 <- sn3** (by copying sn2 into sn3) + +Method (1) +---------- +To end up with this image chain : **base <- sn1 <- sn3** (by copying *sn2* into *sn1*) + +**NOTE**: This is only possible *if* sn1 isn't used by more images as their backing +file, or they'd get corrupted!! + + (a) We're doing an *offline commit* (similar to what *blockcommit* can do + to an *online* guest). :: + + # qemu-img commit sn2.qcow2 + + - This will *commit* the changes from sn2 into its backing file(which is + sn1). + + (b) Now that we've comitted changes from sn2 into sn1, let's change the + backing file link in sn3 to point to sn1. :: + + # qemu-img rebase -u -b sn1.qcow2 sn3.qcow2 + + - **NOTE**: This is 'Unsafe mode' -- in this mode, only the backing file + name is changed w/o any checks on the file contents. The user must + take care of specifying the correct new backing file, or the + guest-visible. This mode is useful for renaming or moving the + backing file to somewhere else. It can be used without an + accessible old backing file, i.e. you can use it to fix an image + whose backing file has already been moved/renamed. + + + (c) Now, we can delete the sn2 disk image(as the changes are now committed + to sn1). :: + + # rm sn2.qcow2 + + +Method (2) +---------- +To end up with this image chain : **base <- sn1 <- sn3** (by copying *sn2* into *sn3*) + + (a) Copy contents of sn2(the old backing file) into sn3, and change the backing file link of sn3 to sn1:: + + # qemu-img rebase -b sn1.qcow2 sn3.qcow2 + + - Apart from changing backing file link of sn3 to sn1, the above cmd + will it also /copy/ the contents from sn2 into sn3). + + - In other words: This is 'Safe mode', which is the default -- + any clusters that differ between the new backing_file(in this + case, sn1) and the old backing file(in this case, sn2) of + filename(in this case, sn3) are merged into filename(sn3), before + actually changing the backing file. + + (b) Now, we can delete the sn2 disk image(as the changes are now committed to + sn1). :: + + # rm sn2.qcow2 + -- 1.7.7.6

4 6

[libvirt] [libvirt-php] Allow block devices in libvirt_domain_disk_add
by Martijn Otto 17 Apr '13

17 Apr '13

I have written a patch to the libvirt_domain_disk_add function which does the following things: 1. Allow adding block devices as disks with libvirt_domain_disk_add 2. Removed the xflags parameter (not relevant as no xml is returned anyways) 3. Added the cache option to control cache mode (either default, none, writeback or writethrough) 4. Added the io option to control the used io mode (either default, native or threads) Besides this, I have rewritten it so it now uses the virDomainAttachDevice function, which is meant for these things, instead of pasting the device XML by hand into the domain XML. I have uploaded this to my github clone at https://github.com/martijnotto/libvirt-php It would be nice if this could be included in a future release of lbvirt-php. If the code does not meet a coding standard for libvirt-php or if there is some other concern, please let me know and I will do what I can to improve it. With Regards, Martijn Otto Copernica B.V.

1 0

[libvirt] [PATCH v2] qemu: Implement CPUs check against machine type's cpu-max
by Michal Novotny 17 Apr '13

17 Apr '13

Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. Signed-off-by: Michal Novotny <minovotn(a)redhat.com> --- src/conf/capabilities.h | 1 + src/qemu/qemu_capabilities.c | 40 +++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_capabilities.h | 3 ++- src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 7 +++++++ src/qemu/qemu_process.c | 27 +++++++++++++++++++++++++++ 6 files changed, 77 insertions(+), 2 deletions(-) diff --git a/src/conf/capabilities.h b/src/conf/capabilities.h index abcf6de..16bf3de 100644 --- a/src/conf/capabilities.h +++ b/src/conf/capabilities.h @@ -46,6 +46,7 @@ typedef virCapsGuestMachine *virCapsGuestMachinePtr; struct _virCapsGuestMachine { char *name; char *canonical; + int cpu_max; }; typedef struct _virCapsGuestDomainInfo virCapsGuestDomainInfo; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index d10c8aa..a03a643 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -243,6 +243,7 @@ struct _virQEMUCaps { size_t nmachineTypes; char **machineTypes; char **machineAliases; + int *machineMaxCpus; }; struct _virQEMUCapsCache { @@ -322,6 +323,7 @@ virQEMUCapsSetDefaultMachine(virQEMUCapsPtr qemuCaps, { char *name = qemuCaps->machineTypes[defIdx]; char *alias = qemuCaps->machineAliases[defIdx]; + int cpu_max = qemuCaps->machineMaxCpus[defIdx]; memmove(qemuCaps->machineTypes + 1, qemuCaps->machineTypes, @@ -329,8 +331,12 @@ virQEMUCapsSetDefaultMachine(virQEMUCapsPtr qemuCaps, memmove(qemuCaps->machineAliases + 1, qemuCaps->machineAliases, sizeof(qemuCaps->machineAliases[0]) * defIdx); + memmove(qemuCaps->machineMaxCpus + 1, + qemuCaps->machineMaxCpus, + sizeof(qemuCaps->machineMaxCpus[0]) * defIdx); qemuCaps->machineTypes[0] = name; qemuCaps->machineAliases[0] = alias; + qemuCaps->machineMaxCpus[0] = cpu_max; } /* Format is: @@ -377,7 +383,8 @@ virQEMUCapsParseMachineTypesStr(const char *output, } if (VIR_REALLOC_N(qemuCaps->machineTypes, qemuCaps->nmachineTypes + 1) < 0 || - VIR_REALLOC_N(qemuCaps->machineAliases, qemuCaps->nmachineTypes + 1) < 0) { + VIR_REALLOC_N(qemuCaps->machineAliases, qemuCaps->nmachineTypes + 1) < 0 || + VIR_REALLOC_N(qemuCaps->machineMaxCpus, qemuCaps->nmachineTypes + 1) < 0) { VIR_FREE(name); VIR_FREE(canonical); goto no_memory; @@ -390,6 +397,8 @@ virQEMUCapsParseMachineTypesStr(const char *output, qemuCaps->machineTypes[qemuCaps->nmachineTypes-1] = name; qemuCaps->machineAliases[qemuCaps->nmachineTypes-1] = NULL; } + /* Value 0 means "unknown" as it's not exposed by QEMU binary */ + qemuCaps->machineMaxCpus[qemuCaps->nmachineTypes-1] = 0; } while ((p = next)); @@ -1718,6 +1727,8 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr qemuCaps) goto no_memory; if (VIR_ALLOC_N(ret->machineAliases, qemuCaps->nmachineTypes) < 0) goto no_memory; + if (VIR_ALLOC_N(ret->machineMaxCpus, qemuCaps->nmachineTypes) < 0) + goto no_memory; ret->nmachineTypes = qemuCaps->nmachineTypes; for (i = 0 ; i < qemuCaps->nmachineTypes ; i++) { if (!(ret->machineTypes[i] = strdup(qemuCaps->machineTypes[i]))) @@ -1725,6 +1736,7 @@ virQEMUCapsPtr virQEMUCapsNewCopy(virQEMUCapsPtr qemuCaps) if (qemuCaps->machineAliases[i] && !(ret->machineAliases[i] = strdup(qemuCaps->machineAliases[i]))) goto no_memory; + ret->machineMaxCpus[i] = qemuCaps->machineMaxCpus[i]; } return ret; @@ -1885,9 +1897,11 @@ int virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr qemuCaps, goto no_memory; if (!(mach->canonical = strdup(qemuCaps->machineTypes[i]))) goto no_memory; + mach->cpu_max = qemuCaps->machineMaxCpus[i]; } else { if (!(mach->name = strdup(qemuCaps->machineTypes[i]))) goto no_memory; + mach->cpu_max = qemuCaps->machineMaxCpus[i]; } (*machines)[i] = mach; } @@ -1923,6 +1937,25 @@ const char *virQEMUCapsGetCanonicalMachine(virQEMUCapsPtr qemuCaps, } +int virQEMUCapsGetMachineMaxCpus(virQEMUCapsPtr qemuCaps, + const char *name) +{ + size_t i; + + if (!name) + return 0; + + for (i = 0 ; i < qemuCaps->nmachineTypes ; i++) { + if (!qemuCaps->machineMaxCpus[i]) + continue; + if (STREQ(qemuCaps->machineTypes[i], name)) + return qemuCaps->machineMaxCpus[i]; + } + + return 0; +} + + static int virQEMUCapsProbeQMPCommands(virQEMUCapsPtr qemuCaps, qemuMonitorPtr mon) @@ -2073,6 +2106,10 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, virReportOOMError(); goto cleanup; } + if (VIR_ALLOC_N(qemuCaps->machineMaxCpus, nmachines) < 0) { + virReportOOMError(); + goto cleanup; + } for (i = 0 ; i < nmachines ; i++) { if (machines[i]->alias) { @@ -2087,6 +2124,7 @@ virQEMUCapsProbeQMPMachineTypes(virQEMUCapsPtr qemuCaps, } if (machines[i]->isDefault) defIdx = i; + qemuCaps->machineMaxCpus[i] = machines[i]->cpu_max; } qemuCaps->nmachineTypes = nmachines; diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 728add5..8205ff7 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -224,7 +224,8 @@ size_t virQEMUCapsGetMachineTypes(virQEMUCapsPtr qemuCaps, char ***names); const char *virQEMUCapsGetCanonicalMachine(virQEMUCapsPtr qemuCaps, const char *name); - +int virQEMUCapsGetMachineMaxCpus(virQEMUCapsPtr qemuCaps, + const char *name); int virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr qemuCaps, size_t *nmachines, virCapsGuestMachinePtr **machines); diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index f39f009..c097953 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -650,6 +650,7 @@ struct _qemuMonitorMachineInfo { char *name; bool isDefault; char *alias; + int cpu_max; }; int qemuMonitorGetMachines(qemuMonitorPtr mon, diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 6fdd650..adbd865 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -4024,6 +4024,13 @@ int qemuMonitorJSONGetMachines(qemuMonitorPtr mon, goto cleanup; } } + + if (virJSONValueObjectHasKey(child, "cpu-max") && + virJSONValueObjectGetNumberInt(child, "cpu-max", &info->cpu_max) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("query-machines reply has malformed 'cpu-max' data")); + goto cleanup; + } } ret = n; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index ce9f501..9eae8f6 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3266,6 +3266,30 @@ qemuSetUnprivSGIO(virDomainDiskDefPtr disk) return ret; } +static bool +qemuValidateCpuMax(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) +{ + int cpu_max; + + cpu_max = virQEMUCapsGetMachineMaxCpus(qemuCaps, def->os.machine); + if (!cpu_max) + return true; + + if (def->vcpus > cpu_max) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + "%s", _("CPUs greater than specified machine type limit")); + return false; + } + + if (def->maxvcpus > cpu_max) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + "%s", _("Maximum CPUs greater than specified machine type limit")); + return false; + } + + return true; +} + int qemuProcessStart(virConnectPtr conn, virQEMUDriverPtr driver, virDomainObjPtr vm, @@ -3481,6 +3505,9 @@ int qemuProcessStart(virConnectPtr conn, vm->def->emulator))) goto cleanup; + if (!qemuValidateCpuMax(vm->def, priv->qemuCaps)) + goto cleanup; + if (qemuAssignDeviceAliases(vm->def, priv->qemuCaps) < 0) goto cleanup; -- 1.7.11.7

2 1

[libvirt] (no subject)
by David Scott 17 Apr '13

17 Apr '13

Hi, I've made an improved set of ocaml bindings for the libvirt event mechanism which I'm now reasonably happy with. Improvements since my first submission: 1. it's possible to deregister callbacks with 'deregister_any' 2. the callback to ocaml now re-acquires the heap lock *before* creating and registering OCaml values with the GC: the previous patches got this wrong and bad things happened 3. it's possible to add and remove timer callbacks: this is used in the example to run Gc.compact() often, to check for problems 4. I removed the symbol detection for bindings present in libvirt 0.9.1 Let me know what you think! Thanks, Dave

1 3

[libvirt] [PATCH 0/2] Add cpu-max to capabilities and implement checks
by Michal Novotny 17 Apr '13

17 Apr '13

Add cpu-max to capabilities XML output for newer QEMU and implement checks whether the number of vCPUs/maximum vCPUS doesn't exceed machine limit. For older versions of QEMU cpu-max field is not present so the cpu-max is set to 0 to disable checking and act the same as without this patch. Signed-off-by: Michal Novotny <minovotn(a)redhat.com> Michal Novotny (2): cpu-max: Implement cpu-max attribute into capabilities XML output qemu: Implement validation for max-cpu in XML docs/schemas/capability.rng | 5 +++++ src/conf/capabilities.c | 4 ++++ src/conf/capabilities.h | 1 + src/qemu/qemu_capabilities.c | 40 +++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_capabilities.h | 3 ++- src/qemu/qemu_driver.c | 30 ++++++++++++++++++++++++++++++ src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 7 +++++++ 8 files changed, 89 insertions(+), 2 deletions(-) -- 1.7.11.7

2 4

[libvirt] patch request
by Thierry Parmentelat 17 Apr '13

17 Apr '13

Just in case this is useful, I'd like to submit this change below that was not present at least in 1.0.4 http://git.onelab.eu/?p=libvirt.git;a=blob;f=virgetlasterror.patch;h=9109d5… I'd taken this hint here in the first place http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700077 -- Thierry

2 3

[libvirt] Google Summer of Code 2013 ideas wiki open
by Stefan Hajnoczi 16 Apr '13

16 Apr '13

I have created the Google Summer of Code 2013 wiki page where you can add project ideas: http://wiki.qemu.org/Google_Summer_of_Code_2013 Please add project ideas you are willing to mentor. If you have an idea but cannot mentor this year, feel free to add it but please try to find a mentor for it. If you want to be a mentor, please see http://wiki.qemu.org/Google_Summer_of_Code_2013#Information_for_mentors. Background on Google Summer of Code: Google Summer of Code is a scheme where Google funds university students to work on open source projects for 12 weeks during the summer. It has been held annually since 2005. GSoC is an opportunity for students to experience open source development. Organizations sometimes find long-term contributors, and either way it's a fun experience. Open source organizations can apply to take part. Those chosen will be able to take on one or more students for the summer. Each student is paired with a mentor who helps them and evaluates their progress. Last year QEMU was not accepted but we were successful in years before that. I believe Google will announce GSoC again this year (there is no guarantee though) and I have created the wiki page so we can begin organizing project ideas that students can choose from. This way we'll be ready to put together a good organization application. Stefan

6 54

[libvirt] [PATCH 0/6] cleanup: About including header
by Osier Yang 16 Apr '13

16 Apr '13

4 14

[libvirt] [PATCH 0/5] VirtualBox version 4.2 support for libvirt vbox driver
by ryan woodsmall 16 Apr '13

16 Apr '13

This patch set adds VirtualBox 4.2 initial support for the libvirt vbox driver. I've tested enough to check capabilities, create a VM, destroy it, etc. Five patches total: - Patch 1 is the C API header file from Oracle, cleaned up for libvirt. - Patch 2 is the version specific source file for version dependency. - Patch 3 is the src/Makefile.am change to pick up the two new files. - Patch 4 is the vbox driver support for the new VirtualBox API/version. - Patch 5 is the vbox_tmpl.c template support for the new version. A few things have changed in the VirtualBox API - some small (capitalizations of things in function names like Ip to IP and Dhcp to DHCP) and some much larger (FindMedium is superceded by OpenMedium). The biggest change for the sake of this patch set is the signature of CreateMachine is quite a bit different. Using the Oracle source as a guide, to spin up a VM with a given UUID, it looks like a text flag has to be passed in a new argument to CreateMachine. This flag is built in the VirtualBox 4.2 specific ifdefs and is kind of ugly but works. Additionally, there is now (unused) VM groups support in CreateMachine and the previous 'osTypeId' arg is currently set to nsnull as in the Oracle code. The FindMedium to OpenMedium changes were more straightforward and are pretty clear. The rest of the vbox template changes are basically spelling/capitalization changes from the looks of things. This probably isn't perfect, but it works on git and patched against 0.10.2 for a few quick tests. Not currently on the list, so ping me directly if you need any other info on these, or if anything could use additional work. Thanks! -r ryan woodsmall (5): vbox C API header for VirtualBox v4.2 vbox version-specific C file for VirtualBox v4.2 Makefile.am additions for VirtualBox v4.2 vbox driver support for VirtualBox v4.2 vbox template support for VirtualBox v4.2 src/Makefile.am | 3 +- src/vbox/vbox_CAPI_v4_2.h | 8855 +++++++++++++++++++++++++++++++++++++++++++++ src/vbox/vbox_V4_2.c | 13 + src/vbox/vbox_driver.c | 8 + src/vbox/vbox_tmpl.c | 90 +- 5 files changed, 8958 insertions(+), 11 deletions(-) create mode 100644 src/vbox/vbox_CAPI_v4_2.h create mode 100644 src/vbox/vbox_V4_2.c

4 9

[libvirt] [PATCH] Check for QMP query-tpm-models
by Stefan Berger 16 Apr '13

16 Apr '13

Check for QMP query-tpm-models and set a capability flag. Do not use this QMP command if it is not supported. Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- src/qemu/qemu_capabilities.c | 8 ++++++++ src/qemu/qemu_capabilities.h | 1 + 2 files changed, 9 insertions(+) Index: libvirt/src/qemu/qemu_capabilities.h =================================================================== --- libvirt.orig/src/qemu/qemu_capabilities.h +++ libvirt/src/qemu/qemu_capabilities.h @@ -179,6 +179,7 @@ enum virQEMUCapsFlags { QEMU_CAPS_MACHINE_USB_OPT = 137, /* -machine xxx,usb=on/off */ QEMU_CAPS_DEVICE_TPM_PASSTHROUGH = 138, /* -tpmdev passthrough */ QEMU_CAPS_DEVICE_TPM_TIS = 139, /* -device tpm_tis */ + QEMU_CAPS_TPM_MODELS = 140, /* query-tpm-models QMP command */ QEMU_CAPS_LAST, /* this must always be the last item */ }; Index: libvirt/src/qemu/qemu_capabilities.c =================================================================== --- libvirt.orig/src/qemu/qemu_capabilities.c +++ libvirt/src/qemu/qemu_capabilities.c @@ -220,6 +220,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAS "machine-usb-opt", "tpm-passthrough", "tpm-tis", + + "query-tpm-models", /* 140 */ ); struct _virQEMUCaps { @@ -1962,6 +1964,8 @@ virQEMUCapsProbeQMPCommands(virQEMUCapsP virQEMUCapsSet(qemuCaps, QEMU_CAPS_ADD_FD); else if (STREQ(name, "nbd-server-start")) virQEMUCapsSet(qemuCaps, QEMU_CAPS_NBD_SERVER); + else if (STREQ(name, "query-tpm-models")) + virQEMUCapsSet(qemuCaps, QEMU_CAPS_TPM_MODELS); VIR_FREE(name); } VIR_FREE(commands); @@ -2144,6 +2148,10 @@ virQEMUCapsProbeQMPTPM(virQEMUCapsPtr qe { int nentries, i; char **entries = NULL; + + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_TPM_MODELS)) + return 0; + if ((nentries = qemuMonitorGetTPMModels(mon, &entries)) < 0) return -1;

3 4

[libvirt] [PATCH v2] Fix compilation error in util/vircgroup.c
by Stefan Berger 16 Apr '13

16 Apr '13

Fix the error util/vircgroup.c: In function 'virCgroupNewDomainPartition': util/vircgroup.c:1299:11: error: declaration of 'dirname' shadows a global declaration [-Werror=shadow] Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- src/util/vircgroup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: libvirt-acl/src/util/vircgroup.c =================================================================== --- libvirt-acl.orig/src/util/vircgroup.c +++ libvirt-acl/src/util/vircgroup.c @@ -1296,13 +1296,13 @@ int virCgroupNewDomainPartition(virCgrou virCgroupPtr *group) { int rc; - char *dirname = NULL; + char *grpname = NULL; - if (virAsprintf(&dirname, "%s.%s.libvirt", + if (virAsprintf(&grpname, "%s.%s.libvirt", name, driver) < 0) return -ENOMEM; - rc = virCgroupNew(dirname, partition, -1, group); + rc = virCgroupNew(grpname, partition, -1, group); if (rc == 0) { /* @@ -1322,7 +1322,7 @@ int virCgroupNewDomainPartition(virCgrou } } - VIR_FREE(dirname); + VIR_FREE(grpname); return rc; } #else

2 2

[libvirt] [PATCH] Fix build breaker with ATTRIBUTE_NONNULL defs
by John Ferlan 16 Apr '13

16 Apr '13

Using "./autogen.sh --system lv_cv_static_analysis=yes" for my daily Coverity builds resulted in the following error when building: In file included from util/vircgrouppriv.h:32:0, from util/vircgroup.c:44: util/vircgroup.h:59:5: error: nonnull argument with out-of-range operand number (argument 1, operand 5) util/vircgroup.h:74:5: error: nonnull argument references non-pointer operand (argument 1, operand 4) make[3]: *** [libvirt_util_la-vircgroup.lo] Error 1 make[3]: Leaving directory `/home/jferlan/libvirt.cov.curr/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jferlan/libvirt.cov.curr/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jferlan/libvirt.cov.curr' make: *** [all] Error 2 --- src/util/vircgroup.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/vircgroup.h b/src/util/vircgroup.h index f324fa3..b030e4a 100644 --- a/src/util/vircgroup.h +++ b/src/util/vircgroup.h @@ -54,11 +54,11 @@ int virCgroupNewPartition(const char *path, int virCgroupNewDriver(const char *name, bool create, int controllers, virCgroupPtr *group) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(5); + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(4); int virCgroupNewSelf(virCgroupPtr *group) ATTRIBUTE_NONNULL(1); int virCgroupNewDomainDriver(virCgroupPtr driver, @@ -69,11 +69,11 @@ int virCgroupNewDomainDriver(virCgroupPtr driver, int virCgroupNewDomainPartition(virCgroupPtr partition, const char *driver, const char *name, bool create, virCgroupPtr *group) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(4); + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(5); int virCgroupNewVcpu(virCgroupPtr domain, int vcpuid, bool create, virCgroupPtr *group) -- 1.8.1.4

2 1

[libvirt] [PATCH] Resolve valgrind error
by John Ferlan 16 Apr '13

16 Apr '13

Commit id '1acfc171' resulted in the following valgrind failure: ==25317== 136 (24 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4 ==25317== at 0x4A06B6F: calloc (vg_replace_malloc.c:593) ==25317== by 0x4C6F851: virAlloc (viralloc.c:124) ==25317== by 0x4C71493: virBitmapNew (virbitmap.c:74) ==25317== by 0x4C71B79: virBitmapNewData (virbitmap.c:434) ==25317== by 0x402EF2: test8 (virbitmaptest.c:436) ==25317== by 0x40499F: virtTestRun (testutils.c:157) ==25317== by 0x402E8D: mymain (virbitmaptest.c:474) ==25317== by 0x404FDA: virtTestMain (testutils.c:719) ==25317== by 0x39D0821A04: (below main) (in /usr/lib64/libc-2.16.so) --- tests/virbitmaptest.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/tests/virbitmaptest.c b/tests/virbitmaptest.c index 90be0e2..2464c33 100644 --- a/tests/virbitmaptest.c +++ b/tests/virbitmaptest.c @@ -432,24 +432,25 @@ static int test8(const void *v ATTRIBUTE_UNUSED) { virBitmapPtr bitmap = NULL; char data[108] = {0x00,}; + int ret = -1; bitmap = virBitmapNewData(data, sizeof(data)); if (!bitmap) - goto error; + goto cleanup; if (!virBitmapIsAllClear(bitmap)) - goto error; + goto cleanup; if (virBitmapSetBit(bitmap, 11) < 0) - goto error; + goto cleanup; if (virBitmapIsAllClear(bitmap)) - goto error; + goto cleanup; - return 0; -error: + ret = 0; +cleanup: virBitmapFree(bitmap); - return -1; + return ret; } static int -- 1.8.1.4

2 2

[libvirt] [PATCH] Fix compilation error in util/vircgroup.c
by Stefan Berger 16 Apr '13

16 Apr '13

Fix the error util/vircgroup.c: In function 'virCgroupNewDomainPartition': util/vircgroup.c:1299:11: error: declaration of 'dirname' shadows a global declaration [-Werror=shadow] Signed-off-by: Stefan Berger <stefanb(a)linux.vnet.ibm.com> --- src/util/vircgroup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: libvirt-acl/src/util/vircgroup.c =================================================================== --- libvirt-acl.orig/src/util/vircgroup.c +++ libvirt-acl/src/util/vircgroup.c @@ -1296,13 +1296,13 @@ int virCgroupNewDomainPartition(virCgrou virCgroupPtr *group) { int rc; - char *dirname = NULL; + char *directoryname = NULL; - if (virAsprintf(&dirname, "%s.%s.libvirt", + if (virAsprintf(&directoryname, "%s.%s.libvirt", name, driver) < 0) return -ENOMEM; - rc = virCgroupNew(dirname, partition, -1, group); + rc = virCgroupNew(directoryname, partition, -1, group); if (rc == 0) { /* @@ -1322,7 +1322,7 @@ int virCgroupNewDomainPartition(virCgrou } } - VIR_FREE(dirname); + VIR_FREE(directoryname); return rc; } #else

2 1

[libvirt] [PATCH 0/2] Suppress log message when using unsupported TPM QMP commands
by Stefan Berger 16 Apr '13

16 Apr '13

Properly suppress log messages when using unsupported TPM QMP commands. Stefan

2 4

[libvirt] [libvirt-glib] Fix year in NEWS
by Christophe Fergeau 16 Apr '13

16 Apr '13

We switched from 2012 to 2013!! --- I've pushed this under the trivial rule. Christophe NEWS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index b5f0c84..b1f4a80 100644 --- a/NEWS +++ b/NEWS @@ -1,7 +1,7 @@ libvirt-glib News ================= -0.1.6 - Mar 18, 2012 +0.1.6 - Mar 18, 2013 ==================== - Prefer g_strlcpy over strncpy @@ -14,7 +14,7 @@ - Replace FSF address with URL in copyright headers - Add API for changing Spice compression parameters. -0.1.5 - Jan 14, 2012 +0.1.5 - Jan 14, 2013 ==================== - Add support for bridge interface types in guest XML -- 1.8.1.4

1 0

[libvirt] [PATCH 0/7] Add support for guest-based CPU-hotplug and unplug
by Peter Krempa 16 Apr '13

16 Apr '13

This is a initial support for guest-agent based cpu hotplug that was commited in upstream qemu and should be released in qemu 1.5.0. This patchset relies on the existing qemuDomainSetVcpusFlags API that is not really ideal for this purpose but is usable. I'm planing on adding a specific-cpu hotplug API later that will allow more control. Peter Krempa (7): lib: Fix docs about return value of virDomainGetVcpusFlags() virsh-domain: Refactor cmdVcpucount and fix output on inactive domains qemu_agent: Add support for appending arrays to commands qemu_agent: Introduce helpers for agent based CPU hot(un)plug Introduce flag VIR_DOMAIN_VCPU agent, for agent based CPU unlpug(shutdown). qemu: Implement request of vCPU state using the guest agent qemu: Implement support for VIR_DOMAIN_VCPU in qemuDomainSetVcpusFlags include/libvirt/libvirt.h.in | 1 + src/libvirt.c | 9 +- src/qemu/qemu_agent.c | 141 +++++++++++++++++++++ src/qemu/qemu_agent.h | 12 ++ src/qemu/qemu_driver.c | 181 ++++++++++++++++++++++++--- tools/virsh-domain.c | 283 +++++++++++++++++++++---------------------- tools/virsh.pod | 13 +- 7 files changed, 474 insertions(+), 166 deletions(-) -- 1.8.1.5

2 15

[libvirt] [PATCH v4 00/11] Add support for guests with TPM passthrough device
by Stefan Berger 16 Apr '13

16 Apr '13

Hello! The following set of patches adds support to libvirt for adding a TPM passthrough device to a QEMU guest. Support for this was recently accepted into QEMU. This set of patches borrows a lot from the recently added support for rng's. Regards, Stefan --- v3->v4: - followed tree to ce65b435 - followed comments on v3 v2->v3: - followed tree to 03122d7b - some nits I found fixed v1->v2: - Followed Daniel Berrange's comments (except for the one on de-consolidating the JSON monitor code)

2 28

[libvirt] [PATCH 1/2] qemu: Support discard for disk
by Osier Yang 16 Apr '13

16 Apr '13

QEMU introduced "discard" option for drive since commit a9384aff53, <...> @var{discard} is one of "ignore" (or "off") or "unmap" (or "on") and controls whether @dfn{discard} (also known as @dfn{trim} or @dfn{unmap}) requests are ignored or passed to the filesystem. Some machine types may not support discard requests. </...> This patch exposes the support in libvirt. --- docs/formatdomain.html.in | 8 +++++ docs/schemas/domaincommon.rng | 11 +++++++ src/conf/domain_conf.c | 18 +++++++++++ src/conf/domain_conf.h | 10 ++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 11 +++++++ .../qemuxml2argv-disk-discard.args | 8 +++++ .../qemuxml2argvdata/qemuxml2argv-disk-discard.xml | 36 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 3 ++ tests/qemuxml2xmltest.c | 2 ++ 12 files changed, 112 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-discard.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-discard.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 0cc56d9..f1cee14 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1676,6 +1676,14 @@ network. By default copy-on-read is off. <span class='since'>Since 0.9.10 (QEMU and KVM only)</span> </li> + <li> + The optional <code>discard</code> attribute controls whether + to discard (also known as "trim" or "unmap") requests are + ignored or passed to the filesystem. The value can be either + "on" (allow the discard request to be passed) or "off" (ingore + the discard request). + <span class='since'>Since 1.0.5 (QEMU and KVM only)</span> + </li> </ul> </dd> <dt><code>boot</code></dt> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 468c49c..4b71e16 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -1304,6 +1304,9 @@ <optional> <ref name="copy_on_read"/> </optional> + <optional> + <ref name="discard"/> + </optional> <empty/> </element> </define> @@ -1399,6 +1402,14 @@ <value>off</value> </choice> </attribute> + </define> + <define name="discard"> + <attribute name='discard'> + <choice> + <value>on</value> + <value>off</value> + </choice> + </attribute> </define> <define name="controller"> <element name="controller"> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 548368e..4925a80 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -728,6 +728,10 @@ VIR_ENUM_IMPL(virDomainTPMModel, VIR_DOMAIN_TPM_MODEL_LAST, VIR_ENUM_IMPL(virDomainTPMBackend, VIR_DOMAIN_TPM_TYPE_LAST, "passthrough") +VIR_ENUM_IMPL(virDomainDiskDiscard, VIR_DOMAIN_DISK_DISCARD_LAST, + "default", + "on", + "off") #define VIR_DOMAIN_XML_WRITE_FLAGS VIR_DOMAIN_XML_SECURE #define VIR_DOMAIN_XML_READ_FLAGS VIR_DOMAIN_XML_INACTIVE @@ -4324,6 +4328,7 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt, char *wwn = NULL; char *vendor = NULL; char *product = NULL; + char *discard = NULL; int expected_secret_usage = -1; int auth_secret_usage = -1; @@ -4551,6 +4556,7 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt, ioeventfd = virXMLPropString(cur, "ioeventfd"); event_idx = virXMLPropString(cur, "event_idx"); copy_on_read = virXMLPropString(cur, "copy_on_read"); + discard = virXMLPropString(cur, "discard"); } else if (!mirror && xmlStrEqual(cur->name, BAD_CAST "mirror") && !(flags & VIR_DOMAIN_XML_INACTIVE)) { char *ready; @@ -4997,6 +5003,14 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt, def->copy_on_read = cor; } + if (discard) { + if ((def->discard = virDomainDiskDiscardTypeFromString(discard)) <= 0) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unknown disk discard mode '%s'"), discard); + goto error; + } + } + if (devaddr) { if (virDomainParseLegacyDeviceAddress(devaddr, &def->info.addr.pci) < 0) { @@ -5116,6 +5130,7 @@ cleanup: VIR_FREE(ioeventfd); VIR_FREE(event_idx); VIR_FREE(copy_on_read); + VIR_FREE(discard); VIR_FREE(devaddr); VIR_FREE(serial); virStorageEncryptionFree(encryption); @@ -13291,6 +13306,7 @@ virDomainDiskDefFormat(virBufferPtr buf, const char *event_idx = virDomainVirtioEventIdxTypeToString(def->event_idx); const char *copy_on_read = virDomainVirtioEventIdxTypeToString(def->copy_on_read); const char *sgio = virDomainDiskSGIOTypeToString(def->sgio); + const char *discard = virDomainDiskDiscardTypeToString(def->discard); char uuidstr[VIR_UUID_STRING_BUFLEN]; @@ -13367,6 +13383,8 @@ virDomainDiskDefFormat(virBufferPtr buf, virBufferAsprintf(buf, " event_idx='%s'", event_idx); if (def->copy_on_read) virBufferAsprintf(buf, " copy_on_read='%s'", copy_on_read); + if (def->discard) + virBufferAsprintf(buf, " discard='%s'", discard); virBufferAddLit(buf, "/>\n"); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index f1f01fa..fdf5d93 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -600,6 +600,14 @@ enum virDomainDiskSGIO { VIR_DOMAIN_DISK_SGIO_LAST }; +enum virDomainDiskDiscard { + VIR_DOMAIN_DISK_DISCARD_DEFAULT = 0, + VIR_DOMAIN_DISK_DISCARD_ON, + VIR_DOMAIN_DISK_DISCARD_OFF, + + VIR_DOMAIN_DISK_DISCARD_LAST +}; + typedef struct _virDomainBlockIoTuneInfo virDomainBlockIoTuneInfo; struct _virDomainBlockIoTuneInfo { unsigned long long total_bytes_sec; @@ -682,6 +690,7 @@ struct _virDomainDiskDef { bool rawio_specified; int rawio; /* no = 0, yes = 1 */ int sgio; /* enum virDomainDiskSGIO */ + int discard; /* enum virDomainDiskDiscard */ size_t nseclabels; virSecurityDeviceLabelDefPtr *seclabels; @@ -2416,6 +2425,7 @@ VIR_ENUM_DECL(virDomainDiskIo) VIR_ENUM_DECL(virDomainDiskSecretType) VIR_ENUM_DECL(virDomainDiskSGIO) VIR_ENUM_DECL(virDomainDiskTray) +VIR_ENUM_DECL(virDomainDiskDiscard) VIR_ENUM_DECL(virDomainIoEventFd) VIR_ENUM_DECL(virDomainVirtioEventIdx) VIR_ENUM_DECL(virDomainDiskCopyOnRead) diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 30fdcd7..a24bf5c 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -140,6 +140,7 @@ virDomainDiskDefFree; virDomainDiskDefGenSecurityLabelDef; virDomainDiskDefGetSecurityLabelDef; virDomainDiskDeviceTypeToString; +virDomainDiskDiscardTypeToString; virDomainDiskErrorPolicyTypeFromString; virDomainDiskErrorPolicyTypeToString; virDomainDiskFindByBusAndDst; diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index b174672..278012c 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -222,6 +222,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "tpm-tis", "query-tpm-models", /* 140 */ + "drive-discard", ); struct _virQEMUCaps { @@ -963,6 +964,8 @@ virQEMUCapsComputeCmdFlags(const char *help, virQEMUCapsSet(qemuCaps, QEMU_CAPS_DRIVE_COPY_ON_READ); if (strstr(help, "bps=")) virQEMUCapsSet(qemuCaps, QEMU_CAPS_DRIVE_IOTUNE); + if (strstr(help, "discard")) + virQEMUCapsSet(qemuCaps, QEMU_CAPS_DRIVE_DISCARD); } if ((p = strstr(help, "-vga")) && !strstr(help, "-std-vga")) { const char *nl = strstr(p, "\n"); diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index 7a0f191..17c5335 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -180,6 +180,7 @@ enum virQEMUCapsFlags { QEMU_CAPS_DEVICE_TPM_PASSTHROUGH = 138, /* -tpmdev passthrough */ QEMU_CAPS_DEVICE_TPM_TIS = 139, /* -device tpm_tis */ QEMU_CAPS_TPM_MODELS = 140, /* query-tpm-models QMP command */ + QEMU_CAPS_DRIVE_DISCARD = 141, /* -drive discard=off(ignore)|on(unmap) */ QEMU_CAPS_LAST, /* this must always be the last item */ }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 63b9350..36f20eb 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2987,6 +2987,17 @@ qemuBuildDriveStr(virConnectPtr conn ATTRIBUTE_UNUSED, } } + if (disk->discard) { + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_DISCARD)) { + virBufferAsprintf(&opt, ",discard=%s", + virDomainDiskDiscardTypeToString(disk->discard)); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("discard is not supported by this QEMU binary")); + goto error; + } + } + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_MONITOR_JSON)) { const char *wpolicy = NULL, *rpolicy = NULL; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.args new file mode 100644 index 0000000..02e2ddb --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.args @@ -0,0 +1,8 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test \ +/usr/bin/qemu -S -M pc-0.13 -m 1024 -smp 1 -nographic -nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot dc -usb \ +-drive file=/var/lib/libvirt/images/f14.img,if=none,id=drive-virtio-disk0,discard=on \ +-device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 \ +-drive file=/var/lib/libvirt/Fedora-14-x86_64-Live-KDE.iso,if=none,media=cdrom,id=drive-ide0-1-0,discard=off \ +-device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.xml new file mode 100644 index 0000000..fa38a2d --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-discard.xml @@ -0,0 +1,36 @@ +<domain type='qemu'> + <name>test</name> + <uuid>92d7a226-cfae-425b-a6d3-00bbf9ec5c9e</uuid> + <memory unit='KiB'>1048576</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc-0.13'>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + <bootmenu enable='yes'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>restart</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' discard='on'/> + <source file='/var/lib/libvirt/images/f14.img'/> + <target dev='vda' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw' discard='off'/> + <source file='/var/lib/libvirt/Fedora-14-x86_64-Live-KDE.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index be6c759..e09e070 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -575,6 +575,9 @@ mymain(void) QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_COPY_ON_READ, QEMU_CAPS_VIRTIO_TX_ALG, QEMU_CAPS_DEVICE, QEMU_CAPS_VIRTIO_BLK_SCSI, QEMU_CAPS_VIRTIO_BLK_SG_IO); + DO_TEST("disk-discard", + QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_DISCARD, + QEMU_CAPS_DEVICE); DO_TEST("disk-snapshot", QEMU_CAPS_DRIVE, QEMU_CAPS_DRIVE_CACHE_V2, QEMU_CAPS_DRIVE_FORMAT); DO_TEST("event_idx", diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index 3a1683f..7f32661 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -255,6 +255,8 @@ mymain(void) DO_TEST("disk-scsi-disk-vpd"); DO_TEST("disk-source-pool"); + DO_TEST("disk-discard"); + DO_TEST("virtio-rng-random"); DO_TEST("virtio-rng-egd"); -- 1.8.1.4

1 1

[libvirt] [Concern] Whether some clock element stability need to be check before migration?
by Xuesong Zhang 16 Apr '13

16 Apr '13

hi, This is xuesong from libvirt-QE, which is the feature owner of stable guest ABI in rhel7. I met one issue, but didn't know whether it is one bug or not, since in Guest ABI , some aspects belong to "a host-side configuration parameter". So, would you please kindly help to check it? Thanks. Description While check the guest clock ABI stability, some scenario fails. version kernel-3.8.0-0.43.el7.x86_64 qemu-kvm-1.3.0-6.el7.x86_64 libvirt-1.0.3-1.el7.x86_64 reproduced 100% Steps 1. prepare migration env on two hosts. 2. prepare one guest with the parallel. ...... <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120' limit='10000'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> .... 3. start and dumpxml this gust # virsh start mig Domain mig started # virsh dumpxml mig > mig.xml 4. Change "localtime" to "utc" in the generated xml "mig.xml". ...... <clock offset='utc'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120' limit='10000'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> .... 5. migration with the modified xml is successfully.------------------it is issue, should prompt error message. # virsh migrate --live --xml mig.xml mig qemu+ssh://{$target host IP}/system 6. run step3 again, then change timer name "pit" to "platform". Note, maker sure only one change point in the xml. then migration with the modified xml. ----------------this result is as expect # virsh migrate mig --live --xml mig.xml qemu+ssh://10.66.83.38/system error: unsupported configuration: Target timer platform does not match source pit 7. run step3 again, then delete timer name "pit". Note, maker sure only one change point in the xml. then migration with the modified xml.-----------------the result is as expect #virsh migrate mig --live --xml mig.xml qemu+ssh://10.66.83.38/system error: unsupported configuration: Target domain timers do not match source 8. run step3 again, then change timer track from "guest" to "wall". Note, maker sure only one change point in the xml. then migration with the modified xml. The migration is succssful.------------------------------------------------------------------------------------------------------------------it is issue, should prompt error message. # virsh migrate --live --xml mig.xml mig qemu+ssh://{$target host IP}/system 9. run step3 again, then change timer tickpolicy from "catchup" to "delay". Note, maker sure only one change point in the xml. then migration with the modified xml. The migration is succssful.------------------------------------------------------------------------------------------------------------------it is issue, should prompt error message. # virsh migrate --live --xml mig.xml mig qemu+ssh://{$target host IP}/system Actual result The result in step 6 and 7 is as expected, the result of step 5, 8 and 9 is wrong. Expect result The clock element stability in step 5, 8 and 9 need to be check before migration. Addtional info: Below is all checks about clock in upstream 1.0.4 maint branch: In timer check Function virDomainTimerDefCheckABIStability only check 1.NAME :src->name != dst->name 2.PRESENT :src->present != dst->present) 3.FREQUENCY :src->name == VIR_DOMAIN_TIMER_NAME_TSC) { if (src->frequency != dst->frequency) } 4.MODE src->mode != dst->mode And in another function , check timer's numbers 5.NUMBERS : src->clock.ntimers != dst->clock.ntimers Best Regards, Zhang Xuesong IRC: xuzhang internal phone: 88393

1 0

[libvirt] [PATCH 0/2] Check domain status before virsh suspend or resume
by John Ferlan 16 Apr '13

16 Apr '13

https://bugzilla.redhat.com/show_bug.cgi?id=906644 Added checks to both virsh suspend and virsh resume for the domain to be in a the right state before trying the suspend/resume. Similar checks to examples/domsuspend/suspend.c. Although not stated in case, any thoughts on adding a --force for both? John Ferlan (2): virsh: Add check for domain state before attempting resume virsh: Add check for domain state before attempting suspend tools/virsh-domain.c | 40 +++++++++++++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 9 deletions(-) -- 1.8.1.4

3 5