- Devel - libvirt List Archives

[libvirt] [PATCH] vbox: Silently ignore missing registry key on Windows
by Matthias Bolte 11 Jan '11

11 Jan '11

Don't report an error when the VirtualBox registry key is missing, as this just indicates that VirtualBox is not installed in general. This matches the behavior of the XPCOM glue that silently ignores a missing VBoxXPCOMC.so. --- src/vbox/vbox_MSCOMGlue.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/vbox/vbox_MSCOMGlue.c b/src/vbox/vbox_MSCOMGlue.c index e6a886f..be0ec34 100644 --- a/src/vbox/vbox_MSCOMGlue.c +++ b/src/vbox/vbox_MSCOMGlue.c @@ -356,8 +356,6 @@ vboxLookupVersionInRegistry(void) status = RegOpenKeyEx(HKEY_LOCAL_MACHINE, keyName, 0, KEY_READ, &key); if (status != ERROR_SUCCESS) { - VIR_ERROR(_("Could not open registry key '%s' nor '%s'"), - VBOX_REGKEY_ORACLE, VBOX_REGKEY_SUN); return -1; } } -- 1.7.0.4

3 3

[libvirt] Docs team task: Update main docs.html page with index of all pages
by Justin Clift 11 Jan '11

11 Jan '11

Hi Anthony, (Following up from previous email, but CC'ing the libvirt team this time as some of the guys might have input/ideas/etc.) I'm thinking the very best thing you can do is get our "Docs" landing page under control for the main site: http://libvirt.org/docs.html It's very blank, relying on people to realise that everything is accessible on the left hand menu bar instead. :( What it should contain is an index to all of the main documentation pieces, so people can click directly from there. Some sort of menu structure will be needed (up to you, try things out). The way the website works, is that it's actually part of the libvirt source code. The "docs" directory in the source code is effectively the website. When people update the docs directory in the git repository, there's a cronjob on the libvirt.org server that rebuilds the live website. So, first things first, you'll need to make sure you have the "xhtml1-dtds" package installed. It's in the main CentOS repositories, so yum should know it automatically. Then you'll need to get the main libvirt source code from git: $ git clone git://libvirt.org/libvirt.git Cloning into libvirt... remote: Counting objects: 50501, done. remote: Compressing objects: 100% (8276/8276), done. remote: Total 50501 (delta 42262), reused 50237 (delta 42087) Receiving objects: 100% (50501/50501), 52.13 MiB | 165 KiB/s, done. Resolving deltas: 100% (42262/42262), done. $ ls -la total 0 drwxr-xr-x 3 user staff 102 8 Jan 21:47 . drwxr-xr-x@ 22 user staff 748 8 Jan 21:47 .. drwxr-xr-x 65 user staff 2210 8 Jan 21:55 libvirt (For me, on the opposite side of the world to the main libvirt.org server, this takes a while. Several minutes. Subsequent operations are much faster.) Then change into the newly created "libvirt" subdirectory, and run the "autogen.sh" command. This prepares the entire libvirt source code for compiling locally, including the website docs (which you'll need). $ ./autogen.sh (this will configure itself if all the needed utils are installed, or it might barf if somethings missing. It should proactively let you know if there's else that needs installing) Once the autogen.sh has finished, run "make". If you have a multi-core processor, run it as a parallel make using the -j option: $ make -j 5 Parallel makes are a *bunch* faster than just using a single core. The # to use is the number of cores in the box, plus one. (ie use -j 3 on a dual core, use -j 9 on a 8 core box, etc) If you open your browser, there should be in "index.html" file in the docs directory. Open that. Voila, it's the website. :) So, the file you need to update is the docs/docs.html.in one. When you make changes to it, run the "make" command again. That'll process it, converting it from docs.html.in, to docs.html. As you're trying things out and getting it right, feel free to copy the generated output to some temporary spot on the web then post the URL for comment/feedback/suggestions/etc. (I do this fairly often too) When you reckon it's all good and ready for inclusion, I'll give you the steps for generating a patch file and posting it. It's pretty simple. :) How's that so far? Regards and best wishes, Justin Clift

3 9

[libvirt] [PATCH] qemu: sound: Support intel 'hda' model
by Cole Robinson 11 Jan '11

11 Jan '11

In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML. Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default. --- docs/formatdomain.html.in | 5 +++-- docs/schemas/domain.rng | 1 + src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 14 +++++++++++++- .../qemuxml2argv-sound-device.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-sound-device.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-sound.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-sound.xml | 1 + 9 files changed, 24 insertions(+), 6 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index e9fcea1..8c43b74 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1663,8 +1663,9 @@ qemu-kvm -net nic,model=? /dev/null The <code>sound</code> element has one mandatory attribute, <code>model</code>, which specifies what real sound device is emulated. Valid values are specific to the underlying hypervisor, though typical - choices are 'es1370', 'sb16', and 'ac97' - (<span class="since">'ac97' only since 0.6.0</span>) + choices are 'es1370', 'sb16', 'ac97', and 'hda' + (<span class="since"> + 'ac97' only since 0.6.0, 'hda' only since 0.8.8</span>) </dd> </dl> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index a524e4b..491a5a5 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -1489,6 +1489,7 @@ <value>es1370</value> <value>pcspk</value> <value>ac97</value> + <value>hda</value> </choice> </attribute> <optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index c857a89..992435d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -225,7 +225,8 @@ VIR_ENUM_IMPL(virDomainSoundModel, VIR_DOMAIN_SOUND_MODEL_LAST, "sb16", "es1370", "pcspk", - "ac97") + "ac97", + "hda") VIR_ENUM_IMPL(virDomainMemballoonModel, VIR_DOMAIN_MEMBALLOON_MODEL_LAST, "virtio", diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index a459a22..d5ff9f3 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -458,6 +458,7 @@ enum virDomainSoundModel { VIR_DOMAIN_SOUND_MODEL_ES1370, VIR_DOMAIN_SOUND_MODEL_PCSPK, VIR_DOMAIN_SOUND_MODEL_AC97, + VIR_DOMAIN_SOUND_MODEL_HDA, VIR_DOMAIN_SOUND_MODEL_LAST }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 7dd8e03..2030455 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1726,11 +1726,13 @@ qemuBuildSoundDevStr(virDomainSoundDefPtr sound) goto error; } - /* Hack for 2 wierdly unusal devices name in QEMU */ + /* Hack for wierdly unusal devices name in QEMU */ if (STREQ(model, "es1370")) model = "ES1370"; else if (STREQ(model, "ac97")) model = "AC97"; + else if (STREQ(model, "hda")) + model = "intel-hda"; virBufferVSprintf(&buf, "%s", model); virBufferVSprintf(&buf, ",id=%s", sound->info.alias); @@ -3750,6 +3752,14 @@ qemuBuildCommandLine(virConnectPtr conn, goto error; virCommandAddArg(cmd, str); + + if (sound->model == VIR_DOMAIN_SOUND_MODEL_HDA) { + /* This is just an HDA codec, so doesn't require + * stable addressing AIUI */ + virCommandAddArgList(cmd, + "-device", "hda-output", NULL); + } + VIR_FREE(str); } } @@ -5529,6 +5539,8 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, type = VIR_DOMAIN_SOUND_MODEL_ES1370; } else if (STRPREFIX(start, "ac97")) { type = VIR_DOMAIN_SOUND_MODEL_AC97; + } else if (STRPREFIX(start, "hda")) { + type = VIR_DOMAIN_SOUND_MODEL_HDA; } if (type != -1) { diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args index 6b2e697..6cd4b4a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -usb -soundhw pcspk -device ES1370,id=sound1,bus=pci.0,addr=0x2 -device sb16,id=sound2 -device AC97,id=sound3,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -usb -soundhw pcspk -device ES1370,id=sound1,bus=pci.0,addr=0x2 -device sb16,id=sound2 -device AC97,id=sound3,bus=pci.0,addr=0x3 -device intel-hda,id=sound4,bus=pci.0,addr=0x4 -device hda-output -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml index c725346..f48c61e 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml @@ -22,6 +22,7 @@ <sound model='es1370'/> <sound model='sb16'/> <sound model='ac97'/> + <sound model='hda'/> <memballoon model='virtio'/> </devices> </domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound.args b/tests/qemuxml2argvdata/qemuxml2argv-sound.args index 8cb2da2..0db62c3 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -soundhw pcspk,es1370,sb16,ac97 +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -soundhw pcspk,es1370,sb16,ac97,hda diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml index d34e0b3..c713d05 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml @@ -24,6 +24,7 @@ <sound model='es1370'/> <sound model='sb16'/> <sound model='ac97'/> + <sound model='hda'/> <memballoon model='virtio'/> </devices> </domain> -- 1.7.3.3

4 12

[libvirt] [PATCH] Watchdog IB700 is not a PCI device (RHBZ#667091).
by Richard W.M. Jones 11 Jan '11

11 Jan '11

-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/

2 1

[libvirt] [RFC] Explicit boot device ordering
by Jiri Denemark 11 Jan '11

11 Jan '11

Hi, I'm working on $SUBJ and I can't decide on XML representation of that. The goal is to let users specify an ordered list of devices to boot from, e.g., 2nd NIC, 1st NIC, 1st CD-ROM, 2nd IDE disk. We already have boot elements in /domain/os so we could make use of them or we could add a boot element inside device elements. So for the first case, we could have something like <os> <boot target='net1'/> <boot target='net0'/> <boot target='hdc'/> <boot target='hdb'/> <os> Where target attributes would match /domain/devices/*/target@dev For the second case, appropriate devices would contain <boot order='n'/> elements. Personally I like the first option more since it is very easy to change boot order in that case and the whole boot list is co-located at a single place in domain XML. Do you feel the same or do you even have a better solution in your mind? Jirka

3 3

[libvirt] [PATCH] network: plug unininitialized read found by valgrind
by Eric Blake 11 Jan '11

11 Jan '11

* src/util/network.c (virSocketAddrMask): Zero out port, so that iptables can initialize just the netmask, then call virSocketFormatAddr without an uninitialized read in getnameinfo. --- I'm not sure if this is the best patch; an alternative would be to call memset(network,0,sizeof network) in iptablesFormatNetwork prior to virSocketAddrMaskByPrefix. But with this patch in place, valgrind no longer complained about: ==31478== Use of uninitialised value of size 8 ==31478== at 0x3021643DAB: _itoa_word (in /lib64/libc-2.12.so) ==31478== by 0x3021644E74: vfprintf (in /lib64/libc-2.12.so) ==31478== by 0x302166EFB1: vsnprintf (in /lib64/libc-2.12.so) ==31478== by 0x302164F022: snprintf (in /lib64/libc-2.12.so) ==31478== by 0x3021705135: getnameinfo (in /lib64/libc-2.12.so) ==31478== by 0x4E4FE00: virSocketFormatAddrFull (network.c:194) ==31478== by 0x4E4FCAE: virSocketFormatAddr (network.c:152) ==31478== by 0x4E43688: iptablesFormatNetwork (iptables.c:307) ==31478== by 0x4E43FDE: iptablesForwardMasquerade (iptables.c:761) ==31478== by 0x4E44392: iptablesRemoveForwardMasquerade (iptables.c:863) ==31478== by 0x4A8BEF: networkRemoveMasqueradingIptablesRules (bridge_driver.c:893) ==31478== by 0x4A9BCA: networkRemoveIpSpecificIptablesRules (bridge_driver.c:1244) ==31478== Uninitialised value was created by a stack allocation ==31478== at 0x4E43570: iptablesFormatNetwork (iptables.c:289) So I'm assuming that the uninitialized read was due to gethostname looking at the port field which was still filled with uninitialized stack data. src/util/network.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/util/network.c b/src/util/network.c index a7e7423..33028aa 100644 --- a/src/util/network.c +++ b/src/util/network.c @@ -1,7 +1,7 @@ /* * network.c: network helper APIs for libvirt * - * Copyright (C) 2009-2010 Red Hat, Inc. + * Copyright (C) 2009-2011 Red Hat, Inc. * * See COPYING.LIB for the License of this software * @@ -291,6 +291,7 @@ int virSocketAddrIsNetmask(virSocketAddrPtr netmask) { * virSocketAddrMask: * @addr: address that needs to be masked * @netmask: the netmask address + * @network: where to store the result, can be same as @addr * * Mask off the host bits of @addr according to @netmask, turning it * into a network address. @@ -311,6 +312,7 @@ virSocketAddrMask(const virSocketAddrPtr addr, network->data.inet4.sin_addr.s_addr = (addr->data.inet4.sin_addr.s_addr & netmask->data.inet4.sin_addr.s_addr); + network->data.inet4.sin_port = 0; network->data.stor.ss_family = AF_INET; network->len = addr->len; return 0; @@ -322,6 +324,7 @@ virSocketAddrMask(const virSocketAddrPtr addr, = (addr->data.inet6.sin6_addr.s6_addr[ii] & netmask->data.inet6.sin6_addr.s6_addr[ii]); } + network->data.inet6.sin6_port = 0; network->data.stor.ss_family = AF_INET6; network->len = addr->len; return 0; @@ -334,6 +337,7 @@ virSocketAddrMask(const virSocketAddrPtr addr, * virSocketAddrMaskByPrefix: * @addr: address that needs to be masked * @prefix: prefix (# of 1 bits) of netmask to apply + * @network: where to store the result, can be same as @addr * * Mask off the host bits of @addr according to @prefix, turning it * into a network address. -- 1.7.3.4

3 3

[libvirt] [PATCH] network: plug memory leak
by Eric Blake 11 Jan '11

11 Jan '11

* src/conf/network_conf.c (virNetworkDefParseXML): Release ipNodes. --- Another memleak found by valgrind; shown with additional context to make review easier. src/conf/network_conf.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index abe91b5..28a3ee8 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -1,22 +1,22 @@ /* * network_conf.c: network XML handling * - * Copyright (C) 2006-2010 Red Hat, Inc. + * Copyright (C) 2006-2011 Red Hat, Inc. * Copyright (C) 2006-2008 Daniel P. Berrange * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Author: Daniel P. Berrange <berrange(a)redhat.com> */ @@ -631,67 +631,69 @@ virNetworkDefParseXML(xmlXPathContextPtr ctxt) nIps = virXPathNodeSet("./ip", ctxt, &ipNodes); if (nIps > 0) { int ii; /* allocate array to hold all the addrs */ if (VIR_ALLOC_N(def->ips, nIps) < 0) { virReportOOMError(); goto error; } /* parse each addr */ for (ii = 0; ii < nIps; ii++) { int ret = virNetworkIPParseXML(def->name, &def->ips[ii], ipNodes[ii], ctxt); if (ret < 0) goto error; def->nips++; } } + VIR_FREE(ipNodes); /* IPv4 forwarding setup */ if (virXPathBoolean("count(./forward) > 0", ctxt)) { if (def->nips == 0) { virNetworkReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Forwarding requested, but no IP address provided")); goto error; } tmp = virXPathString("string(./forward[1]/@mode)", ctxt); if (tmp) { if ((def->forwardType = virNetworkForwardTypeFromString(tmp)) < 0) { virNetworkReportError(VIR_ERR_INTERNAL_ERROR, _("unknown forwarding type '%s'"), tmp); VIR_FREE(tmp); goto error; } VIR_FREE(tmp); } else { def->forwardType = VIR_NETWORK_FORWARD_NAT; } def->forwardDev = virXPathString("string(./forward[1]/@dev)", ctxt); } else { def->forwardType = VIR_NETWORK_FORWARD_NONE; } return def; error: virNetworkDefFree(def); + VIR_FREE(ipNodes); return NULL; } static virNetworkDefPtr virNetworkDefParse(const char *xmlStr, const char *filename) { xmlDocPtr xml; virNetworkDefPtr def = NULL; if ((xml = virXMLParse(filename, xmlStr, "network.xml"))) { def = virNetworkDefParseNode(xml, xmlDocGetRootElement(xml)); xmlFreeDoc(xml); } return def; } -- 1.7.3.4

3 3

[libvirt] [PATCH] cpu: plug memory leak
by Eric Blake 11 Jan '11

11 Jan '11

* src/cpu/cpu_x86.c (x86ModelLoad): Free data before overwriting. --- Yet another valgrind finding; 320 bytes per domain XML parse. src/cpu/cpu_x86.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c index df1e431..ae8e5e7 100644 --- a/src/cpu/cpu_x86.c +++ b/src/cpu/cpu_x86.c @@ -1,7 +1,7 @@ /* * cpu_x86.c: CPU driver for CPUs with x86 compatible CPUID instruction * - * Copyright (C) 2009-2010 Red Hat, Inc. + * Copyright (C) 2009-2011 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -973,6 +973,7 @@ x86ModelLoad(xmlXPathContextPtr ctxt, VIR_FREE(name); model->vendor = ancestor->vendor; + x86DataFree(model->data); if (!(model->data = x86DataCopy(ancestor->data))) goto no_memory; } -- 1.7.3.4

2 2

[libvirt] [RFC] Live disk snapshot API
by Jiri Denemark 11 Jan '11

11 Jan '11

Hi all. Purpose of this API is to help with making host-side backups of running domains without having to suspend them until backup finishes. The API can be used to create a consistent snapshot of a disk assigned to a domain, which can be later used for making backups. For better consistency, libvirt will try to notify the domain to make data on disk consistent. Guest agent is needed for this to work and libvirt will talk with it using hypervisor API or directly. Libvirt already provides snapshot support with virDomainSnapshot* APIs but they serve a bit different purpose. Domain snapshots consist of current state of all disks and runtime state (if the domain is running) taken at the same time. Since memory is also saved, domain snapshot creation can take some time during which the domain may need to be suspended. The main benefit of these APIs is that they can be used to create checkpoints of a domain in a known good state to which the domain can later be reverted. Disk snapshot API needs to be general and flexible enough to support various storage and snapshot methods. Examples of what can be used for creating disk snapshots are: QEMU qcow2 snapshots, LVM snapshots, filesystems with snapshot support (btrfs, zfs, ...), enterprise storage. Moreover, method used to create disk snapshot does not have to be determined by disk type. One can have a qcow2 disk stored on btrfs inside lvm logical volume; snapshot of such disk can be done at any of the three levels. Hypervisor support: QEMU supports snapshot_blkdev monitor command for creating qcow2 snapshots. VMware does not seem to support per-device snapshots, only per-VM snapshot without memory. VirtualBox provides IMedium::createDiffStorage(), IMedium::mergeTo() for per-device snapshots but they do not seem to work on disks in use. However, full support from hypervisors is not strictly required since snapshots can be done outside of them although at a possible cost of losing consistency. As different snapshot methods may require different input data, new diskSnapshot XML element is introduced to describe disk snapshot method: <diskSnapshot method='qemu|lvm|btrfs|...'>  </diskSnapshot> For qemu method, the element can be very simple: <diskSnapshot method='qemu'/> For lvm, logical volume device needs to be specified in case it is not the same as disk to be snapshotted: <diskSnapshot method='lvm'> <device path='/dev/vg/lv4'/> </diskSnapshot> Enterprise storage would need their own ways of identifying volumes to be snapshotted. The diskSnapshot element can be used inside disk element in domain XML: <domain ...> ... <devices> ... <disk ...> ... <diskSnapshot ...> ... </diskSnapshot> </disk> </devices> </domain> The "disk" part of "diskSnapshot" element name may seem to be redundant but I wanted to avoid confusion with snapshot XML element used for domain snapshots. Existing virDomainUpdateDevice API can be used to alter snapshot method on existing disk devices. To create a snapshot of a disk, the following API is introduced: int virDomainDiskSnapshotCreate(virDomainPtr domain, const char *disk, const char *method, const char *name, char **modifiedDisk, char **backupSource, unsigned int flags); @domain pointer to domain object @disk XML definition of the disk to snapshot @method optional <diskSnapshot> XML element overriding the one from <disk> element; if none of them is specified, default method according to disk type (and pool) is used; e.g., qcow disk => qemu method; logical volume in LVM pool => lvm method @name snapshot name @modifiedDisk place where to store modified XML description of the disk which the domain is now using; NULL is stored if domain is still using the original disk (snapshot was created separately) @backupSource place where to store 'source' element from disk XML describing the disk which can be used to take backups of 'disk' (i.e., read-only and immutable snapshot); it might either be the same as provided in 'disk' or something else (depending on method/implementation used); e.g., for qemu method, the element describes previous disk source; lvm creates a new device for snapshot and keeps writing into the original device @flags OR'ed set of flags: - VIR_DOMAIN_DISK_SNAPSHOT_QUIESCE_REQUIRED -- if no guest agent is running/answering requests for consistent disk state, fail the API; otherwise, the snapshot will be done regardless I have a slight feeling that the API is a bit over-engineered but I'm not entirely sure if it can be simplified and still provide the flexibility and future-compatibility. I have this feeling especially about backupSource output parameter which might possibly replaced with a simple char * (eventually returned directly by the API instead of int) containing file/device path. Another think which is not strictly needed is modifiedDisk. The caller can ask for domain XML and look the device there if needed but that would be quite complicated. Thus returning it from this API seemed useful and logical too, since the API is possibly changing disk XML and it make sense to return the changes. Deleting/merging snapshots previously created by virDomainDiskSnapshotCreate is not covered by this proposal and will need to be added in the future to complete disk snapshot support. Jirka

4 5

[libvirt] [PATCH] docs: updated memtune info again in virsh command reference
by Justin Clift 10 Jan '11

10 Jan '11

1 1