December 2015 - Devel - libvirt List Archives

[libvirt] [PATCH] rbd: Return VIR_STORAGE_FILE_RAW as format for RBD volumes
by Wido den Hollander 04 Jan '16

04 Jan '16

This used to return 'unkown' and that was not correct. A vol-dumpxml now returns: <volume type='network'> <name>image3</name> <key>libvirt/image3</key> <source> </source> <capacity unit='bytes'>10737418240</capacity> <allocation unit='bytes'>10737418240</allocation> <target> <path>libvirt/image3</path> <format type='raw'/> </target> </volume> The RBD driver will now error out if a different format than RAW is provided when creating a volume. Signed-off-by: Wido den Hollander <wido(a)widodh.nl> --- src/conf/storage_conf.c | 3 ++- src/storage/storage_backend_rbd.c | 13 +++++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 9b8abea..7c81bab 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -220,7 +220,8 @@ static virStoragePoolTypeInfo poolTypeInfo[] = { }, .volOptions = { .defaultFormat = VIR_STORAGE_FILE_RAW, - .formatToString = virStoragePoolFormatDiskTypeToString, + .formatFromString = virStorageVolumeFormatFromString, + .formatToString = virStorageFileFormatTypeToString, } }, {.poolType = VIR_STORAGE_POOL_SHEEPDOG, diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index cdbfdee..80684eb 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -306,6 +306,7 @@ static int volStorageBackendRBDRefreshVolInfo(virStorageVolDefPtr vol, vol->target.capacity = info.size; vol->target.allocation = info.obj_size * info.num_objs; vol->type = VIR_STORAGE_VOL_NETWORK; + vol->target.format = VIR_STORAGE_FILE_RAW; VIR_FREE(vol->target.path); if (virAsprintf(&vol->target.path, "%s/%s", @@ -557,6 +558,12 @@ virStorageBackendRBDCreateVol(virConnectPtr conn ATTRIBUTE_UNUSED, { vol->type = VIR_STORAGE_VOL_NETWORK; + if (vol->target.format != VIR_STORAGE_FILE_RAW) { + virReportError(VIR_ERR_NO_SUPPORT, "%s", + _("only RAW volumes are supported by this storage pool")); + return -VIR_ERR_NO_SUPPORT; + } + VIR_FREE(vol->target.path); if (virAsprintf(&vol->target.path, "%s/%s", pool->def->source.name, @@ -603,6 +610,12 @@ virStorageBackendRBDBuildVol(virConnectPtr conn, goto cleanup; } + if (vol->target.format != VIR_STORAGE_FILE_RAW) { + virReportError(VIR_ERR_NO_SUPPORT, "%s", + _("only RAW volumes are supported by this storage pool")); + goto cleanup; + } + if (virStorageBackendRBDOpenRADOSConn(&ptr, conn, &pool->def->source) < 0) goto cleanup; -- 1.9.1

2 1

[libvirt] [PATCH 0/3] Various Valgrind fixes
by Michael Chapman 04 Jan '16

04 Jan '16

Valgrind reported a couple of memory leaks and jumps conditional on uninitialized values. Happy New Year! Michael Chapman (3): qemu: do not copy out non-existent block job info qemu: do not leak NBD disk data in migration cookie storage: do not leak storage pool XML filename src/qemu/qemu_driver.c | 4 ++-- src/qemu/qemu_migration.c | 5 +++-- src/storage/storage_driver.c | 10 +++++----- 3 files changed, 10 insertions(+), 9 deletions(-) -- 2.4.3

3 5

[libvirt] Non-contiguous NUMA cell numbers
by Andrea Bolognani 04 Jan '16

04 Jan '16

Hi all, libvirt currently doesn't allow you to configure a guest with something like <cpu> <topology sockets='2' cores='5' threads='8'/> <numa> <cell id='0' cpus='0-39' memory='1048576' unit='KiB'/> <cell id='16' cpus='40-79' memory='1048576' unit='KiB'/> </numa> </cpu> with the following error: XML error: Exactly one 'cell' element per guest NUMA cell allowed, non-contiguous ranges or ranges not starting from 0 are not allowed The error message is very specific about not allowing gaps in NUMA cell numbering; however, on the very same host, I have $ numactl --hard | head -1 available: 4 nodes (0-1,16-17) so gaps in numbering are definitely possible, at least on ppc64. Should we consider relaxing this requirement and allow arbitrarily-numbered NUMA cells? Is there a specific reason why it was forbidden in the first place? Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team

4 4

[libvirt] [PATCH v8 0/5] Partial posting of updates to Add quorum to libvirt
by John Ferlan 04 Jan '16

04 Jan '16

I took a few cycles to reformat the initial 5 patches of the add quorum support posted as a v7 here: http://www.redhat.com/archives/libvir-list/2015-December/msg00119.html These patches are easily separable from the rest of the series. Rather than see things linger for months on end, trying to make small leaps. Changes in the series are to reorder things slightly, follow some of the review comments from previous series, and a few other things along the way. I've looked at this way too long to - hopefully I haven't missed anything. Most I forget... One I do remember is the virStorageSourceCopy changes in patch 5 where I believe the "Get" and "Set" wanted to use the 'i' index rather than having the "Get" use the 'i' and the "Set" always use '0'. Matthias Gatto (5): virstoragefile: Add helper to get storage source backingStore virstoragefile: Add helper to set storage source backingStore virstoragefile: Use helper to get storage source backing store virstoragefile: Use helper to set storage source backing store virstoragefile: Convert storage source backingStore into backingStores src/conf/domain_conf.c | 25 +++++---- src/conf/storage_conf.c | 29 ++++++----- src/libvirt_private.syms | 2 + src/qemu/qemu_cgroup.c | 6 ++- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 35 ++++++++----- src/qemu/qemu_monitor_json.c | 4 +- src/security/security_dac.c | 3 +- src/security/security_selinux.c | 5 +- src/security/virt-aa-helper.c | 2 +- src/storage/storage_backend.c | 34 +++++++----- src/storage/storage_backend_fs.c | 46 +++++++++------- src/storage/storage_backend_gluster.c | 11 ++-- src/storage/storage_backend_logical.c | 15 ++++-- src/storage/storage_driver.c | 3 +- src/util/virstoragefile.c | 98 ++++++++++++++++++++++++++++++----- src/util/virstoragefile.h | 10 +++- tests/virstoragetest.c | 18 +++---- 18 files changed, 243 insertions(+), 105 deletions(-) -- 2.5.0

2 6

[libvirt] [PATCH] bhyve: bhyveload: respect boot dev and boot order
by Roman Bogorodskiy 02 Jan '16

02 Jan '16

Make bhyveload respect boot order as specified by os.boot section of the domain XML or by "boot order" for specific devices. As bhyve does not support a real boot order specification right now, it's just about choosing a single device to boot from. --- src/bhyve/bhyve_command.c | 49 ++++++++++++++++++++-- .../bhyvexml2argv-bhyveload-bootorder.args | 10 +++++ .../bhyvexml2argv-bhyveload-bootorder.ldargs | 3 ++ .../bhyvexml2argv-bhyveload-bootorder.xml | 30 +++++++++++++ .../bhyvexml2argv-bhyveload-bootorder1.args | 10 +++++ .../bhyvexml2argv-bhyveload-bootorder1.ldargs | 3 ++ .../bhyvexml2argv-bhyveload-bootorder1.xml | 29 +++++++++++++ .../bhyvexml2argv-bhyveload-bootorder2.args | 9 ++++ .../bhyvexml2argv-bhyveload-bootorder2.ldargs | 3 ++ .../bhyvexml2argv-bhyveload-bootorder2.xml | 24 +++++++++++ .../bhyvexml2argv-bhyveload-bootorder3.args | 10 +++++ .../bhyvexml2argv-bhyveload-bootorder3.ldargs | 3 ++ .../bhyvexml2argv-bhyveload-bootorder3.xml | 30 +++++++++++++ tests/bhyvexml2argvtest.c | 4 ++ 14 files changed, 214 insertions(+), 3 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.xml diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 6576029..1e5d4c7 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -522,6 +522,48 @@ virBhyveProcessBuildGrubbhyveCmd(virDomainDefPtr def, return cmd; } +static virDomainDiskDefPtr +virBhyveGetBootDisk(virConnectPtr conn, virDomainDefPtr def) +{ + size_t i; + virDomainDiskDefPtr match = NULL; + int best_index = INT_MAX; + int boot_cdrom = 0, boot_disk = 0; + + if (def->ndisks == 0) + return NULL; + + for (i = 0; i < def->os.nBootDevs; i++) { + switch (def->os.bootDevs[i]) { + case VIR_DOMAIN_BOOT_CDROM: + boot_cdrom = i; + break; + case VIR_DOMAIN_BOOT_DISK: + boot_disk = i; + break; + } + } + + for (i = 0; i < def->ndisks; i++) { + int bootIndex; + if (!virBhyveUsableDisk(conn, def->disks[i])) + continue; + + bootIndex = def->disks[i]->info.bootIndex; + if (def->disks[i]->device == VIR_DOMAIN_DISK_DEVICE_CDROM) + bootIndex += boot_cdrom; + else if (def->disks[i]->device == VIR_DOMAIN_DISK_DEVICE_DISK) + bootIndex += boot_disk; + + if (bootIndex < best_index) { + best_index = bootIndex; + match = def->disks[i]; + } + } + + return match; +} + virCommandPtr virBhyveProcessBuildLoadCmd(virConnectPtr conn, virDomainDefPtr def, const char *devmap_file, char **devicesmap_out) @@ -535,10 +577,11 @@ virBhyveProcessBuildLoadCmd(virConnectPtr conn, virDomainDefPtr def, } if (def->os.bootloader == NULL) { - disk = def->disks[0]; + disk = virBhyveGetBootDisk(conn, def); - if (!virBhyveUsableDisk(conn, disk)) - return NULL; + if (disk == NULL) + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("no bootable disks found")); return virBhyveProcessBuildBhyveloadCmd(def, disk); } else if (strstr(def->os.bootloader, "grub-bhyve") != NULL) { diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.args b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.args new file mode 100644 index 0000000..01a0290 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.args @@ -0,0 +1,10 @@ +/usr/sbin/bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \ +-s 2:0,ahci-hd,/tmp/freebsd.img \ +-s 4:0,ahci-cd,/tmp/cdrom.iso bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.ldargs new file mode 100644 index 0000000..24e0bc2 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.ldargs @@ -0,0 +1,3 @@ +/usr/sbin/bhyveload \ +-m 214 \ +-d /tmp/cdrom.iso bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.xml new file mode 100644 index 0000000..487caf0 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder.xml @@ -0,0 +1,30 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + </os> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='file' type='raw'/> + <source file='/tmp/cdrom.iso'/> + <target dev='hda' bus='sata'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <interface type='bridge'> + <model type='virtio'/> + <source bridge="virbr0"/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.args b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.args new file mode 100644 index 0000000..01a0290 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.args @@ -0,0 +1,10 @@ +/usr/sbin/bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \ +-s 2:0,ahci-hd,/tmp/freebsd.img \ +-s 4:0,ahci-cd,/tmp/cdrom.iso bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.ldargs new file mode 100644 index 0000000..32538b5 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.ldargs @@ -0,0 +1,3 @@ +/usr/sbin/bhyveload \ +-m 214 \ +-d /tmp/freebsd.img bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.xml new file mode 100644 index 0000000..6ea4631 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder1.xml @@ -0,0 +1,29 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <boot dev='hd'/> + </os> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='file' type='raw'/> + <source file='/tmp/cdrom.iso'/> + <target dev='hda' bus='sata'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <interface type='bridge'> + <model type='virtio'/> + <source bridge="virbr0"/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.args b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.args new file mode 100644 index 0000000..88de179 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.args @@ -0,0 +1,9 @@ +/usr/sbin/bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \ +-s 2:0,ahci-hd,/tmp/freebsd.img bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.ldargs new file mode 100644 index 0000000..32538b5 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.ldargs @@ -0,0 +1,3 @@ +/usr/sbin/bhyveload \ +-m 214 \ +-d /tmp/freebsd.img bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.xml new file mode 100644 index 0000000..f086a9e --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder2.xml @@ -0,0 +1,24 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + <boot dev='cdrom'/> + <boot dev='hd'/> + </os> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </disk> + <interface type='bridge'> + <model type='virtio'/> + <source bridge="virbr0"/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.args b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.args new file mode 100644 index 0000000..01a0290 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.args @@ -0,0 +1,10 @@ +/usr/sbin/bhyve \ +-c 1 \ +-m 214 \ +-u \ +-H \ +-P \ +-s 0:0,hostbridge \ +-s 3:0,virtio-net,faketapdev,mac=52:54:00:00:00:00 \ +-s 2:0,ahci-hd,/tmp/freebsd.img \ +-s 4:0,ahci-cd,/tmp/cdrom.iso bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.ldargs b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.ldargs new file mode 100644 index 0000000..24e0bc2 --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.ldargs @@ -0,0 +1,3 @@ +/usr/sbin/bhyveload \ +-m 214 \ +-d /tmp/cdrom.iso bhyve diff --git a/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.xml b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.xml new file mode 100644 index 0000000..c3edcdf --- /dev/null +++ b/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.xml @@ -0,0 +1,30 @@ +<domain type='bhyve'> + <name>bhyve</name> + <uuid>df3be7e7-a104-11e3-aeb0-50e5492bd3dc</uuid> + <memory>219136</memory> + <vcpu>1</vcpu> + <os> + <type>hvm</type> + </os> + <devices> + <disk type='file' device='disk'> + <driver name='file' type='raw'/> + <source file='/tmp/freebsd.img'/> + <target dev='hda' bus='sata'/> + <boot order='2'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='file' type='raw'/> + <source file='/tmp/cdrom.iso'/> + <target dev='hda' bus='sata'/> + <boot order='1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <interface type='bridge'> + <model type='virtio'/> + <source bridge="virbr0"/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + </devices> +</domain> diff --git a/tests/bhyvexml2argvtest.c b/tests/bhyvexml2argvtest.c index 3e57a78..bea4caa 100644 --- a/tests/bhyvexml2argvtest.c +++ b/tests/bhyvexml2argvtest.c @@ -130,6 +130,10 @@ mymain(void) DO_TEST("grub-defaults"); DO_TEST("grub-bootorder"); DO_TEST("grub-bootorder2"); + DO_TEST("bhyveload-bootorder"); + DO_TEST("bhyveload-bootorder1"); + DO_TEST("bhyveload-bootorder2"); + DO_TEST("bhyveload-bootorder3"); DO_TEST("bhyveload-explicitargs"); DO_TEST("custom-loader"); DO_TEST("disk-cdrom-grub"); -- 2.4.6

2 2

[libvirt] [PATCH] conf: rework code around 'append' attribute to make coverity happy
by Dmitry Mishin 29 Dec '15

29 Dec '15

Signed-off-by: Dmitry Mishin <dim(a)virtuozzo.com> --- src/conf/domain_conf.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index f210c0b..8895e10 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -1723,10 +1723,11 @@ virDomainChrSourceDefCopy(virDomainChrSourceDefPtr dest, switch (src->type) { case VIR_DOMAIN_CHR_TYPE_FILE: - dest->data.file.append = src->data.file.append; case VIR_DOMAIN_CHR_TYPE_PTY: case VIR_DOMAIN_CHR_TYPE_DEV: case VIR_DOMAIN_CHR_TYPE_PIPE: + if (src->type == VIR_DOMAIN_CHR_TYPE_FILE) + dest->data.file.append = src->data.file.append; if (VIR_STRDUP(dest->data.file.path, src->data.file.path) < 0) return -1; break; @@ -9386,12 +9387,12 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, switch ((virDomainChrType) def->type) { case VIR_DOMAIN_CHR_TYPE_FILE: - if (!append) - append = virXMLPropString(cur, "append"); case VIR_DOMAIN_CHR_TYPE_PTY: case VIR_DOMAIN_CHR_TYPE_DEV: case VIR_DOMAIN_CHR_TYPE_PIPE: case VIR_DOMAIN_CHR_TYPE_UNIX: + if (!append && def->type == VIR_DOMAIN_CHR_TYPE_FILE) + append = virXMLPropString(cur, "append"); /* PTY path is only parsed from live xml. */ if (!path && (def->type != VIR_DOMAIN_CHR_TYPE_PTY || @@ -9476,15 +9477,15 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, break; case VIR_DOMAIN_CHR_TYPE_FILE: + case VIR_DOMAIN_CHR_TYPE_PTY: + case VIR_DOMAIN_CHR_TYPE_DEV: + case VIR_DOMAIN_CHR_TYPE_PIPE: if (append && (def->data.file.append = virTristateSwitchTypeFromString(append)) <= 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Invalid append attribute value '%s'"), append); goto error; } - case VIR_DOMAIN_CHR_TYPE_PTY: - case VIR_DOMAIN_CHR_TYPE_DEV: - case VIR_DOMAIN_CHR_TYPE_PIPE: if (!path && def->type != VIR_DOMAIN_CHR_TYPE_PTY) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", -- 1.8.3.1

2 2

[libvirt] [PATCHv2 0/3] 'Append' attribute for serial ports output to file
by Dmitry Mishin 26 Dec '15

26 Dec '15

By default, QEMU truncates serial file on open. Sometimes, it could be weird - for example, when we are trying to investigate some event, which occured several restarts ago. This patch set adds an ability to preserve previous content. Dmitry Mishin (3): tests: add qemu 2.6 caps test conf: Add new 'append' attribute for chardevs with file source qemu: Process new 'append' attribute for char dev with output to a file docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 28 +- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 10 + tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 173 + tests/qemucapabilitiesdata/caps_2.6.0-1.replies | 4043 ++++++++++++++++++++ tests/qemucapabilitiestest.c | 1 + .../qemuxml2argv-serial-file-chardev.args | 2 +- .../qemuxml2argv-serial-file-chardev.xml | 2 +- tests/qemuxml2argvtest.c | 3 +- 12 files changed, 4264 insertions(+), 7 deletions(-) create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.replies -- 1.8.3.1

3 8

[libvirt] Proposal for snapshotting functions of volumes
by Wido den Hollander 25 Dec '15

25 Dec '15

Hi, Currently libvirt is lacking support for snapshotting volumes through the storage pool mechanism. I want to add this to libvirt, but since the internals and the API design ideas of libvirt are not fully known to me I wanted to put this up for a basic review first. This patch can also be viewed on Github: https://github.com/wido/libvirt/commit/4483ab247f607250c5b3314d0a19509ef251… My main questions are: * Is this something we would like to see in libvirt? * If so, am I on the right track? * If so, what API calls should be different? The steps I want to take: 1. Add the new API calls 2. Add support to the RBD backend 3. Add support to virsh 4. Add support to the Java bindings The Apache CloudStack project uses libvirt intensively and I want to add as much support to libvirt as we need so that we don't do stuff inside CloudStack where libvirt might be a lot better place to do it. Any comments are very much appreciated before I start spending hours of my time on this :) Wido

1 1

[libvirt] centos6.5 virsh list hang and libvirtd can not restart
by 王李明 25 Dec '15

25 Dec '15

hi all： my environment is centos6.5 libvirt version is 1.2.14-1 qemu version is 1.7.0-1 I use openstack create a windows guest about two days later I run virsh list but the the process is hang virsh list can not return any thing it hang then I run /etc/init.d/libvirtd restart it show libivrtd stop faild and start failed I run /etc/init.d/libvirtd status it show libvired dead but subsys locked who can help me ? thans

2 2

[libvirt] [PATCH] vz: BUG: fix connecting hang in case of init failure
by Maxim Nestratov 24 Dec '15

24 Dec '15

In case of prlsdkLoadDomains fails, vzOpenDefault should clear connection privateData pointer every time its memory is actually freed. Also it is not necessary to call vzConnectClose if a call to vzOpenDefault fails, because they both make cleanup of connection privateData. Signed-off-by: Maxim Nestratov <mnestratov(a)virtuozzo.com> --- src/vz/vz_driver.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c index 2ef47e4..dfcffb4 100644 --- a/src/vz/vz_driver.c +++ b/src/vz/vz_driver.c @@ -266,6 +266,7 @@ vzOpenDefault(virConnectPtr conn) prlsdkDisconnect(privconn); prlsdkDeinit(); err_free: + conn->privateData = NULL; VIR_FREE(privconn); return VIR_DRV_OPEN_ERROR; } @@ -307,10 +308,8 @@ vzConnectOpen(virConnectPtr conn, return VIR_DRV_OPEN_ERROR; } - if ((ret = vzOpenDefault(conn)) != VIR_DRV_OPEN_SUCCESS) { - vzConnectClose(conn); + if ((ret = vzOpenDefault(conn)) != VIR_DRV_OPEN_SUCCESS) return ret; - } return VIR_DRV_OPEN_SUCCESS; } -- 2.4.3

2 1