- Devel - libvirt List Archives

[libvirt] [PATCH 0/3] Get the voldef target physical value
by John Ferlan 20 Dec '16

20 Dec '16

This effort started primarily to address some ideas/thoughts brought up in https://bugzilla.redhat.com/show_bug.cgi?id=1332019 although as things were updated, it seems that using storage volume definitions wouldn't be necessary since the same data can be obtained via the virDomainGetBlockInfo API. Still since code had been written - I figured I'd posted it and see what kind of feedback it got. The first patch just adds the <physical> element to the output XML and documents it thusly. The 2nd/3rd patch take a different approach adding virStorageVolInfoFlags which could take a single flag indicating that the caller would prefer to return the "physical" value instead of the "allocation" value. Yes, kind of a hack, but since we cannot extend _virStorageVolInfo to add a physical it's a mechanism to allow fetching the data using existing structures. Sure a virStorageVolStats API could be created as well, but I figured I'd see how this went first before thinking about that. John Ferlan (3): conf: Display <physical> in output of voldef storage: Introduce virStorageVolInfoFlags virsh: Allow display of the physical volume size daemon/remote.c | 38 +++++++++++++++++++++++++++++ docs/formatstorage.html.in | 5 ++++ include/libvirt/libvirt-storage.h | 11 +++++++++ src/conf/storage_conf.c | 6 +++++ src/driver-storage.h | 6 +++++ src/libvirt-storage.c | 51 +++++++++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 5 ++++ src/remote/remote_driver.c | 37 ++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 20 ++++++++++++++- src/remote_protocol-structs | 10 ++++++++ src/storage/storage_driver.c | 24 +++++++++++++++--- tools/virsh-volume.c | 37 +++++++++++++++++++++++++--- tools/virsh.pod | 8 ++++-- 13 files changed, 247 insertions(+), 11 deletions(-) -- 2.7.4

2 6

[libvirt] [PATCH 0/2] cgroup: unavailable controller prevents controller disabling
by Boris Fiuczynski 20 Dec '16

20 Dec '16

The problem description is covered in patch one. I added patch two as an optional enhancement removing some complexity and improving readability. If this finds common agreement it should simply be squashed into the first patch of this series. Boris Fiuczynski (2): cgroup: unavailable controller prevents controller disabling cgroup: reduce complexity of controller disabling src/util/vircgroup.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) -- 2.5.5

2 6

[libvirt] [PATCH] qemu: Adjust qemuDomainGetBlockInfo data for sparse backed files
by John Ferlan 20 Dec '16

20 Dec '16

According to commit id '0282ca45a' the 'physical' value should essentially be the last offset of the image or the host physical size in bytes of the image container. However, commit id '15fa84ac' refactored the GetBlockInfo to use the same returned data as the GetStatsBlock API for an active domain. For the 'entry->physical' that would end up being the "actual-size" as set through the qemuMonitorJSONBlockStatsUpdateCapacityOne (commit '7b11f5e5'). Digging deeper into QEMU code one finds that actual_size is filled in using the same algorithm as GetBlockInfo has used for setting the 'allocation' field when the domain is inactive. The difference in values is seen primarily in sparse raw files and other container type files (such as qcow2), which will return a smaller value via the stat API for 'st_blocks'. Additionally for container files, the 'capacity' field (populated via the QEMU "virtual-size" value) may be slightly different (smaller) in order to accomodate the overhead for the container. For sparse files, the state 'st_size' field is returned. This patch thus alters the allocation and physical values for sparse backed storage files to be more appropriate to the API contract. The result for GetBlockInfo is the following: capacity: logical size in bytes of the image (how much storage the guest will see) allocation: host storage in bytes occupied by the image (such as highest allocated extent if there are no holes, similar to 'du') physical: host physical size in bytes of the image container (last offset, similar to 'ls') NB: The GetStatsBlock API allows a different contract for the values: "block.<num>.allocation" - offset of the highest written sector as unsigned long long. "block.<num>.capacity" - logical size in bytes of the block device backing image as unsigned long long. "block.<num>.physical" - physical size in bytes of the container of the backing image as unsigned long long. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Initially based on a question posed on libvirt-users: https://www.redhat.com/archives/libvirt-users/2016-November/msg00050.html related to determining whether the provided physical value for an inactive guest would be valid I found that virDomainGetBlockInfo was returning different results for capacity and physical when the domain was running. As I dug deeper I found Eric Blake's commit regarding how libvirt uses/describes the allocation, capacity, and physical and felt that the changes made to virDomainGetBlockInfo especially for sparse files and "container" files (such as qcow2) would essentially provide incorrect and perhaps unexpected results. If it's felt that the live/active domain should return/display the same as the virConnectGetAllDomainStats, then I can drop the patch. I guess I find it odd that the physical size could be 4K matching the allocation value for a sparse file. Likewise, for a fully preallocated file was showing an allocation value of 0 since wr_highest_offset hadn't yet been updated. I've been testing with a guest with different types of "file" and "block" storage backings where the 'block' storage is essentially iSCSI devices added to the guest. Logically the changes result in what I'd expect for results based upon reading the API docs. src/qemu/qemu_driver.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 88778d4..c537891 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11808,13 +11808,29 @@ qemuDomainGetBlockInfo(virDomainPtr dom, info->allocation = entry->wr_highest_offset; } - if (entry->physical) { - info->physical = entry->physical; - } else { + /* Unlike GetStatsBlock, this API has defined the expected return values + * for allocation and physical slightly differently. + * + * Having a zero for either or if they're the same is an indication that + * there's a sparse file backing this device. In this case, we'll force + * the setting of physical based on the on disk file size. + * + * Additionally, if qemu hasn't written to the file yet, then set the + * allocation to whatever qemu returned for physical (e.g. the "actual- + * size" from the json query) as that will match the expected allocation + * value for this API. */ + if (entry->physical == 0 || info->allocation == 0 || + info->allocation == entry->physical) { + info->allocation = entry->physical; + if (info->allocation == 0) + info->allocation = entry->physical; + if (qemuDomainStorageUpdatePhysical(driver, cfg, vm, disk->src) < 0) goto endjob; info->physical = disk->src->physical; + } else { + info->physical = entry->physical; } info->capacity = entry->capacity; -- 2.7.4

2 1

[libvirt] [PATCH] examples: Resolve sign-compare warnings
by Michal Privoznik 20 Dec '16

20 Dec '16

For instance: hellolibvirt/hellolibvirt.c: In function 'showDomains': hellolibvirt/hellolibvirt.c:100:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < numNames; i++) { ^ Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- examples/admin/client_info.c | 2 +- examples/admin/client_limits.c | 2 +- examples/admin/list_clients.c | 2 +- examples/admin/list_servers.c | 2 +- examples/admin/threadpool_params.c | 2 +- examples/domsuspend/suspend.c | 2 +- examples/domtop/domtop.c | 7 +++---- examples/hellolibvirt/hellolibvirt.c | 2 +- examples/openauth/openauth.c | 2 +- 9 files changed, 11 insertions(+), 12 deletions(-) diff --git a/examples/admin/client_info.c b/examples/admin/client_info.c index 314a0902b..57e9cd71e 100644 --- a/examples/admin/client_info.c +++ b/examples/admin/client_info.c @@ -102,7 +102,7 @@ int main(int argc, char **argv) virAdmClientPtr clnt = NULL; /* which client get identity for */ virTypedParameterPtr params = NULL; /* where to store identity info */ int nparams = 0; - size_t i = 0; + ssize_t i = 0; char *timestr = NULL; if (argc != 3) { diff --git a/examples/admin/client_limits.c b/examples/admin/client_limits.c index 2d5b75489..2a1d6314c 100644 --- a/examples/admin/client_limits.c +++ b/examples/admin/client_limits.c @@ -9,7 +9,7 @@ int main(int argc, char **argv) virAdmServerPtr srv = NULL; /* which server to work with */ virTypedParameterPtr params = NULL; int nparams = 0; - size_t i; + ssize_t i; if (argc != 2) { fprintf(stderr, "One argument specifying the server which to work " diff --git a/examples/admin/list_clients.c b/examples/admin/list_clients.c index 3b4496e30..21ea4d818 100644 --- a/examples/admin/list_clients.c +++ b/examples/admin/list_clients.c @@ -50,7 +50,7 @@ int main(int argc, char **argv) virAdmConnectPtr conn = NULL; virAdmServerPtr srv = NULL; /* which server list the clients from */ virAdmClientPtr *clients = NULL; /* where to store the servers */ - size_t i = 0; + ssize_t i = 0; int count = 0; if (argc != 2) { diff --git a/examples/admin/list_servers.c b/examples/admin/list_servers.c index 1f6f4c6cf..420fd5fb7 100644 --- a/examples/admin/list_servers.c +++ b/examples/admin/list_servers.c @@ -8,7 +8,7 @@ int main(void) virAdmConnectPtr conn = NULL; virAdmServerPtr *servers = NULL; /* where to store the servers */ virAdmServerPtr *tmp = NULL; - size_t i = 0; + ssize_t i = 0; int count = 0; /* first, open a connection to the daemon */ diff --git a/examples/admin/threadpool_params.c b/examples/admin/threadpool_params.c index ee9ce83c1..43c71184a 100644 --- a/examples/admin/threadpool_params.c +++ b/examples/admin/threadpool_params.c @@ -9,7 +9,7 @@ int main(int argc, char **argv) virAdmServerPtr srv = NULL; /* which server to work with */ virTypedParameterPtr params = NULL; int nparams = 0; - size_t i; + ssize_t i; if (argc != 2) { fprintf(stderr, "One argument specifying the server which to work " diff --git a/examples/domsuspend/suspend.c b/examples/domsuspend/suspend.c index 3e3f70e23..493a4b7b2 100644 --- a/examples/domsuspend/suspend.c +++ b/examples/domsuspend/suspend.c @@ -156,7 +156,7 @@ fetch_domains(virConnectPtr conn) { int num_domains, ret = -1; virDomainPtr *domains = NULL; - size_t i; + ssize_t i; const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE; DEBUG("Fetching list of running domains"); diff --git a/examples/domtop/domtop.c b/examples/domtop/domtop.c index 22839947d..5a798154a 100644 --- a/examples/domtop/domtop.c +++ b/examples/domtop/domtop.c @@ -161,7 +161,7 @@ fetch_domains(virConnectPtr conn) { int num_domains, ret = -1; virDomainPtr *domains = NULL; - size_t i; + ssize_t i; const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE; DEBUG("Fetching list of running domains"); @@ -189,8 +189,7 @@ fetch_domains(virConnectPtr conn) } static void -print_cpu_usage(const char *dom_name, - size_t cpu, +print_cpu_usage(size_t cpu, size_t ncpus, unsigned long long then, virTypedParameterPtr then_params, @@ -334,7 +333,7 @@ do_top(virConnectPtr conn, goto cleanup; } - print_cpu_usage(dom_name, 0, max_id, + print_cpu_usage(0, max_id, then.tv_sec * 1000000 + then.tv_usec, then_params, then_nparams, now.tv_sec * 1000000 + now.tv_usec, diff --git a/examples/hellolibvirt/hellolibvirt.c b/examples/hellolibvirt/hellolibvirt.c index c64fa9658..02c440198 100644 --- a/examples/hellolibvirt/hellolibvirt.c +++ b/examples/hellolibvirt/hellolibvirt.c @@ -55,7 +55,7 @@ static int showDomains(virConnectPtr conn) { int ret = 0, numNames, numInactiveDomains, numActiveDomains; - size_t i; + ssize_t i; int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE | VIR_CONNECT_LIST_DOMAINS_INACTIVE; virDomainPtr *nameList = NULL; diff --git a/examples/openauth/openauth.c b/examples/openauth/openauth.c index 0be977ef8..7a8254bb1 100644 --- a/examples/openauth/openauth.c +++ b/examples/openauth/openauth.c @@ -91,7 +91,7 @@ static int showDomains(virConnectPtr conn) { int ret = 0, numNames, numInactiveDomains, numActiveDomains; - size_t i; + ssize_t i; char **nameList = NULL; numActiveDomains = virConnectNumOfDomains(conn); -- 2.11.0

2 1

Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
by Andrea Bolognani 20 Dec '16

20 Dec '16

On Tue, 2016-11-01 at 13:46 +1100, David Gibson wrote: > On Mon, Oct 31, 2016 at 03:10:23PM +1100, Alexey Kardashevskiy wrote: > > > > On 31/10/16 13:53, David Gibson wrote: > > > > > > On Fri, Oct 28, 2016 at 12:07:12PM +0200, Greg Kurz wrote: > > > > > > > > On Fri, 28 Oct 2016 18:56:40 +1100 > > > > Alexey Kardashevskiy <aik(a)ozlabs.ru> wrote: > > > > > > > > > > > > > > At the moment sPAPR PHB creates a root buf of TYPE_PCI_BUS type. > > > > > This means that vfio-pci devices attached to it (and this is > > > > > a default behaviour) hide PCIe extended capabilities as > > > > > the bus does not pass a pci_bus_is_express(pdev->bus) check. > > > > > > > > > > This changes adds a default PCI bus type property to sPAPR PHB > > > > > and uses TYPE_PCIE_BUS if none passed; older machines get TYPE_PCI_BUS > > > > > for backward compatibility as a bus type is used in the bus name > > > > > so the root bus name becomes "pcie.0" instead of "pci.0". > > > > > > > > > > Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> > > > > > --- > > > > > > > > > > What can possibly go wrong with such change of a name? > > > > > From devices prospective, I cannot see any. > > > > > > > > > > libvirt might get upset as "pci.0" will not be available, > > > > > will it make sense to create pcie.0 as a root bus and always > > > > > add a PCIe->PCI bridge and name its bus "pci.0"? > > > > > > > > > > Or create root bus from TYPE_PCIE_BUS and force name to "pci.0"? > > > > > pci_register_bus() can do this. > > > > > > > > > > > > > > > --- > > > > > hw/ppc/spapr.c | 5 +++++ > > > > > hw/ppc/spapr_pci.c | 5 ++++- > > > > > include/hw/pci-host/spapr.h | 1 + > > > > > 3 files changed, 10 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > > > > index 0b3820b..a268511 100644 > > > > > --- a/hw/ppc/spapr.c > > > > > +++ b/hw/ppc/spapr.c > > > > > @@ -2541,6 +2541,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true); > > > > > .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \ > > > > > .property = "mem64_win_size", \ > > > > > .value = "0", \ > > > > > + }, \ > > > > > + { \ > > > > > + .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \ > > > > > + .property = "root_bus_type", \ > > > > > + .value = TYPE_PCI_BUS, \ > > > > > }, > > > > > > > > > > static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index, > > > > > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c > > > > > index 7cde30e..2fa1f22 100644 > > > > > --- a/hw/ppc/spapr_pci.c > > > > > +++ b/hw/ppc/spapr_pci.c > > > > > @@ -1434,7 +1434,9 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp) > > > > > bus = pci_register_bus(dev, NULL, > > > > > pci_spapr_set_irq, pci_spapr_map_irq, sphb, > > > > > &sphb->memspace, &sphb->iospace, > > > > > - PCI_DEVFN(0, 0), PCI_NUM_PINS, TYPE_PCI_BUS); > > > > > + PCI_DEVFN(0, 0), PCI_NUM_PINS, > > > > > + sphb->root_bus_type ? sphb->root_bus_type : > > > > > + TYPE_PCIE_BUS); > > > > > > > > Shouldn't we ensure that sphb->root_bus_type is either TYPE_PCIE_BUS or > > > > TYPE_PCI_BUS ? > > > > > > Yes, I think so. In fact, I think it would be better to make the > > > property a boolean that just selects PCI-E, rather than this which > > > exposes qemu (semi-)internal type names on the comamnd line. > > > > Sure, a "pcie-root" boolean property should do. > > > > However this is not my main concern, I rather wonder if we have to have > > pci.0 when we pick PCIe for the root. > > Right. > > I've added Andrea Bologna to the CC list to get a libvirt perspective. Thanks for doing so: changes such as this one can have quite an impact on the upper layers of the stack, so the earliest libvirt is involved in the discussion the better. I'm going to go a step further and cross-post to libvir-list in order to give other libvirt contributors a chance to chime in too. > Andrea, > > To summarise the issue here: > * As I've said before the PAPR spec kinda-sorta abstracts the > difference between vanilla PCI and PCI-E > * However, because within qemu we're declaring the bus as PCI that > means some PCI-E devices aren't working right > * In particular it means that PCI-E extended config space isn't > available > > The proposal is to change (on newer machine types) the spapr PHB code > to declare a PCI-E bus instead. AIUI this still won't make the root > complex guest visible (which it's not supposed to be under PAPR), and > the guest shouldn't see a difference in most cases - it will still see > the PAPR abstracted PCIish bus, but will now be able to get extended > config space. > > The possible problem from a libvirt perspective is that doing this in > the simplest way in qemu would change the name of the default bus from > pci.0 to pcie.0. We have two suggested ways to mitigate this: > 1) Automatically create a PCI-E to PCI bridge, so that new machine > types will have both a pcie.0 and pci.0 bus > 2) Force the name of the bus to be pci.0, even though it's treated > as PCI-E in other ways. > > We're trying to work out exactly what will and won't cause trouble for > libvirt. Option 2) is definitely a no-no, as we don't want to be piling up even more hacks and architecture-specific code: the PCI Express Root Bus should be called pcie.0, just as it is on q35 and mach-virt machine types. Option 1) doesn't look too bad, but devices that are added automatically by QEMU are an issue since we need to hardcode knowledge of them into libvirt if we want the rest of the PCI address allocation logic to handle them correctly. Moreover libvirt now has the ability of building a legacy PCI topology without user intervention, if needed to plug in legacy devices, on machines that have a PCI Express Root Bus, which makes the additional bridge fully redundant... ... or at least it would, if we actually had a proper PCIe-to-PCI bridge; AFAIK, though, the closest we have is the i82801b11-bridge that is Intel-specific despite having so far been abused as a generic PCIe-to-PCI bridge. I'm not even sure whether it would work at all on ppc64. Moving from legacy PCI to PCI Express would definitely be an improvement, in my opinion. As mentioned, that's already the case for at least two other architectures, so the more we can standardize on that, the better. That said, considering that a big part of the PCI address allocation logic is based off whether the specific machine type exposes a legay PCI Root Bus or a PCI Express Root Bus, libvirt will need a way to be able to tell which one is which. Version checks are pretty much out of the question, as they fail as soon as downstream releases enter the picture. A few ways we could deal with the situation: 1) switch to PCI Express on newer machine types, and expose some sort of capability through QMP so that libvirt can know about the switch 2) switch between legacy PCI and PCI Express based on a machine type option. libvirt would be able to find out whether the option is available or not, and default to either <controller type='pci' model='pci-root'/> or <controller type='pci' model='pcie-root'/> based on that. In order to support multiple PHBs properly, those would have to be switchable with an option as well 3) create an entirely new machine type, eg. pseries-pcie or whatever someone with the ability to come up with decent names can suggest :) That would make ppc64 similar to x86, where i440fx and q35 have different root buses. libvirt would learn about the new machine type, know that it has a PCI Express Root Bus, and behave accordingly Option 1) would break horribly with existing libvirt versions, and so would Option 2) if we default to using PCI Express. Option 2) with default to legacy PCI and option 3) would work just fine with existing libvirt versions AFAICT, but wouldn't of course expose the new capabilities. Option 3) is probably the one that will be less confusing to users; we might even decide to take the chance and fix other small annoyances with the current pseries machine type, if there's any. On the other hand, it might very well be considered to be too big a hammer for such a small nail. -- Andrea Bolognani / Red Hat / Virtualization

9 32

[libvirt] [PATCH] Point to the new libvirt-go bindings
by Daniel P. Berrange 19 Dec '16

19 Dec '16

The github.com/rgbkrk/libvirt-go bindings were the most complete bindings historically, but their API coverage stops at 1.2.4, with exception of a couple of newer APIs. The new bindings at http://libvirt.org/git/?p=libvirt-go.git;a=log how have (almost[1]) 100% API coverage all the way to 2.5.0. They also expose the APIs in a way that allows for much stronger go type checking by the compiler, and expose typed parameters as explicit structs. Finally the bindings are able to conditionally compile against any libvirt version 1.2.0 -> 2.5.0 without use of go build tags. Change the docs to point to these new bindings, since they'll be a better bet for users long term. [1] virEvent & virStream callbacks are still TODO to be fixed real soon. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/bindings.html.in | 4 ++-- docs/docs.html.in | 2 +- docs/downloads.html.in | 15 +++++++++++++++ 3 files changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 7fe26df..dc15576 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -15,8 +15,8 @@ <a href="csharp.html">C# bindings</a>. </li> <li> - <strong>Go</strong>: Kyle Kelley et al. are developing - <a href="https://github.com/rgbkrk/libvirt-go">Go bindings</a>. + <strong>Go</strong>: Daniel Berrange develops + <a href="https://godoc.org/github.com/libvirt/libvirt-go">Go bindings</a>. </li> <li> <strong>Java</strong>: Daniel Veillard develops diff --git a/docs/docs.html.in b/docs/docs.html.in index b0d200b..60489a0 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -57,7 +57,7 @@ <dt><a href="bindings.html">Language bindings</a></dt> <dd>Bindings of the libvirt API for <a href="csharp.html">c#</a>, - <a href="https://github.com/rgbkrk/libvirt-go">go</a>, + <a href="https://godoc.org/github.com/libvirt/libvirt-go">go</a>, <a href="java.html">java</a>, <a href="http://libvirt.org/ocaml/">ocaml</a>. <a href="http://search.cpan.org/dist/Sys-Virt/">perl</a>, diff --git a/docs/downloads.html.in b/docs/downloads.html.in index dd96409..3a6ea91 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -57,6 +57,21 @@ </td> </tr> <tr> + <td>Go</td> + <td> + <a href="ftp://libvirt.org/libvirt/go/">ftp</a> + <a href="http://libvirt.org/sources/go/">http</a> + <a href="https://libvirt.org/sources/go/">https</a> + </td> + <td> + <a href="http://libvirt.org/git/?p=libvirt-go.git;a=summary">libvirt</a> + </td> + <td> + <a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a> + <a href="https://github.com/libvirt/libvirt-go">github</a> + </td> + </tr> + <tr> <td>Java</td> <td> <a href="ftp://libvirt.org/libvirt/java/">ftp</a> -- 2.9.3

2 1

[libvirt] [PATCH] xen: add QED format test
by Cédric Bosdonnat 19 Dec '16

19 Dec '16

Follow up of commit 340bb6b7 to add unit tests for the QED format support. Also add missing QED case in xenFormatXLDisk() --- src/xenconfig/xen_xl.c | 5 +++++ tests/xlconfigdata/test-disk-positional-parms-full.cfg | 2 +- tests/xlconfigdata/test-disk-positional-parms-full.xml | 6 ++++++ 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c index 048ecd579..65d8ffc63 100644 --- a/src/xenconfig/xen_xl.c +++ b/src/xenconfig/xen_xl.c @@ -1050,6 +1050,11 @@ xenFormatXLDisk(virConfValuePtr list, virDomainDiskDefPtr disk) case VIR_STORAGE_FILE_QCOW2: virBufferAddLit(&buf, "qcow2"); break; +#ifdef LIBXL_HAVE_QED + case VIR_STORAGE_FILE_QED: + virBufferAddLit(&buf, "qed"); + break; +#endif /* set default */ default: virBufferAddLit(&buf, "raw"); diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.cfg b/tests/xlconfigdata/test-disk-positional-parms-full.cfg index 217d4dccf..20421ffc1 100644 --- a/tests/xlconfigdata/test-disk-positional-parms-full.cfg +++ b/tests/xlconfigdata/test-disk-positional-parms-full.cfg @@ -22,4 +22,4 @@ parallel = "none" serial = "none" builder = "hvm" boot = "d" -disk = [ "/dev/HostVG/XenGuest2,raw,hda,rw,backendtype=phy", "/var/lib/libvirt/images/XenGuest2-home,qcow2,hdb,rw", "/root/boot.iso,raw,hdc,ro,devtype=cdrom" ] +disk = [ "/dev/HostVG/XenGuest2,raw,hda,rw,backendtype=phy", "/var/lib/libvirt/images/XenGuest2-home,qcow2,hdb,rw", "/root/boot.iso,raw,hdc,ro,devtype=cdrom", "/var/lib/libvirt/images/XenGuest2-qed,qed,hdd,rw", ] diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.xml b/tests/xlconfigdata/test-disk-positional-parms-full.xml index 1bc5b436e..9c2fb41b7 100644 --- a/tests/xlconfigdata/test-disk-positional-parms-full.xml +++ b/tests/xlconfigdata/test-disk-positional-parms-full.xml @@ -39,6 +39,12 @@ <readonly/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='qed'/> + <source file='/var/lib/libvirt/images/XenGuest2-qed'/> + <target dev='hdd' bus='ide'/> + <address type='drive' controller='0' bus='1' target='0' unit='1'/> + </disk> <controller type='ide' index='0'/> <interface type='bridge'> <mac address='00:16:3e:66:92:9c'/> -- 2.11.0

3 2

[libvirt] [PATCH] docs: link to news file and other resources
by Daniel P. Berrange 19 Dec '16

19 Dec '16

In the website reorg we accidentally lost all links to the nice reformatted news.html file. Add a link on the front page, and also extend the download page table so that it includes links to API docs and news files for each module (where available) Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/downloads.html.in | 12 ++++++++++++ docs/index.html.in | 1 + 2 files changed, 13 insertions(+) diff --git a/docs/downloads.html.in b/docs/downloads.html.in index 3a6ea91..d56e17b 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -20,6 +20,7 @@ <th>Releases</th> <th>GIT Repo</th> <th>GIT Mirrors</th> + <th>Resources</th> </tr> </thead> <tbody> @@ -37,6 +38,10 @@ <a href="https://gitlab.com/libvirt/libvirt">gitlab</a> <a href="https://github.com/libvirt/libvirt">github</a> </td> + <td> + <a href="html/index.html">api ref</a> + <a href="news.html">changes</a> + </td> </tr> <tr> <th colspan="7">Language bindings</th> @@ -70,6 +75,9 @@ <a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a> <a href="https://github.com/libvirt/libvirt-go">github</a> </td> + <td> + <a href="https://godoc.org/github.com/libvirt/libvirt-go">api ref</a> + </td> </tr> <tr> <td>Java</td> @@ -113,6 +121,10 @@ <a href="https://gitlab.com/libvirt/libvirt-perl">gitlab</a> <a href="https://github.com/libvirt/libvirt-perl">github</a> </td> + <td> + <a href="http://search.cpan.org/dist/Sys-Virt/">api ref</a> + <a href="http://libvirt.org/git/?p=libvirt-perl.git;a=blob;f=Changes;hb=HEAD">changes</a> + </td> </tr> <tr> <td>PHP</td> diff --git a/docs/index.html.in b/docs/index.html.in index bcb47f7..31bd6e0 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -41,6 +41,7 @@ <li>targets Linux, FreeBSD, <a href="windows.html">Windows</a> and OS-X</li> <li>is used by many <a href="apps.html">applications</a></li> </ul> + <p>Recent / forthcoming <a href="news.html">release changes</a></p> </div> <div class="panel"> -- 2.9.3

2 1

[libvirt] [PATCH] Fix running of nosetests on python 3
by Daniel P. Berrange 19 Dec '16

19 Dec '16

Previously the way Fedora installed /usr/bin/nosetests allowed it to be invoked with either python 2 or 3. Since Fedora 25 though, it contains a module name that only exists on python 2. So we need to be more intelligent and pick a different nosetests binary per version. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- setup.py | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) This is technically a CI build breaker fix for rawhide, but it could do with review so I've not pushed it yet. diff --git a/setup.py b/setup.py index bbcfe87..0d65763 100755 --- a/setup.py +++ b/setup.py @@ -277,6 +277,20 @@ class my_test(Command): self.build_platlib = os.path.join(self.build_base, 'lib' + plat_specifier) + def find_nosetests_path(self): + paths = [ + "/usr/bin/nosetests-%d.%d" % (sys.version_info[0], + sys.version_info[1]), + "/usr/bin/nosetests-%d" % (sys.version_info[0]), + "/usr/bin/nosetests", + ] + + for path in paths: + if os.path.exists(path): + return path + + raise Exception("Cannot find any nosetests binary") + def run(self): """ Run test suite @@ -289,7 +303,8 @@ class my_test(Command): else: os.environ["PYTHONPATH"] = self.build_platlib self.spawn([sys.executable, "sanitytest.py", self.build_platlib, apis[0]]) - self.spawn([sys.executable, "/usr/bin/nosetests"]) + nose = self.find_nosetests_path() + self.spawn([sys.executable, nose]) class my_clean(clean): -- 2.9.3

2 1

[libvirt] [PATCH] AppArmor: allow QEMU to set_process_name.
by intrigeri 19 Dec '16

19 Dec '16

https://bugzilla.redhat.com/show_bug.cgi?id=1369281 --- examples/apparmor/libvirt-qemu | 1 + 1 file changed, 1 insertion(+) diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu index 11381d4df0..a07291d583 100644 --- a/examples/apparmor/libvirt-qemu +++ b/examples/apparmor/libvirt-qemu @@ -21,6 +21,7 @@ /dev/ptmx rw, /dev/kqemu rw, @{PROC}/*/status r, + @{PROC}/@{pid}/task/@{tid}/comm rw, @{PROC}/sys/kernel/cap_last_cap r, # For hostdev access. The actual devices will be added dynamically -- 2.11.0

5 15