June 2015 - Devel - libvirt List Archives

[libvirt] [libvirt-glib] More coverage for networking API
by Zeeshan Ali (Khattak) 27 Jun '15

27 Jun '15

This set of patches improve our coverage for networking APIs of Libvirt.

1 5

[libvirt] [PATCH] qemu: Resolve Coverity RESOURCE_LEAK
by John Ferlan 27 Jun '15

27 Jun '15

Commit id '15fa84acb' added the alias fetch, but forgot to free it. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushing as trivial src/qemu/qemu_driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b6e05fa..2b530c8 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -11805,7 +11805,7 @@ qemuDomainGetBlockInfo(virDomainPtr dom, int rc; virHashTablePtr stats = NULL; qemuBlockStats *entry; - char *alias; + char *alias = NULL; virCheckFlags(0, -1); @@ -11891,6 +11891,7 @@ qemuDomainGetBlockInfo(virDomainPtr dom, endjob: qemuDomainObjEndJob(driver, vm); cleanup: + VIR_FREE(alias); virHashFree(stats); virDomainObjEndAPI(&vm); virObjectUnref(cfg); -- 2.1.0

1 0

[libvirt] [PATCH V2] libxl: support domainReset
by Jim Fehlig 26 Jun '15

26 Jun '15

Currently, libxl does not provide a reset function, but domainReset can be implemented in the libxl driver by forcibly destroying the domain and starting it again. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- This is essentially a V2 of a patch submitted quite some time ago https://www.redhat.com/archives/libvir-list/2014-August/msg00077.html The idea of implmenting domainReset in the libxl driver by forcibly destroying the domain and starting it again was ACK'ed in principle by Ian Campbell https://www.redhat.com/archives/libvir-list/2014-August/msg00109.html I never pushed the patch since it was not ACK'ed by a libvirt maintainer and stumbled across it while cleaning up some of my old branches. The only change here is rebase against current libvirt.git master. src/libxl/libxl_driver.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index 12be816..671d336 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -1237,6 +1237,64 @@ libxlDomainReboot(virDomainPtr dom, unsigned int flags) } static int +libxlDomainReset(virDomainPtr dom, unsigned int flags) +{ + libxlDriverPrivatePtr driver = dom->conn->privateData; + libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver); + virDomainObjPtr vm; + int ret = -1; + + virCheckFlags(0, -1); + + if (!(vm = libxlDomObjFromDomain(dom))) + goto cleanup; + + if (virDomainResetEnsureACL(dom->conn, vm->def) < 0) + goto cleanup; + + if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY) < 0) + goto cleanup; + + if (!virDomainObjIsActive(vm)) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("Domain is not running")); + goto endjob; + } + + /* + * The semantics of reset can be achieved by forcibly destroying + * the domain and starting it again. + */ + if (libxl_domain_destroy(cfg->ctx, vm->def->id, NULL) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to destroy domain '%d' before reset"), + vm->def->id); + goto endjob; + } + + libxlDomainCleanup(driver, vm, VIR_DOMAIN_SHUTOFF_DESTROYED); + + if (libxlDomainStart(driver, vm, false, -1) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to start domain '%d' after reset"), + vm->def->id); + goto endjob; + } + + ret = 0; + + endjob: + if (!libxlDomainObjEndJob(driver, vm)) + vm = NULL; + + cleanup: + if (vm) + virObjectUnlock(vm); + virObjectUnref(cfg); + return ret; +} + +static int libxlDomainDestroyFlags(virDomainPtr dom, unsigned int flags) { @@ -5066,6 +5124,7 @@ static virHypervisorDriver libxlHypervisorDriver = { .domainShutdown = libxlDomainShutdown, /* 0.9.0 */ .domainShutdownFlags = libxlDomainShutdownFlags, /* 0.9.10 */ .domainReboot = libxlDomainReboot, /* 0.9.0 */ + .domainReset = libxlDomainReset, /* 1.2.8 */ .domainDestroy = libxlDomainDestroy, /* 0.9.0 */ .domainDestroyFlags = libxlDomainDestroyFlags, /* 0.9.4 */ .domainGetOSType = libxlDomainGetOSType, /* 0.9.0 */ -- 2.3.7

1 1

[libvirt] ANNOUNCE: Oz 0.14.0 release
by Chris Lalancette 26 Jun '15

26 Jun '15

All, I'm pleased to announce release 0.14.0 of Oz. Oz is a program for doing automated installation of guest operating systems with limited input from the user. Release 0.14.0 is a bugfix and feature release for Oz. Some of the highlights between Oz 0.13.0 and 0.14.0 are: * Fix a bug in checksum checking (this should work again) * Add a global lock around pool refresh; should get rid of a user-visible failure * Support for Debian 8 * Support for Ubuntu 15.04 * Support for Fedora 22 * Support for installing aarch64 guests * Support for installing POWER guests * Support for install arm 32-bit guests A tarball and zipfile of this release is available on the Github releases page: https://github.com/clalancette/oz/releases . Packages for Fedora-21, Fedora-22, EPEL-7, and EPEL-6 have been built in Koji and will eventually make their way to stable. Instructions on how to get and use Oz are available at http://github.com/clalancette/oz/wiki . If you have questions or comments about Oz, please feel free to contact me at clalancette at gmail.com, or open up an issue on the github page: http://github.com/clalancette/oz/issues . Thanks to everyone who contributed to this release through bug reports, patches, and suggestions for improvement. Chris Lalancette

1 0

[libvirt] [PATCH 0/2] Add configuration time check for invalid lun settings
by John Ferlan 26 Jun '15

26 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1201143 Patch 1 is just a doc change - more a clarification regarding the 'exact' configuration for https://bugzilla.redhat.com/show_bug.cgi?id=1228007 Patch 2 adds a configuration time check for the correct settings when someone tries to configure a lun. This does to a degree duplicate some checks in the run time check qemuCheckDiskConfig, but since allowing the configuration was causing issues for at least virt-manager, it was requested to do config time checks. The copious comment in the code notes that the volume check is only partial since at the time of post parse device callback, the Translation of source pool data to disk data has not occurred, so the "best" that can be done is to check if at least a non direct 'lun' volume type is being used (unless of course we translated the source pool). John Ferlan (2): docs: Clarification for when allowed to use 'lun' for "volume" conf: Validate disk lun using correct types docs/formatdomain.html.in | 3 ++- src/conf/domain_conf.c | 22 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 +- 3 files changed, 25 insertions(+), 2 deletions(-) -- 2.1.0

2 4

[libvirt] [sandbox 00/10] Actually use host-image mounts on /
by Cédric Bosdonnat 26 Jun '15

26 Jun '15

Hi all, In the virt-sandbox documentation we had examples with host-image mounts targetting /. However the / in the sandbox was still the host one. The main goal of this patch series is to fix that problem. This will also be needed to run docker container with libvirt-sandbox. I also added some configure flags to disable lzma or zlib support at build time. At least opensuse 13.2 doesn't have static lzma. Cédric Bosdonnat (10): Allow disabling build with lzma. Allow disabling zlib support. Enable strcmp checks in libvirt-sandbox-init-qemu.c Copy init-common and all its deps to config subdir Remove init-common dependency on libvirt-sandbox.so init-qemu: extract the mounts.cfg entry mounting code qemu: use mounts targeting / as root Add function to check if there is a mount with / target Don't add sandbox:root device if we have a mount targetting / container builder: don't expose host rootfs if unneeded cfg.mk | 2 +- configure.ac | 37 ++++- libvirt-sandbox/Makefile.am | 41 +++-- .../libvirt-sandbox-builder-container.c | 22 +-- libvirt-sandbox/libvirt-sandbox-builder-machine.c | 136 +++++++++++++++-- libvirt-sandbox/libvirt-sandbox-config-all.h | 61 ++++++++ .../libvirt-sandbox-config-interactive.c | 2 +- .../libvirt-sandbox-config-mount-file.c | 2 +- .../libvirt-sandbox-config-mount-guest-bind.c | 2 +- .../libvirt-sandbox-config-mount-host-bind.c | 2 +- .../libvirt-sandbox-config-mount-host-image.c | 2 +- libvirt-sandbox/libvirt-sandbox-config-mount-ram.c | 2 +- libvirt-sandbox/libvirt-sandbox-config-mount.c | 2 +- .../libvirt-sandbox-config-network-address.c | 2 +- ...rt-sandbox-config-network-filterref-parameter.c | 2 +- .../libvirt-sandbox-config-network-filterref.c | 2 +- .../libvirt-sandbox-config-network-route.c | 2 +- libvirt-sandbox/libvirt-sandbox-config-network.c | 2 +- .../libvirt-sandbox-config-service-generic.c | 2 +- .../libvirt-sandbox-config-service-systemd.c | 2 +- libvirt-sandbox/libvirt-sandbox-config-service.c | 2 +- libvirt-sandbox/libvirt-sandbox-config.c | 23 ++- libvirt-sandbox/libvirt-sandbox-config.h | 1 + libvirt-sandbox/libvirt-sandbox-init-common.c | 5 +- libvirt-sandbox/libvirt-sandbox-init-qemu.c | 166 +++++++++++++++++---- libvirt-sandbox/libvirt-sandbox.h | 18 +-- libvirt-sandbox/libvirt-sandbox.sym | 1 + 27 files changed, 442 insertions(+), 101 deletions(-) create mode 100644 libvirt-sandbox/libvirt-sandbox-config-all.h -- 2.1.4

2 20

[libvirt] [libvirt-python PATCH] Revert "Change livbirt version to 1.3.0 for the next release"
by Martin Kletzander 26 Jun '15

26 Jun '15

This reverts commit 751e016f09a6a0dd372667bdd2b322731718e359. Since Admin API was deferred for a release and the minor version bump didn't happen, it must not happen in libvirt-python either, for compatibility reasons. --- This must be applied before release if and only if the same happens in libvirt upstream as stated above. setup.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/setup.py b/setup.py index 04e3de41fc71..8d34fde3e60d 100755 --- a/setup.py +++ b/setup.py @@ -311,7 +311,7 @@ class my_clean(clean): _c_modules, _py_modules = get_module_lists() setup(name = 'libvirt-python', - version = '1.3.0', + version = '1.2.17', url = 'http://www.libvirt.org', maintainer = 'Libvirt Maintainers', maintainer_email = 'libvir-list(a)redhat.com', -- 2.4.4

3 2

[libvirt] [PATCH v2 0/3] Defer Admin API enablement post-release
by Martin Kletzander 26 Jun '15

26 Jun '15

Even when rushing, you sometimes don't finish what you want. And I'd rather chosen safe road and avoid risks. And we have no usable API function in the admin API or a client binary just yet. Hence the temporary disablement in the second patch. First patch is a clean-up that's supposed to stay in even after release, second is designed to be cleanly reverted after release. Third patch moves the version back from 1.3.0 to 1.2.17, but is highly optional, meaning if anyone has a preference whether to take it in or not just express your opinion, it doesn't really matter. If yes, then I'll also change the version back in libvirt-python. Martin Kletzander (3): spec: Remove admin package specification Temporarily disable admin API Revert "Change livbirt version to 1.3.0 for the next release" Makefile.am | 2 +- configure.ac | 2 +- daemon/libvirtd.c | 3 ++- docs/Makefile.am | 5 ++--- docs/formatdomain.html.in | 6 +++--- include/libvirt/Makefile.am | 5 +++-- libvirt.spec.in | 21 ++++----------------- src/libvirt_public.syms | 2 +- src/vz/vz_driver.c | 8 ++++---- 9 files changed, 21 insertions(+), 33 deletions(-) -- 2.4.4

3 5

[libvirt] [PATCH 00/13] PCIe fixes + new PCI controllers w/RFC
by Laine Stump 26 Jun '15

26 Jun '15

The first 4 patches are bugfixes/reorganizations that have no controversy. The sets of 5-7, 8-10, and 11-13 each implement a new model of PCI controller: 5-7 - <controller type='pci' model='pcie-root-port'/> This is based on qemu's ioh3420. 8-10 - <controller type='pci' model='pcie-switch-upstream-port'/> Based on qemu's x3130-upstream 11-13 - <controller type='pci' model='pcie-switch-downstream-port'/> (xio3130-downstream) The first patch of each set adds a capability bit for qemu (again non-controversial), the 2nd adds the new pci controller model, and the 3rd implements that model in qemu (by checking for the capability and adding a commandline arg or failing). The "controversial"/RFC bit is this - talking to Alex Williamson (after I'd rwritten these patches, which is why I'm presenting them in a form that I *don't* want to push) about the possibility of qemu adding generic root-port, switch-upstream-port, and switch-downstream-port controllers, and possibly also a generic dmi-to-pci-bridge (i.e. controllers not tied to any particular hardware implementation as with those currently available), I'm realizing that, while it was a correct decision to make all of the existing pci controllers "type='pci'" (since they share an address space), using the "model" attribute to set the kind of controller was probably a mistake. The problem - if: <controller type='pci' model='dmi-to-pci-bridge'/> currently means to add an i82801b11-bridge controller to the domain, once qemu implements a generic dmi-to-pci-bridge, how will *that* be denoted, and how will we avoid replacing the existing i81801b11-bridge in a particular domain with the generic version when a guest is restarted following a qemu/libvirt upgrade? In hindsight, it probably would have been better to do something like this with the four existing pci controllers: <controller type='pci' subType='dmi-to-pci-bridge' model='i82801b11-bridge'/> <controller type='pci' subType='pci-bridge' model='pci-bridge'/> (or maybe blank?) <controller type='pci' subType='pci-root'/> (again maybe model is blank) <controller type='pci' subType='pcie-root'/>(and again) (instead, what is shown above as "subType" is currently placed in the "model" attribute). Then we could add the 3 new types like this: <controller type='pci' subType='pcie-root-port' model='ioh3420'/> <controller type='pci' subType='pcie-switch-upstream-port' model='x3130-upstream/> <controller type='pci' subType='pcie-switch-downstream-port' model='xio3130-downstream/> and we would easily be able to add support for new generic controllers that behaved identically, by just adding a new model. But we haven't done that, and anything we do in the future must be backwards compatible with what's already there (right?). I'm trying to think of how to satisfy backward compatibility while making things work better in the future. Some ideas, in no particular order: === Idea 1: multiplex the meaning of the "model" attribute, so we currently have: <controller type='pci' model='dmi-to-pci-bridge'/> which means "add an i82801b11-bridge device" and when we add a generic version of this type of controller, we would do it with something like: <controller type='pci' model='generic-dmi-to-pci-bridge'/> and for another vendor's mythical controller: <controller type='pci' model='xyz-dmi-to-pci-bridge'/> Cons: This will make for ugliness in switch statements where a new case will have to be added whenever a different controller with similar behavior/usage is supported. And it's generally not a good idea to have a single attribute be used for two different functions. === Idea 2: implement new controllers as suggested in "20/20 hindsight" above. For controllers in existing domains (dmi-to-pci-bridge, pic-bridge, pci-root, and pcie-root) imply it into the controller definition of an existing domain when only model has been given (but don't write it out that way, to preserve the ability to downgrade). So this: [1] <controller type='pci' model='dmi-to-pci-bridge'/> would internally mean this: [2] <controller type='pci' subType='dmi-to-pci-bridge' model='i82801b11-bridge'/> (but would remain as [1] when config is rewritten/migrated) while this: [3] <controller type='pci' subType='dmi-to-pci-bridge' model='anything whatsoever/> would mean exactly what it says. Cons: Keeping this straight would mean having some sort of "oldStyleCompat" flag in the controller object, to be sure that [1] wasn't sent in migration status as [2] (since the destination might not recognize it). It would also mean keeping the code in the parser and formatter to deal with this flag. Forever. === Idea 3: interpret controllers with missing subType as above, but actually write it out to the config/migration/etc in the new modified format. Cons: This would prevent downgrading libvirt or migrating from a host with newer libvirt to one with older libvirt. (Although preserving compatibility at some level when downgrading may be a stated requirement of some downstream distros' builds of libvirt, I think for upstream it is only a "best effort"; I'm just not certain how much "best" is considered to be :-) === Idea 4: Unlike other uses of "model" in libvirt, for pci controllers, continue to use "model" to denote the subtype/class/whatever of controller, and create a new attribute to denote the different specific implementations of each one. So for example: [4] <controller type='pci' model='dmi-to-pci-bridge'/> would become: [5] <controller type='pci' model='dmi-to-pci-bridge' implementation='i82801b11-bridge'/> (or some other name in place of "implementation" - ideas? I'm horrible at thinkin up names) Pros: wouldn't create compatibility problems when downgrading or migrating cross version. Cons: Is inconsistent with every other use of "model" attribute in libvirt, and each new addition of a PCI controller further propagates this misuse. ==== I currently like either option 2 or 3 (depending on how good we want to be about supporting downgrade/intra-version migration), but as is obvious by the fact that it was me that suggested putting the type of pci controller into "model", I am very good at making the wrong decision on matters like this. Whatever everyone thinks is best, patches 5-13 of this series would be changed accordingly, and possibly a couple new patches would be made to adjust the 4 existing controller types. Note that this will also effect the libvirt support for the upcoming qemu "pxb" controller, which is a PCI root bus that can be placed in its own numa node (my description may be incorrect, but I think it gets the idea across). Anyway, with idea 2 or 3 it would be: <controller type='pci' subType='pci-root' model='pxb'/> (along with some options to setup numa info). So, along with any comments on the individual patches (including whether the specific args added to the qemu commandline are correct - I'm looking at you, qemu people!), I would appreciate opinions on how I can save us from this misuse of "model" that I've created. Laine Stump (13): qemu: refactor qemuBuildControllerDevStr to eliminate future duplicate code qemu: always permit PCI devices to be manually assigned to a PCIe bus qemu: ignore assumptions about hotplug requirement when address is from config docs: document when pcie-root/dmi-to-pci-bridge support was added qemu: add capabilities bit for device ioh3420 conf: new pci controller model "pcie-root-port" qemu: support new pci controller model "pcie-root-port" qemu: add capabilities bit for device x3130-upstream conf: new pci controller model "pcie-switch-upstream-port" qemu: support new pci controller model "pcie-switch-upstream-port" qemu: add capabilities bit for device xio3130-downstream conf: new pcie-controller model "pcie-switch-downstream-port" qemu: support new pci controller model "pcie-switch-downstream-port" docs/formatdomain.html.in | 48 +++++++++--- docs/schemas/domaincommon.rng | 3 + src/conf/domain_addr.c | 47 ++++++++++-- src/conf/domain_addr.h | 23 ++++-- src/conf/domain_conf.c | 5 +- src/conf/domain_conf.h | 3 + src/qemu/qemu_capabilities.c | 8 +- src/qemu/qemu_capabilities.h | 5 +- src/qemu/qemu_command.c | 86 +++++++++++++++++----- tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 3 + tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 3 + tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 3 + tests/qemucapabilitiesdata/caps_1.5.3-1.caps | 3 + tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 3 + tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 3 + tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 3 + tests/qemuhelptest.c | 10 ++- .../qemuxml2argv-pcie-root-port.args | 10 +++ .../qemuxml2argv-pcie-root-port.xml | 33 +++++++++ .../qemuxml2argv-pcie-switch-downstream-port.args | 13 ++++ .../qemuxml2argv-pcie-switch-downstream-port.xml | 36 +++++++++ .../qemuxml2argv-pcie-switch-upstream-port.args | 9 +++ .../qemuxml2argv-pcie-switch-upstream-port.xml | 32 ++++++++ tests/qemuxml2argvtest.c | 25 +++++++ tests/qemuxml2xmltest.c | 3 + 25 files changed, 375 insertions(+), 45 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-upstream-port.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-upstream-port.xml -- 2.1.0

5 37

[libvirt] [PATCH 0/3] Defer Admin API enablement post-release
by Martin Kletzander 26 Jun '15

26 Jun '15

Even when rushing, you sometimes don't finish what you want. And I'd rather chosen safe road and avoid risks. And we have no usable API function in the admin API, yet. Hence the temporary disablement in the second patch. First patch is a clean-up that's supposed to stay in even after release. Third patch moves the version back from 1.3.0 to 1.2.17, but is highly optional, meaning if anyone has a preference whether to take it in or not just express your opinion, it doesn't really matter. If yes, then I'll also change the version back in libvirt-python. Martin Kletzander (3): spec: Remove admin package specification Temporarily disable admin API Revert "Change livbirt version to 1.3.0 for the next release" configure.ac | 2 +- daemon/libvirtd.c | 3 ++- docs/formatdomain.html.in | 6 +++--- libvirt.spec.in | 26 +++++++++----------------- src/libvirt_public.syms | 2 +- src/vz/vz_driver.c | 4 ++-- 6 files changed, 18 insertions(+), 25 deletions(-) -- 2.4.4

2 5