- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] virsh: Properly handle detach-interface --live --config.
by Nitesh Konkar 04 May '16

04 May '16

The virsh attach virsh detach interface command fails when both live and config are set and when the interface gets attached to different pci slots on live and config xml respectively. When we attach an interface with both --live and --config, the first time they get the same PCI slots, but the second time onwards it differs and hence the virsh detach-interface --live --config command fails. This patch makes sure that when both --live --config are set , qemuDomainDetachDeviceFlags is called twice, once with config xml and once with live xml. Steps to see the issue: virsh attach-interface --domain DomainName --type network --source default --mac 52:54:00:4b:76:5f --live --config virsh detach-interface --domain DomainName --type network --mac 52:54:00:4b:76:5f --live --config virsh attach-interface --domain DomainName --type network --source default --mac 52:54:00:4b:76:5f --live --config virsh detach-interface --domain DomainName --type network --mac 52:54:00:4b:76:5f --live --config Nitesh Konkar (2): virsh: Introduce virshDomainDetachInterface function virsh: Pass the correct live/config xml to virshDomainDetachInterface tools/virsh-domain.c | 128 +++++++++++++++++++++++++++++---------------------- 1 file changed, 73 insertions(+), 55 deletions(-) -- 1.8.3.1

2 5

[libvirt] [PATCH v2] bhyve: implement domainShutdown
by Roman Bogorodskiy 04 May '16

04 May '16

Bhyve supports ACPI shutdown by issuing SIGTERM signal to the bhyve process. Add the bhyveDomainShutdown() function and virBhyveProcessShutdown() helper function that just sends SIGTERM to VM's bhyve process. If a guest supports ACPI shutdown then process will be terminated and this event will be noticed by the bhyve monitor code that will handle setting proper status and clean up VM's resources. Also, remove usage of virProcessKillPainfully() from domainDestroy. First, it sends SIGTERM to the process that actually triggers ACPI reset and that's not we want to do. Second, we're doing bhyvectl --destroy later and it kills bhyve process, so there's no need to manually kill it. --- Changes from v1: - Sending SIGKILL dropped completely for destroy due to reasons described in the commit message. This is mainly based on the results of this (ongoing) discussion: https://lists.freebsd.org/pipermail/freebsd-virtualization/2016-April/00434… src/bhyve/bhyve_driver.c | 27 +++++++++++++++++++++++++++ src/bhyve/bhyve_process.c | 39 +++++++++++++++++++++++++++------------ src/bhyve/bhyve_process.h | 2 ++ 3 files changed, 56 insertions(+), 12 deletions(-) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index 5526bb0..4fc504e 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -1018,6 +1018,32 @@ bhyveDomainDestroy(virDomainPtr dom) } static int +bhyveDomainShutdown(virDomainPtr dom) +{ + virDomainObjPtr vm; + int ret = -1; + + if (!(vm = bhyveDomObjFromDomain(dom))) + goto cleanup; + + if (virDomainShutdownEnsureACL(dom->conn, vm->def) < 0) + goto cleanup; + + if (!virDomainObjIsActive(vm)) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("Domain is not running")); + goto cleanup; + } + + ret = virBhyveProcessShutdown(vm); + + cleanup: + if (vm) + virObjectUnlock(vm); + return ret; +} + +static int bhyveDomainOpenConsole(virDomainPtr dom, const char *dev_name ATTRIBUTE_UNUSED, virStreamPtr st, @@ -1502,6 +1528,7 @@ static virHypervisorDriver bhyveHypervisorDriver = { .domainCreateWithFlags = bhyveDomainCreateWithFlags, /* 1.2.3 */ .domainCreateXML = bhyveDomainCreateXML, /* 1.2.4 */ .domainDestroy = bhyveDomainDestroy, /* 1.2.2 */ + .domainShutdown = bhyveDomainShutdown, /* 1.3.3 */ .domainLookupByUUID = bhyveDomainLookupByUUID, /* 1.2.2 */ .domainLookupByName = bhyveDomainLookupByName, /* 1.2.2 */ .domainLookupByID = bhyveDomainLookupByID, /* 1.2.3 */ diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index 14588a9..e42ed74 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -281,23 +281,15 @@ virBhyveProcessStop(bhyveConnPtr driver, if ((priv != NULL) && (priv->mon != NULL)) bhyveMonitorClose(priv->mon); - /* First, try to kill 'bhyve' process */ - if (virProcessKillPainfully(vm->pid, true) != 0) - VIR_WARN("Failed to gracefully stop bhyve VM '%s' (pid: %d)", - vm->def->name, - (int)vm->pid); - - /* Cleanup network interfaces */ - bhyveNetCleanup(vm); - - /* No matter if shutdown was successful or not, we - * need to unload the VM */ if (!(cmd = virBhyveProcessBuildDestroyCmd(driver, vm->def))) - goto cleanup; + return -1; if (virCommandRun(cmd, NULL) < 0) goto cleanup; + /* Cleanup network interfaces */ + bhyveNetCleanup(vm); + ret = 0; virCloseCallbacksUnset(driver->closeCallbacks, vm, @@ -317,6 +309,29 @@ virBhyveProcessStop(bhyveConnPtr driver, } int +virBhyveProcessShutdown(virDomainObjPtr vm) +{ + if (vm->pid <= 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Invalid PID %d for VM"), + (int)vm->pid); + return -1; + } + + /* Bhyve tries to perform ACPI shutdown when it receives + * SIGTERM signal. So we just issue SIGTERM here and rely + * on the bhyve monitor to clean things up if process disappears. + */ + if (virProcessKill(vm->pid, SIGTERM) != 0) { + VIR_WARN("Failed to terminate bhyve process for VM '%s': %s", + vm->def->name, virGetLastErrorMessage()); + return -1; + } + + return 0; +} + +int virBhyveGetDomainTotalCpuStats(virDomainObjPtr vm, unsigned long long *cpustats) { diff --git a/src/bhyve/bhyve_process.h b/src/bhyve/bhyve_process.h index cfa80af..ebabe17 100644 --- a/src/bhyve/bhyve_process.h +++ b/src/bhyve/bhyve_process.h @@ -34,6 +34,8 @@ int virBhyveProcessStop(bhyveConnPtr driver, virDomainObjPtr vm, virDomainShutoffReason reason); +int virBhyveProcessShutdown(virDomainObjPtr vm); + int virBhyveGetDomainTotalCpuStats(virDomainObjPtr vm, unsigned long long *cpustats); -- 2.7.4

2 3

Re: [libvirt] [PATCHv2] virsh: blkdeviotune: accept human readable values for bytes
by Nitesh Konkar 04 May '16

04 May '16

Hello Nishith, Just a small suggestion on the indentation part of the patch. I think your indentation is off by 1 space. Thanks, Nitesh Konkar. On Wed, May 4, 2016 at 8:22 PM, Nitesh Konkar < niteshkonkar.libvirt(a)gmail.com> wrote: > Hello Nishith, > > Just a small suggestion on the indentation part of the patch. I think your > indentation is off by 1 space. > > Thanks, > Nitesh Konkar. > > > On Wed, May 4, 2016 at 7:55 PM, Nishith Shah <nishithshah.2211(a)gmail.com> > wrote: > >> Use vshCommandOptScaledInt instead of vshCommandOptULongLong so that >> values with suffixes can be passed when bytes are being passed along. >> Values for the iops parameters still need to be given in the absolute >> form as they are not bytes but numbers. Please refer to the bug link >> https://bugzilla.redhat.com/show_bug.cgi?id=885380 which can be closed. >> >> Signed-off-by: Nishith Shah <nishithshah.2211(a)gmail.com> >> --- >> tools/virsh-domain.c | 24 ++++++++++++------------ >> tools/virsh.pod | 18 ++++++++++++------ >> 2 files changed, 24 insertions(+), 18 deletions(-) >> >> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c >> index 0a6caae..336a65f 100644 >> --- a/tools/virsh-domain.c >> +++ b/tools/virsh-domain.c >> @@ -1164,7 +1164,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "total-bytes-sec", >> .type = VSH_OT_INT, >> - .help = N_("total throughput limit in bytes per second") >> + .help = N_("total throughput limit, as scaled integer (default >> bytes)") >> }, >> {.name = "read_bytes_sec", >> .type = VSH_OT_ALIAS, >> @@ -1172,7 +1172,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "read-bytes-sec", >> .type = VSH_OT_INT, >> - .help = N_("read throughput limit in bytes per second") >> + .help = N_("read throughput limit, as scaled integer (default >> bytes)") >> }, >> {.name = "write_bytes_sec", >> .type = VSH_OT_ALIAS, >> @@ -1180,7 +1180,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "write-bytes-sec", >> .type = VSH_OT_INT, >> - .help = N_("write throughput limit in bytes per second") >> + .help = N_("write throughput limit, as scaled integer (default >> bytes)") >> }, >> {.name = "total_iops_sec", >> .type = VSH_OT_ALIAS, >> @@ -1212,7 +1212,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "total-bytes-sec-max", >> .type = VSH_OT_INT, >> - .help = N_("total max in bytes") >> + .help = N_("total max, as scaled integer (default bytes)") >> }, >> {.name = "read_bytes_sec_max", >> .type = VSH_OT_ALIAS, >> @@ -1220,7 +1220,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "read-bytes-sec-max", >> .type = VSH_OT_INT, >> - .help = N_("read max in bytes") >> + .help = N_("read max, as scaled integer (default bytes)") >> }, >> {.name = "write_bytes_sec_max", >> .type = VSH_OT_ALIAS, >> @@ -1228,7 +1228,7 @@ static const vshCmdOptDef opts_blkdeviotune[] = { >> }, >> {.name = "write-bytes-sec-max", >> .type = VSH_OT_INT, >> - .help = N_("write max in bytes") >> + .help = N_("write max, as scaled integer (default bytes)") >> }, >> {.name = "total_iops_sec_max", >> .type = VSH_OT_ALIAS, >> @@ -1299,7 +1299,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> if (vshCommandOptStringReq(ctl, cmd, "device", &disk) < 0) >> goto cleanup; >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "total-bytes-sec", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "total-bytes-sec", >> &value, 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> @@ -1308,7 +1308,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> goto save_error; >> } >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "read-bytes-sec", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "read-bytes-sec", &value, >> 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> @@ -1317,7 +1317,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> goto save_error; >> } >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "write-bytes-sec", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "write-bytes-sec", >> &value, 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> @@ -1326,7 +1326,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> goto save_error; >> } >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "total-bytes-sec-max", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "total-bytes-sec-max", >> &value, 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> @@ -1335,7 +1335,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> goto save_error; >> } >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "read-bytes-sec-max", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "read-bytes-sec-max", >> &value, 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> @@ -1344,7 +1344,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd) >> goto save_error; >> } >> >> - if ((rv = vshCommandOptULongLong(ctl, cmd, "write-bytes-sec-max", >> &value)) < 0) { >> + if ((rv = vshCommandOptScaledInt(ctl, cmd, "write-bytes-sec-max", >> &value, 1, ULLONG_MAX)) < 0) { >> goto interror; >> } else if (rv > 0) { >> if (virTypedParamsAddULLong(&params, &nparams, &maxparams, >> diff --git a/tools/virsh.pod b/tools/virsh.pod >> index 2a95df7..6844823 100644 >> --- a/tools/virsh.pod >> +++ b/tools/virsh.pod >> @@ -1097,15 +1097,21 @@ I<domain> (see also B<domblklist> for listing >> these names). >> >> If no limit is specified, it will query current I/O limits setting. >> Otherwise, alter the limits with these flags: >> -I<--total-bytes-sec> specifies total throughput limit in bytes per >> second. >> -I<--read-bytes-sec> specifies read throughput limit in bytes per second. >> -I<--write-bytes-sec> specifies write throughput limit in bytes per >> second. >> +I<--total-bytes-sec> specifies total throughput limit as a scaled >> integer, the >> +default being bytes per second if no suffix is specified. >> +I<--read-bytes-sec> specifies read throughput limit as a scaled integer, >> the >> +default being bytes per second if no suffix is specified. >> +I<--write-bytes-sec> specifies write throughput limit as a scaled >> integer, the >> +default being bytes per second if no suffix is specified. >> I<--total-iops-sec> specifies total I/O operations limit per second. >> I<--read-iops-sec> specifies read I/O operations limit per second. >> I<--write-iops-sec> specifies write I/O operations limit per second. >> -I<--total-bytes-sec-max> specifies maximum total throughput limit in >> bytes per second. >> -I<--read-bytes-sec-max> specifies maximum read throughput limit in bytes >> per second. >> -I<--write-bytes-sec-max> specifies maximum write throughput limit in >> bytes per second. >> +I<--total-bytes-sec-max> specifies maximum total throughput limit as a >> scaled >> +integer, the default being bytes per second if no suffix is specified >> +I<--read-bytes-sec-max> specifies maximum read throughput limit as a >> scaled >> +integer, the default being bytes per second if no suffix is specified. >> +I<--write-bytes-sec-max> specifies maximum write throughput limit as a >> scaled >> +integer, the default being bytes per second if no suffix is specified. >> I<--total-iops-sec-max> specifies maximum total I/O operations limit per >> second. >> I<--read-iops-sec-max> specifies maximum read I/O operations limit per >> second. >> I<--write-iops-sec-max> specifies maximum write I/O operations limit per >> second. >> -- >> 2.1.4 >> >> -- >> libvir-list mailing list >> libvir-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list >> > >

3 3

[libvirt] [PATCH] admin: Add a check to reject negative argument for number of typed params
by Erik Skultety 04 May '16

04 May '16

Since nparams can be technically negative, it is a good practice throughout our code to check if nparams actually has a non-negative value. The same effect would be achieved by converting our internal typed params serializer argument to 'unsigned' type, but it definitely would not be the path of least resistance. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- src/libvirt-admin.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libvirt-admin.c b/src/libvirt-admin.c index a94f5dd..4ad816b 100644 --- a/src/libvirt-admin.c +++ b/src/libvirt-admin.c @@ -838,6 +838,7 @@ virAdmServerSetThreadPoolParameters(virAdmServerPtr srv, virCheckAdmServerReturn(srv, -1); virCheckNonNullArgGoto(params, error); + virCheckNonNegativeArgGoto(nparams, error); if (remoteAdminServerSetThreadPoolParameters(srv, params, nparams, flags) < 0) -- 2.4.11

2 2

[libvirt] [PATCH 0/4] virt-host-validate: add s390 support
by Bjoern Walk 04 May '16

04 May '16

This patch series adds support to the s390 platform for the virt-host-validate tool which detects virtualization capabilities of the host. It has been tested on x86 that no regression is introduced. Bjoern Walk (4): tools: virt-host-validate: fix missing translation marker tools: virt-host-validate: fix CPU flag detection tools: virt-host-validate: improve error handling tools: virt-host-validate: HW virt support on s390 tools/virt-host-validate-common.c | 12 +++++++----- tools/virt-host-validate-common.h | 1 + tools/virt-host-validate-qemu.c | 31 ++++++++++++++++++++++++------- 3 files changed, 32 insertions(+), 12 deletions(-) -- 2.6.6

2 5

[libvirt] RFC: migration with temporary external snapshot design considerations
by Nikolay Shirokovskiy 04 May '16

04 May '16

Hi, all. The result of "[RFC] live migration of VMs with internal snapshots" discussion is that it is nice to have ability to migrate images with internal snapshots while keeping intact their internal snaphot structure. Current qemu drive mirror functionality drops this structure and it is possible to workaround the issue with the help of taking extenal snapshot on source and then blockcommiting it back on destination after migration. The technique of creating temporary external snapshot could be useful in other cases too. For example in case of migration with disks on non cache coherent shared filesystem AFAIU. Thus I want to consider (and in case it is reasonable implement too) this functionality aside from migration with internal snapshots task where we have another issue of moving snapshot metadata to destination. The whole topic of design comes from the fact that blockcommit can fail. The fail itself is not a problem as AFAIK commiting active image does not invalidate it and can be restarted later. So the question is to when and how handle it. This can happen on source when we rollback after unsuccessfull migration or on destination as on finish phase in case of blockcommit fail we can't fail the migration anymore. I see two options. 1. Leave this situation to the mgmt. Thus we need to expose the fact of external snapshot in domain config and somehow signal that mgmt need to take care of situation. Well the fact that we expose this technical snapshot to upper level doubts the whole idea of making the workaround in libvirt itself. 2. Have some kind of background task in libvirt that will try to blockcomit with some policy. Well again, we introduce a policy which is considered to reside in mgmt and introduce background task which makes libvirt mgmt-like too. In anyway we will need to take special care while we have uncommited temporary snapshot. For example if we take internal snapshot at this time then it will be in temporary snapshot and be melted away after temporary snapshot is committed. Other block operations are probably are be affected too in this or another way. We can disable such operations for uncommited temporary snapshot. In case of mgmt managment this is job of mgmt and in case of libvirt managment this should be done in libvirt. All that said I guess the first approach is not the way to go as it fails to archive the goal - hide the details from mgmt layer. As to the second one I'd be glad to hear opinions of the community. Nikolay

1 0

[libvirt] [PATCH 0/3] Admin API: Add support for client disconnect
by Erik Skultety 04 May '16

04 May '16

This series adds a simple support for a client force disconnect. As with the series about client identity retrieval, this series is rebased on listing clients due to some gendispatch stuff needed in all of them. To test it, you checkout my remote branch https://github.com/eskultety/libvirt/tree/list-clients-info-disconnect Erik Skultety (3): admin: Introduce virAdmServerLookupClient admin: Introduce virAdmClientClose API virt-admin: Introduce client-disconnect command daemon/admin.c | 6 ++++ daemon/admin_server.c | 19 +++++++++++ daemon/admin_server.h | 7 ++++ include/libvirt/libvirt-admin.h | 7 ++++ include/libvirt/virterror.h | 1 + src/admin/admin_protocol.x | 27 +++++++++++++++- src/admin/admin_remote.c | 10 ++++++ src/admin_protocol-structs | 14 ++++++++ src/libvirt-admin.c | 66 +++++++++++++++++++++++++++++++++++++ src/libvirt_admin_private.syms | 3 ++ src/libvirt_admin_public.syms | 2 ++ src/rpc/virnetserver.c | 23 +++++++++++++ src/rpc/virnetserver.h | 3 ++ src/util/virerror.c | 6 ++++ tools/virt-admin.c | 72 +++++++++++++++++++++++++++++++++++++++++ tools/virt-admin.pod | 16 +++++++++ 16 files changed, 281 insertions(+), 1 deletion(-) -- 2.4.11

2 4

[libvirt] RFC filesystem pool proposal description.
by Olga Krishtal 04 May '16

04 May '16

In this proposal description we would like to introduce a separate pool type:fspool. Fspool provides and manages filesystems. Below are listed possible examples of fspool, depending on source type: volume, directory or network. Volume fspool uses storage pool volume to reside upon. <fspool type = 'volume'> <name>fspool</name> <uuid>cb07b799-8e03-485c-aaa0-7c88f60b37b0</uuid> <allocation>0</allocation> <capacity>0<capacity> <source> <pool ='pool name'/> <volume='volume name'/> <format type = 'ext4'/> (ext4, zfs - depending on type of volume that is used as a backend). <source/> <target> <path>/path/to/fspool</path> <permissions> <mode>0777</mode> <owner>0</owner> <group>0</group> </permissions> </target> </fspool> Directory fspool represents a host directory: <fspool type = 'dir'> <name>fspool</name> <uuid>cb07b799-8e03-485c-aaa0-7c88f60b37b0</uuid> <target> <path>/path/to/fspool/root</path> <permissions> <mode>0777</mode> <owner>0</owner> <group>0</group> </permissions> </target> </fspool> Network fspool is similar to previous one, except it is remote: <fspool type='network'> <name>fspool</name> <uuid>b27a72b5-a92e-4e58-a172-a80ba73b30fe</uuid> <source> <host name='X.X.X.X'/> - if the pool is not on the host <dir path='some/directory/exposed/to/our/host'/> </source> <target> <path>/fspool</path> </target> </fspool> basic API for fspool management: fspool-define fspool-build fspool-start fspool-stop fspool-destroy fspool-undefine Fspools are divided into fs items. Single item is a directory inside the fspool root directory. Fs item example is listed below: <fs> <name>item</name> <allocation>0</allocation> <capacity>0<capacity> <source>fspool='name'</source> <target> <path>/fspool</path> </target> <permissions> <mode>0777</mode> <owner>0</owner> <group>0</group> <cgroups> Limits</cgroups> </permissions> </fs> - allocation/capacity - is omitted when fspools type is directory. - target path is a path to fs item from the fspool root. If it is not present then the content of item is placed directly in fspool root. - cgroups can be used in order to manipulate space usage politics. Fs items will be manipulated via fs API: fs-define fs-delete fs-list In addition to containers use-cases, fspools are also useful for libvirt itself - they will help store and easily manage some internal metadata, such as snapshots or internal connection driver information (logs, domain configurations, etc). Please, take a look and share your opinion. Olga

4 7

[libvirt] [Ceph] blockInfo cannot work with network type disk
by ZhiQiang Fan 04 May '16

04 May '16

Hi devs & users, The Telemetry service of OpenStack, project code name Ceilometer, is using libvirt.domain.blockInfo() to get disk's physical, allocation and capacity information [1]. However, when disk is network type with protocol ceph, the blockInfo() always fail with: libvirtError: internal error: missing storage backend for network files using rbd protocol. [2] After reading some libvirt code, I think it might due to blockInfo() always assume disk is file backend [3], and file backend doesn't support network type [4]. I want to know if such limitation is by design? - If yes, then how should I get the network type disk's physical, allocation and capacity info? - If not, is there any plan to implement it? Thanks! [1] https://github.com/openstack/ceilometer/blob/stable/mitaka/ceilometer/compu… [2] https://bugs.launchpad.net/ceilometer/+bug/1457440 [3] https://github.com/libvirt/libvirt/blob/d6c25c34ef682a69f73f6ec200129e61b29… [4] https://github.com/libvirt/libvirt/blob/d6c25c34ef682a69f73f6ec200129e61b29…

1 0

[libvirt] [PATCH] libvirt.spec: remove duplicate files from -docs package
by Daniel P. Berrange 04 May '16

04 May '16

Previous commit moved some lists out of the -devel package and into the -docs package commit feffcc03a0d3690dcffd860682dcbaa61d726b39 Author: Cole Robinson <crobinso(a)redhat.com> Date: Wed Apr 13 10:37:42 2016 -0400 spec: Only pull in API docs with -devel package What was not realized is that the rule 'libvirt-docs/*' and ' docs/*.html docs/html docs/*.gif' actually point to the exact same content. ie, we had previously included the website HTML in *both* the -docs and -devel packages. So this change ended up listing the files twice, which caused RPM to print a load of warnings: warning: File listed twice: /usr/share/doc/libvirt-docs/html warning: File listed twice: /usr/share/doc/libvirt-docs/html/32favicon.png warning: File listed twice: /usr/share/doc/libvirt-docs/html/404.html warning: File listed twice: /usr/share/doc/libvirt-docs/html/acl.html warning: File listed twice: /usr/share/doc/libvirt-docs/html/aclpolkit.html Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- libvirt.spec.in | 1 - 1 file changed, 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index f441c51..a24be32 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1956,7 +1956,6 @@ exit 0 %defattr(-, root, root) %doc AUTHORS ChangeLog.gz NEWS README TODO %doc libvirt-docs/* -%doc docs/*.html docs/html docs/*.gif # API docs %dir %{_datadir}/gtk-doc/html/libvirt/ -- 2.5.5

2 1