- Devel - libvirt List Archives

[libvirt] [PATCH v5 03/14] audio: -audiodev command line option: documentation
by Kővágó, Zoltán 22 Feb '19

22 Feb '19

This patch adds documentation of an -audiodev command line option, that deprecates the old QEMU_* environment variables for audio backend configuration. It's syntax is similar to existing options (-netdev, -device, etc): -audiodev driver_name,property=value,... Although now it's possible to specify multiple -audiodev options on command line, multiple audio backends are not supported yet. Signed-off-by: Kővágó, Zoltán <DirtY.iCE.hu(a)gmail.com> --- Notes: Changes from v4: * deprecated QEMU_AUDIO_ env vars * updated to reflect qapi changes * added info to qemu-deprecated.texi qemu-deprecated.texi | 7 ++ qemu-options.hx | 236 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 240 insertions(+), 3 deletions(-) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 45c57952da..5c07ad4acb 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -60,6 +60,13 @@ Support for invalid topologies will be removed, the user must ensure topologies described with -smp include all possible cpus, i.e. @math{@var{sockets} * @var{cores} * @var{threads} = @var{maxcpus}}. +@subsection QEMU_AUDIO_ environment variables and -audio-help (since 4.0) + +The ``-audiodev'' argument is now the preferred way to specify audio +backend settings instead of environment variables. To ease migration to +the new format, the ``-audiodev-help'' option can be used to convert +the current values of the environment variables to ``-audiodev'' options. + @section QEMU Machine Protocol (QMP) commands @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0) diff --git a/qemu-options.hx b/qemu-options.hx index 77bd98e20b..f77f4d89a7 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -416,14 +416,244 @@ The default is @code{en-us}. ETEXI +HXCOMM Deprecated by -audiodev DEF("audio-help", 0, QEMU_OPTION_audio_help, - "-audio-help print list of audio drivers and their options\n", + "-audio-help show -audiodev equivalent of the currently specified audio settings\n", QEMU_ARCH_ALL) STEXI @item -audio-help @findex -audio-help -Will show the audio subsystem help: list of drivers, tunable -parameters. +Will show the -audiodev equivalent of the currently specified +(deprecated) environment variables. +ETEXI + +DEF("audiodev", HAS_ARG, QEMU_OPTION_audiodev, + "-audiodev [driver=]driver,id=id[,prop[=value][,...]]\n" + " specifies the audio backend to use\n" + " id= identifier of the backend\n" + " timer-period= timer period in microseconds\n" + " in|out.fixed-settings= use fixed settings for host audio\n" + " in|out.frequency= frequency to use with fixed settings\n" + " in|out.channels= number of channels to use with fixed settings\n" + " in|out.format= sample format to use with fixed settings\n" + " valid values: s8, s16, s32, u8, u16, u32\n" + " in|out.voices= number of voices to use\n" + " in|out.buffer-len= length of buffer in microseconds\n" + "-audiodev none,id=id,[,prop[=value][,...]]\n" + " dummy driver that discards all output\n" +#ifdef CONFIG_ALSA + "-audiodev alsa,id=id[,prop[=value][,...]]\n" + " in|out.dev= name of the audio device to use\n" + " in|out.period-len= length of period in microseconds\n" + " in|out.try-poll= attempt to use poll mode\n" + " threshold= threshold (in microseconds) when playback starts\n" +#endif +#ifdef CONFIG_COREAUDIO + "-audiodev coreaudio,id=id[,prop[=value][,...]]\n" + " in|out.buffer-count= number of buffers\n" +#endif +#ifdef CONFIG_DSOUND + "-audiodev dsound,id=id[,prop[=value][,...]]\n" + " latency= add extra latency to playback in microseconds\n" +#endif +#ifdef CONFIG_OSS + "-audiodev oss,id=id[,prop[=value][,...]]\n" + " in|out.dev= path of the audio device to use\n" + " in|out.buffer-count= number of buffers\n" + " in|out.try-poll= attempt to use poll mode\n" + " try-mmap= try using memory mapped access\n" + " exclusive= open device in exclusive mode\n" + " dsp-policy= set timing policy (0..10), -1 to use fragment mode\n" +#endif +#ifdef CONFIG_PA + "-audiodev pa,id=id[,prop[=value][,...]]\n" + " server= PulseAudio server address\n" + " in|out.name= source/sink device name\n" +#endif +#ifdef CONFIG_SDL + "-audiodev sdl,id=id[,prop[=value][,...]]\n" +#endif +#ifdef CONFIG_SPICE + "-audiodev spice,id=id[,prop[=value][,...]]\n" +#endif + "-audiodev wav,id=id[,prop[=value][,...]]\n" + " path= path of wav file to record\n", + QEMU_ARCH_ALL) +STEXI +@item -audiodev [driver=]@var{driver},id=@var{id}[,@var{prop}[=@var{value}][,...]] +@findex -audiodev +Adds a new audio backend @var{driver} identified by @var{id}. There are +global and driver specific properties. Some values can be set +differently for input and output, they're marked with @code{in|out.}. +You can set the input's property with @code{in.@var{prop}} and the +output's property with @code{out.@var{prop}}. For example: +@example +-audiodev alsa,id=example,in.frequency=44110,out.frequency=8000 +-audiodev alsa,id=example,out.channels=1 # leaves in.channels unspecified +@end example + +Valid global options are: + +@table @option +@item id=@var{identifier} +Identifies the audio backend. + +@item timer-period=@var{period} +Sets the timer @var{period} used by the audio subsystem in microseconds. +Default is 10000 (10 ms). + +@item in|out.fixed-settings=on|off +Use fixed settings for host audio. When off, it will change based on +how the guest opens the sound card. In this case you must not specify +@var{frequency}, @var{channels} or @var{format}. Default is on. + +@item in|out.frequency=@var{frequency} +Specify the @var{frequency} to use when using @var{fixed-settings}. +Default is 44100Hz. + +@item in|out.channels=@var{channels} +Specify the number of @var{channels} to use when using +@var{fixed-settings}. Default is 2 (stereo). + +@item in|out.format=@var{format} +Specify the sample @var{format} to use when using @var{fixed-settings}. +Valid values are: @code{s8}, @code{s16}, @code{s32}, @code{u8}, +@code{u16}, @code{u32}. Default is @code{s16}. + +@item in|out.voices=@var{voices} +Specify the number of @var{voices} to use. Default is 1. + +@item in|out.buffer=@var{usecs} +Sets the size of the buffer in microseconds. + +@end table + +@item -audiodev none,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a dummy backend that discards all outputs. This backend has no +backend specific properties. + +@item -audiodev alsa,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates backend using the ALSA. This backend is only available on +Linux. + +ALSA specific options are: + +@table @option + +@item in|out.dev=@var{device} +Specify the ALSA @var{device} to use for input and/or output. Default +is @code{default}. + +@item in|out.period-len=@var{usecs} +Sets the period length in microseconds. + +@item in|out.try-poll=on|off +Attempt to use poll mode with the device. Default is on. + +@item threshold=@var{threshold} +Threshold (in microseconds) when playback starts. Default is 0. + +@end table + +@item -audiodev coreaudio,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using Apple's Core Audio. This backend is only +available on Mac OS and only supports playback. + +Core Audio specific options are: + +@table @option + +@item in|out.buffer-count=@var{count} +Sets the @var{count} of the buffers. + +@end table + +@item -audiodev dsound,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using Microsoft's DirectSound. This backend is only +available on Windows and only supports playback. + +DirectSound specific options are: + +@table @option + +@item latency=@var{usecs} +Add extra @var{usecs} microseconds latency to playback. Default is +10000 (10 ms). + +@end table + +@item -audiodev oss,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using OSS. This backend is available on most +Unix-like systems. + +OSS specific options are: + +@table @option + +@item in|out.dev=@var{device} +Specify the file name of the OSS @var{device} to use. Default is +@code{/dev/dsp}. + +@item in|out.buffer-count=@var{count} +Sets the @var{count} of the buffers. + +@item in|out.try-poll=on|of +Attempt to use poll mode with the device. Default is on. + +@item try-mmap=on|off +Try using memory mapped device access. Default is off. + +@item exclusive=on|off +Open the device in exclusive mode (vmix won't work in this case). +Default is off. + +@item dsp-policy=@var{policy} +Sets the timing policy (between 0 and 10, where smaller number means +smaller latency but higher CPU usage). Use -1 to use buffer sizes +specified by @code{buffer} and @code{buffer-count}. This option is +ignored if you do not have OSS 4. Default is 5. + +@end table + +@item -audiodev pa,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using PulseAudio. This backend is available on most +systems. + +PulseAudio specific options are: + +@table @option + +@item server=@var{server} +Sets the PulseAudio @var{server} to connect to. + +@item in|out.name=@var{sink} +Use the specified source/sink for recording/playback. + +@end table + +@item -audiodev sdl,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend using SDL. This backend is available on most systems, +but you should use your platform's native backend if possible. This +backend has no backend specific properties. + +@item -audiodev spice,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend that sends audio through SPICE. This backend requires +@code{-spice} and automatically selected in that case, so usually you +can ignore this option. This backend has no backend specific +properties. + +@item -audiodev wav,id=@var{id}[,@var{prop}[=@var{value}][,...]] +Creates a backend that writes audio to a WAV file. + +Backend specific options are: + +@table @option + +@item path=@var{path} +Write recorded audio into the specified file. Default is +(a)code{qemu.wav}. + +@end table ETEXI DEF("soundhw", HAS_ARG, QEMU_OPTION_soundhw, -- 2.20.1

4 4

[libvirt] QEMU Acceleration with Hypervisor.framework
by Clement BLAISE 22 Feb '19

22 Feb '19

Hello, I’m interested in using hvf also know as Hypervisor. framework acceleration with QEMU which has been supported since 2.12. I’ve gone through the documentation and the code base, I was unable to find an element that could enable it in libvirt. I have come across a patch (link <https://www.spinics.net/linux/fedora/libvir/msg175338.html>) which target this particular feature, but I could not find it in the repo so I guess it has not been applied. Is something that will be supported in the future?

2 1

[libvirt] Configuring pflash devices for OVMF firmware
by Markus Armbruster 22 Feb '19

22 Feb '19

We configure OVMF firmware for PC machine types with -drive if=pflash. This is pretty much the last remaining use of -drive in libvirt we can't yet replace by -blockdev. Such a replacement is desirable, because -blockdev + -device is more flexible than -drive if=pflash. Also, once we don't need -drive with new QEMU anymore, the path for deleting all -drive code in libvirt some day is open. As with all desirables, the benefit needs to exceed the cost. I'm going to describe the status quo, how we got there (briefly and much simplified), then sketch how to replace -drive if=pflash. I'm afraid this is fairly long; sorry. Please correct misunderstandings. Beware, my libvirt and OVMF fu is much weaker than my QEMU fu. In the beginning, board code read the BIOS from a fixed file and mapped it into the guest's address space. Life was simple. On physical hardware, the BIOS can persist a bit of state across (cold) reboots by storing it in (non-volatile) CMOS RAM. We didn't bother. Simple. Fast forward several years, and The Law of OS Envy (every program wants to grow into a full-blown operating system) has asserted itself: PC Firmware has grown from an 8KiB ROM using a few bytes of volatile and non-volatile RAM into a multi-megabyte beast with much more complex storage needs. On today's physical PC hardware, firmware is stored in flash memory. There's code, and there's persistent data. For obvious reasons, the code should be write-protected except when doing an upgrade. "Secure boot" additionally needs to restrict data writes to system management mode (SMM). Here's our first iteration of OVMF support, at QEMU level: -drive if=pflash,format=raw,file=/where/ever/OVMF.fd Generic code creates a block backend for it. Magic board code picks up the backend, creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space. At libvirt level: <loader type="pflash">/where/ever/OVMF.fd</loader> Problem: while the flash device model provides read-only capability, it's all-or-nothing. You can't tell it to write-protect just the part holding code. The examples above don't write-protect anything. /where/ever/OVMF.fd better be writable exclusively. The flash device model could be enhanced, but we went down a different path: we split the single OVMF image OVMF.fd ("unified build") into a code image OVMF_CODE.fd and a data image OVMF_VARS.fd ("split build"). At QEMU level: -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/where/ever/OVMF_VARS.fd OVMF_CODE.fd must be unit 0, and OVMF_VARS.fd must be unit 1. Generic code creates two block backends. Magic board code picks them up, creates a frontend (a cfi.pflash01 device) for each, and maps them into the guest's address space. Note there are *two* virtual flash devices now, whereas physical hardware commonly has just one. At libvirt level: <loader type="pflash" readonly="yes">/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram template="/usr/share/OVMF/OVMF_VARS.fd">/var/libvirt/nvram/${guest}_VARS.fd</nvram> This treats OVMF_VARS.fd as a read-only template, and gives each guest its own writable copy, which is nice. The flash device model supports restricting writes to SMM (remember, that's required for secure boot). It's controlled by cfi.pflash01 property secure, off by default. If we created the device model with -device, we'd simply pass secure=on. But since we create it with -drive if=pflash, we can't. Instead we have to use -global driver=cfi.pflash01,property=secure,value=on This flips the global default value. Awkward, but works out okay, because (1) the flash device holding OVMF_VARS.fd wants this value, and (2) the flash device holding OVMF_CODE.fd doesn't care (it's read-only), and (3) there is no way to create additional flash devices. At the libvirt level, we add secure='yes' to the loader element. We also have to enable SMM emulation. At QEMU level: -machine smm=on At libvirt level: <features> <smm state='on'/> </features> Note that the above configuration examples involve selecting OVMF images. A bit of an inconvenience compared to BIOS, where the default "use the BIOS shipped with QEMU" pretty much just works. To add annoyance to inconvenience, different distributions have different ideas on where to install OVMF images. And because that's not complicated enough, we also have to pair code with data images. And because that's still not complicated enough, any specific machine type may work only with a subset of the available firmwares. The proposed way to deal with all that works as follows. Each set of firmware images comes with a descriptor file. These are JSON and conform to the QAPI schema docs/interop/firmware.json. Among the descriptors that declare support for the kind of machine we want, we pick (really: the management application picks) the one with the highest priority. The distribution provides default priorities, which system administrator and user can override. firmware.json documents this in much more detail. I wrote "proposed", because as far as I can tell, neither distributions nor libvirt are there, yet. After all this text, I'm finally ready to curve towards -blockdev. Going from -drive if=T, T!=none to -blockdev involves two steps. The first step replaces if=T with if=none and -device. The second step replaces -drive if=none with -blockdev. That step is "obvious" (it took us a few years to get to obvious, but I digress). The difficulty is in the first step. Two issues: (1) cfi.pflash01 isn't available with -device. (2) "Magic board code picks up the backend [created for -drive if=pflash], creates a frontend (a cfi.pflash01 device), and maps it into the guest's address space." When we replace if=pflash by if=none, we get to replicate that magic on top of -device. Issue (1) isn't too hard: we add the device to the dynamic sysbus device white-list, move a sysbus_mmio_map() from pflash_cfi01_realize() into pflash_cfi01_realize(). The latter requires a new device property to configure the base address. I got a working prototype. Since this makes the device model's name and properties ABI, review would be advisable. To solve (2), we first have to understand the magic. Device cfi.pflash01 has the following properties: num-blocks Size of the device in blocks sector-length Size of a block (admire the choice of names) width Bank width big-endian Endianess (d'oh) id0, id1, id2, id3 Some kind of device ID, guest-visible, default to zero, few boards change it name Memory region name (why is this even configurable?) phys-addr Physical base address (this is the new device property mentioned above) secure For restricting access to firmware, default off device-width you don't want to know, there is a default, but it's documented as "bad, do not use", yet pretty much all boards use it max-device-width defaults to device-width not actually set anywhere old-multiple-chip-handling back-compat gunk for machine types 2.8 and older The magic board code in hw/i386/pc_sysfw.c configures as follows: num-blocks computed from backend size sector-length 4096 width 1 big-endian 0 id0, id1, id2, id3 all 0 name system.pflash<U>, where U is -drive's unit number phys-addr computed so unit 0 ends right below 0x100000000, unit n+1 ends at right below unit n "secure", "device-width", "max-device-width", "old-multiple-chip-handling" are left at the default. One additional bit of magic is actually in libvirt: it configures "secure" by flipping its default with -global driver=cfi.pflash01,property=secure,value=on. Now let's consider how to replicate this magic on top of device. Perhaps machine-type specific defaults could take care of sector-length, width, big-endian, id0, id1, id2, id3. Leaves num-blocks, name, and phys-addr. Perhaps the realize() method could default num-blocks to size of backend. But that doesn't really help the management application, because it needs to mess with the size anyway to compute phys-addr. So scratch that idea. Moving the magic code to compute num-blocks, phys-addr and name to the management application is certainly possible, but ugly. Note that the values computed are fixed when the firmware gets deployed. If we record them in the firmware descriptor, the management application doesn't need magic, it can simply pass on the values obtained from the descriptor. We'd want to include sector-length in the descriptor then, to ensure num-block has a defined meaning. Same technique could take care of width, big-endian, ... in case machine-type specific defaults turn out to be inadequate for them. Opinions? One more problem: the magic board code does a bit more than just configure the cfi.pflash01 device. That additional magic needs to be generalized to work regardless of whether the device gets configured with -drive if=pflash or with -device. I got a working prototype.

7 44

[libvirt] Plans for next release
by Daniel Veillard 22 Feb '19

22 Feb '19

So it's getting time to think about 5.1.0, I'm thinking about entering freeze on Monday next week, push rc2 Wed and if everything goes well we can have the release out on Friday 1st, I hope that works for everyone, Daniel P.S. I will be on west coast so freeze and pushes likely to be later in the day than usual. -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH 0/1] update copyright notice
by David Kiarie 22 Feb '19

22 Feb '19

this updates the patch to use a full legal name on the copyright notice. David Kiarie (1): src/xenconfig: update copyright notice src/xenconfig/xen_xl.c | 1 + src/xenconfig/xen_xl.h | 1 + tests/xlconfigtest.c | 1 + 3 files changed, 3 insertions(+) -- 2.20.1

2 2

[libvirt] [PATCH 0/1] update copyright notice
by David Kiarie 22 Feb '19

22 Feb '19

these patche follows up a very co-operative review on a preview patch or lack of thereof. i have updated this to reflect the exact name i use in person. David Kiarie (1): src/xenconfig: update copyright notice src/xenconfig/xen_xl.c | 1 + src/xenconfig/xen_xl.h | 1 + tests/xlconfigtest.c | 1 + 3 files changed, 3 insertions(+) -- 2.20.1

2 3

[libvirt] [PATCH] qemu: fix memory leak in qemuBuildDiskDeviceStr
by Ján Tomko 22 Feb '19

22 Feb '19

Commit a1dce962 added the allocated scsiVPDDeviceId without freeing it. Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index f511193fca..74f34af292 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1890,7 +1890,7 @@ qemuBuildDiskDeviceStr(const virDomainDef *def, const char *bus = virDomainDiskQEMUBusTypeToString(disk->bus); const char *contAlias; char *backendAlias = NULL; - char *scsiVPDDeviceId = NULL; + VIR_AUTOFREE(char *) scsiVPDDeviceId = NULL; int controllerModel; if (qemuCheckDiskConfig(disk, qemuCaps) < 0) -- 2.19.2

2 1

[libvirt] [PATCH 0/7] Introduce automatic clearing for virBuffer
by Peter Krempa 22 Feb '19

22 Feb '19

First 4 patches clean up existing mess. Note that this series both fixes and then deletes virBufferEscapeN. The split is deliberate, so that if somebody needs virBufferEscapeN in the future they can revert the removal and get a working version. Peter Krempa (7): util: buffer: Remove misleading AUTOPTR func for 'virBuffer' util: buf: Fix memory leak in virBufferEscapeN tests: buf: Fix debug messages in 'testBufEscapeRegex' util: buf: Remove virBufferEscapeN util: alloc: Introduce 'VIR_AUTOCLEAN' macros for clearing stack'd structs util: buffer: Introduce VIR_AUTOCLEAN function for virBuffer qemu: domain: Use VIR_AUTOCLEAN for virBuffer src/libvirt_private.syms | 1 - src/qemu/qemu_domain.c | 27 +++------- src/util/viralloc.h | 32 +++++++++++- src/util/virbuffer.c | 107 --------------------------------------- src/util/virbuffer.h | 7 ++- tests/virbuftest.c | 57 +++++---------------- 6 files changed, 56 insertions(+), 175 deletions(-) -- 2.20.1

2 10

[libvirt] [PATCHv2 0/2] network: add netmask to dhcp range of dnsmasq conf file for IPv4
by Laine Stump 21 Feb '19

21 Feb '19

I sent V1 of this patch way back in October: https://www.redhat.com/archives/libvir-list/2018-October/msg00889.html but then self-NACKed it because I had written the patch to add the network prefix to dhcp-range, but IPv4 requires the netmask rather than range. Unfortunately, when I modified the patch accordingly the getnameinfo() function began failing, I couldn't immediately see why, and I had to pack everything up and go to KVM Forum. After that, I promptly forgot to look back at it. Today I finally revisited the problem (after the person who originally found it sent a reminder), and discovered the failure of getnameinfo() was due to a bug in a function that I added to the virSocketAddr library in 2010! Laine Stump (2): util: set missing data length in virSocketAddrPrefixToNetmask() network: add netmask to dhcp range of dnsmasq conf file for IPv4 src/network/bridge_driver.c | 27 +++++++++++++++---- src/util/virsocketaddr.c | 2 ++ .../dhcp6-nat-network.conf | 2 +- .../networkxml2confdata/isolated-network.conf | 2 +- .../nat-network-dns-srv-record-minimal.conf | 2 +- .../nat-network-dns-srv-record.conf | 2 +- .../nat-network-dns-txt-record.conf | 2 +- .../networkxml2confdata/nat-network-mtu.conf | 2 +- .../nat-network-name-with-quotes.conf | 2 +- tests/networkxml2confdata/nat-network.conf | 2 +- .../networkxml2confdata/netboot-network.conf | 2 +- .../netboot-proxy-network.conf | 2 +- .../networkxml2confdata/ptr-domains-auto.conf | 2 +- 13 files changed, 35 insertions(+), 16 deletions(-) -- 2.20.1

2 6

[libvirt] [PATCH 0/7] bulk snapshot list/redefine (incremental backup saga)
by Eric Blake 21 Feb '19

21 Feb '19

While looking at my work on incremental backups, Nir raised a good point: if we want to recreate a set of known checkpoints on one machine that will be taking over a domain from another machine, my initial proposal required making multiple API calls to list the XML for each checkpoint on the source, and then more API calls to redefine each checkpoint on the destination; it also had the drawback that the list has to be presented in topological order (the API won't let you define a child checkpoint if the parent is not defined first). He asked if I could instead add bulk APIs, for getting the XML for all checkpoints at once, and then for redefining all checkpoints at once. Since my checkpoint code borrows heavily from concepts in the snapshot code, I chose to tackle the problem by starting with this series, which does the same thing for snapshots as what I plan to do for checkpoints. That is, since this patch series adds virDomainGetXMLDesc(, VIR_DOMAIN_XML_SNAPSHOTS) and virDomainSnapshotCreateXML(, VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE_LIST), the checkpoint series will add virDOmainGetXMLDesc(, VIR_DOMAIN_XML_CHECKPOINTS) and virDomainCheckpointCreateXML(, VIR_DOMAIN_CHECKPOINT_CREATE_REDEFINE_LIST) with very similar code. Note that I'm posting the series now to start review; the bulk query is fully implemented (patch 6), while the bulk redefine still needs more work (patch 7 defines the API, but the actual implementation is trickier, so I'll be posting additional patches later once I get them working). Patch 1 is a revision of work posted previously in a different series where all other patches of that series are now on mainline. Also available at: https://repo.or.cz/libvirt/ericb.git/shortlog/refs/tags/snapshot-bulk-v1 Eric Blake (7): domain: Document VIR_DOMAIN_XML_MIGRATABLE snapshot: Give virDomainSnapshotDefFormat its own flags snapshot: Refactor virDomainSnapshotDefFormat snapshot: Add virDomainSnapshotObjListFormat domain: Expand virDomainDefFormatInternal with snapshots domain: Add VIR_DOMAIN_XML_SNAPSHOTS flag snapshot: Add VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE_LIST flag include/libvirt/libvirt-domain-snapshot.h | 3 + include/libvirt/libvirt-domain.h | 1 + src/conf/domain_conf.h | 8 ++ src/conf/snapshot_conf.h | 18 ++- src/conf/domain_conf.c | 71 ++++++++-- src/conf/snapshot_conf.c | 162 ++++++++++++++++------ src/esx/esx_driver.c | 1 - src/libvirt-domain-snapshot.c | 21 ++- src/libvirt-domain.c | 14 ++ src/libvirt_private.syms | 2 + src/network/bridge_driver.c | 3 +- src/qemu/qemu_domain.c | 24 +++- src/qemu/qemu_driver.c | 7 +- src/test/test_driver.c | 10 +- src/vbox/vbox_common.c | 5 +- src/vz/vz_driver.c | 3 +- tests/domainsnapshotxml2xmltest.c | 16 ++- tools/virsh-domain.c | 7 + tools/virsh-snapshot.c | 13 ++ 19 files changed, 293 insertions(+), 96 deletions(-) -- 2.20.1

1 10