- Devel - libvirt List Archives

Re: [libvirt] [PATCH 2/2] qemu: Validate the domain after marking the current domain as transient
by Daniel P. Berrange 20 Mar '17

20 Mar '17

On Wed, Mar 08, 2017 at 10:32:32AM +0100, Marc Hartmayer wrote: > On Mon, Feb 27, 2017 at 11:20 AM +0100, "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > > On Mon, Feb 27, 2017 at 10:59:39AM +0100, Marc Hartmayer wrote: > >> On Thu, Feb 23, 2017 at 05:36 PM +0100, "Daniel P. Berrange" <berrange(a)redhat.com> wrote: > >> > On Thu, Feb 23, 2017 at 05:22:44PM +0100, Marc Hartmayer wrote: > >> >> On Thu, Feb 23, 2017 at 03:33 PM +0100, Michal Privoznik <mprivozn(a)redhat.com> wrote: > >> >> > On 02/23/2017 10:44 AM, Marc Hartmayer wrote: > >> >> >> Validate the domain that actually will be started. It's semantically > >> >> >> more clear and also it can detect failures that may have happened in > >> >> >> virDomainObjSetDefTransient(). > >> >> >> > >> >> >> Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> > >> >> >> Reviewed-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> > >> >> >> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> > >> >> >> --- > >> >> >> src/qemu/qemu_process.c | 6 +++--- > >> >> >> 1 file changed, 3 insertions(+), 3 deletions(-) > >> >> >> > >> >> >> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c > >> >> >> index a57d136..bd3a8b8 100644 > >> >> >> --- a/src/qemu/qemu_process.c > >> >> >> +++ b/src/qemu/qemu_process.c > >> >> >> @@ -4746,9 +4746,6 @@ qemuProcessInit(virQEMUDriverPtr driver, > >> >> >> vm->def->os.machine))) > >> >> >> goto cleanup; > >> >> >> > >> >> >> - if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, flags) < 0) > >> >> >> - goto cleanup; > >> >> >> - > >> >> >> /* Do this upfront, so any part of the startup process can add > >> >> >> * runtime state to vm->def that won't be persisted. This let's us > >> >> >> * report implicit runtime defaults in the XML, like vnc listen/socket > >> >> >> @@ -4757,6 +4754,9 @@ qemuProcessInit(virQEMUDriverPtr driver, > >> >> >> if (virDomainObjSetDefTransient(caps, driver->xmlopt, vm) < 0) > >> >> >> goto cleanup; > >> >> >> > >> >> >> + if (qemuProcessStartValidate(driver, vm, priv->qemuCaps, caps, flags) < 0) > >> >> >> + goto cleanup; > >> >> >> + > >> >> > > >> >> > This needs to be goto stop for the reasons described in the previous e-mail. > >> >> > > >> >> >> if (flags & VIR_QEMU_PROCESS_START_PRETEND) { > >> >> >> if (qemuDomainSetPrivatePaths(driver, vm) < 0) > >> >> >> goto cleanup; > >> >> >> > >> >> > > >> >> > Honestly, I like what we have now better. I mean, SetDefTransient() is > >> >> > very unlikely to fail. It's just doing a copy of domain definition (in a > >> >> > very stupid way, but lets save that for a different discussion). > >> >> > Basically, it will fail on OOM only (which you will not get on a Linux > >> >> > system, unless you really try). > >> >> > >> >> It's semantically more clear (at least for me) and for example it > >> >> enables us to change some parts of the transient domain before > >> >> validation (affect the transient domain only, not the persistent). > >> > > >> > What are you planning to change in the config before validation ? > >> > > >> > >> I'm implementing a feature which allows to select the boot device at > >> domain start time (something like 'virsh start --with-bootdevice sda > >> domain1'). The main reason why we want this is because the s390 > >> architecture boots only from the first device specified in the boot > >> order. > > > > There's no need to changes in the QEMU driver todo this. You can just > > query the current XML config, change the boot device in it, and then > > run virDomainCreateXML to launch the guest with the changed config, > > or virDomainDefineXML again to make the changed boot device permanent. > > > > First of all, I hope I understand you right :) (you can tell me as soon > as you have read the following text) > > I've followed your advice and tried to add this functionality without > any changes in the QEMU/hypervisor. For this I've created a new function > in the remote driver which will call the needed functions (get current > XML config for the domain, manipulate the XML config, and then use > virDomainCreateXML for starting). > > To get the current XML config is straightforward as you've mentioned - > just use 'virDomanGetXMLDesc(...)'. > > But how can I change the boot device? > 1) I could use libxml2 for manipulating the XML string which we will get > with calling 'virDomainGetXMLDesc(..)' but this is error-prone and just > duplicate work as we have to parse the XML string and the information of > it. Also, if there are any additions in the future for boot devices > there will be no 'compile time reminder' that you have to edit this > function. Yes, this is the way it is normally done. There is a tradeoff here between wanting to be reminded at compile time but seeing build breakage, and libvirt wanting to be able to extend its config info without breaking apps. The libvirt view is that the latter is more important. > or > 2) Parse the XML string into our internal representation (virDomainDef), > adjust the boot orders and create a new XML string out of this internal > representation (reverse to the way how virDomainDefCopy(...) works). But > there is the huge problem: > > We need 'virCapsPtr caps' and 'virDomainXMLOptionPtr xmlopt' for > virDomainDefFormat(...) and virDomainDefParseString(...) but we're on > the remote driver layer and therefore we've no direct access to this. We > could add a function to the hypervisor driver interface for getting > these but this is just awkward. The virDomainDef are private data structures just for internal libvirt usage. Even though virsh is in the libvirt source tree, it should be treated as if it were a standalone application and thus only use the public APIs. > So my question to you is: do you have a better idea for this? > > Many thanks in advance. > > PS. I hope it's okay for you that I'm writing to you only for the moment > (as it's somehow off topic). If not I'll send it to the mailing list :) It isn't off-topic, so I'm copying back in the list. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|

2 1

[libvirt] [PATCH 0/3] log|lock daemon: Don't spam logs with IO error messages after client disconnects
by Peter Krempa 18 Mar '17

18 Mar '17

See patch 3 for explanation Peter Krempa (3): rpc: socket: Add possibility to suppress errors on read hangup rpc: serverclient: Add option to suppress errors on EOF (log|lock)daemon: Don't spam logs with IO error messages after client disconnects src/locking/lock_daemon.c | 3 +++ src/logging/log_daemon.c | 3 +++ src/rpc/virnetserverclient.c | 13 +++++++++++++ src/rpc/virnetserverclient.h | 2 ++ src/rpc/virnetsocket.c | 33 +++++++++++++++++++++++++++------ src/rpc/virnetsocket.h | 2 ++ 6 files changed, 50 insertions(+), 6 deletions(-) -- 2.12.0

2 8

[libvirt] [REPOST PATCH 0/4] Split out storage object into its own module
by John Ferlan 18 Mar '17

18 Mar '17

Repost after merging with latest changes of: http://www.redhat.com/archives/libvir-list/2017-March/msg00305.html Continuing down the pile of drivers from my RFC for making a common pool object - we're now at storage... For reference see patch 3 of: http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html This series works through the storage conf adjustments. This pile is fairly straightforward. The virStorageVol* API's make it a bit more interesting, but like other series we split out anything referencing virStoragePoolObj and go from there. John Ferlan (4): conf: Introduce virstorageobj conf: Adjust coding style for storage conf sources conf: Alter coding style of storage conf function prototypes conf: Use consistent function name prefixes for virstorageobj po/POTFILES.in | 1 + src/Makefile.am | 3 +- src/conf/storage_conf.c | 975 ++--------------------------------------- src/conf/storage_conf.h | 174 ++------ src/conf/virstorageobj.c | 997 ++++++++++++++++++++++++++++++++++++++++++ src/conf/virstorageobj.h | 156 +++++++ src/libvirt_private.syms | 34 +- src/storage/storage_backend.h | 2 +- src/storage/storage_driver.c | 24 +- src/storage/storage_driver.h | 2 +- src/storage/storage_util.h | 1 - src/test/test_driver.c | 1 + 12 files changed, 1263 insertions(+), 1107 deletions(-) create mode 100644 src/conf/virstorageobj.c create mode 100644 src/conf/virstorageobj.h -- 2.9.3

2 5

[libvirt] [PATCH 0/4] Split out storage object into its own module
by John Ferlan 18 Mar '17

18 Mar '17

Continuing down the pile of drivers from my RFC for making a common pool object - we're now at storage... For reference see patch 3 of: http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html This series works through the storage conf adjustments. This pile is fairly straightforward. The virStorageVol* API's make it a bit more interesting, but like other series we split out anything referencing virStoragePoolObj and go from there. John Ferlan (4): conf: Introduce virstorageobj conf: Adjust coding style for storage conf sources conf: Alter coding style of storage conf function prototypes conf: Use consistent function name prefixes for virstorageobj po/POTFILES.in | 1 + src/Makefile.am | 3 +- src/conf/storage_conf.c | 965 ++--------------------------------------- src/conf/storage_conf.h | 174 ++------ src/conf/virstorageobj.c | 986 ++++++++++++++++++++++++++++++++++++++++++ src/conf/virstorageobj.h | 156 +++++++ src/libvirt_private.syms | 34 +- src/storage/storage_backend.h | 2 +- src/storage/storage_driver.c | 24 +- src/storage/storage_driver.h | 2 +- src/storage/storage_util.h | 1 - src/test/test_driver.c | 1 + 12 files changed, 1255 insertions(+), 1094 deletions(-) create mode 100644 src/conf/virstorageobj.c create mode 100644 src/conf/virstorageobj.h -- 2.9.3

2 6

[libvirt] [PATCH v2 0/4] qemu: Add support for generic PCIe Root Ports
by Andrea Bolognani 17 Mar '17

17 Mar '17

Blurby McBlurbface. Andrea Bolognani (4): qemu: Add support for generic PCIe Root Ports qemu: Use generic PCIe Root Ports by default when available tests: Test generic PCIe Root Ports news: Document support for generic PCIe Root Ports docs/news.xml | 10 ++++++ docs/schemas/domaincommon.rng | 1 + src/conf/domain_conf.c | 4 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 18 ++++++++-- src/qemu/qemu_domain_address.c | 13 +++++-- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../qemuxml2argv-pcie-root-port-model-generic.args | 22 ++++++++++++ .../qemuxml2argv-pcie-root-port-model-generic.xml | 22 ++++++++++++ .../qemuxml2argv-pcie-root-port-model-ioh3420.args | 21 ++++++++++++ .../qemuxml2argv-pcie-root-port-model-ioh3420.xml | 19 ++++++++++ tests/qemuxml2argvtest.c | 14 ++++++++ ...qemuxml2xmlout-pcie-root-port-model-generic.xml | 40 ++++++++++++++++++++++ ...qemuxml2xmlout-pcie-root-port-model-ioh3420.xml | 35 +++++++++++++++++++ tests/qemuxml2xmltest.c | 14 ++++++++ 17 files changed, 231 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-generic.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-generic.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-ioh3420.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-root-port-model-ioh3420.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root-port-model-generic.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-root-port-model-ioh3420.xml -- 2.7.4

2 10

[libvirt] [PATCH v1 0/2] libvirt-python: virEventAsyncIOImpl (was: libvirtaio)
by Wojtek Porczyk 17 Mar '17

17 Mar '17

Hello, As promised, this is the event loop implementation which dispatches the callbacks via asyncio's event loop. There are two patches: the first one fixes the bug around freeing opaque objects [1][2], and the second one is the actual implementation. Compared to standalone version I did earlier, this has public names more similar in style to other functions in the module. Also some comments are corrected, and packaging code is lightly touched. [1] https://www.redhat.com/archives/libvir-list/2017-January/msg00863.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1433028 Wojtek Porczyk (2): Allow for ff callbacks to be called by custom event implementations Add asyncio event loop implementation libvirt-override.c | 36 ++--- libvirt-override.py | 45 ++++++ libvirt-python.spec.in | 1 + libvirtaio.py | 398 +++++++++++++++++++++++++++++++++++++++++++++++++ sanitytest.py | 5 +- setup.py | 12 ++ 6 files changed, 471 insertions(+), 26 deletions(-) create mode 100644 libvirtaio.py -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers, | '-.-' | I fear lack of them. '-._ : ,-' -- Isaac Asimov `^-^-_>

2 3

[libvirt] [PATCH 00/12] qemu: Enforce guest CPU specification
by Jiri Denemark 17 Mar '17

17 Mar '17

When starting a domain with custom guest CPU specification QEMU may add or remove some CPU features. There are several reasons for this, e.g., QEMU/KVM does not support some requested features or the definition of the requested CPU model in libvirt's cpu_map.xml differs from the one QEMU is using. We can't really avoid this because CPU models are allowed to change with machine types and libvirt doesn't know (and probably doesn't even want to know) about such changes. Thus when we want to make sure guest ABI doesn't change when a domain gets migrated to another host, we need to update our live CPU definition according to the CPU QEMU created. Once updated, we will change CPU checking to VIR_CPU_CHECK_FULL to make sure the virtual CPU created after migration exactly matches the one on the source. https://bugzilla.redhat.com/show_bug.cgi?id=822148 https://bugzilla.redhat.com/show_bug.cgi?id=824989 Jiri Denemark (12): tests: Switch to sparse initialization of virCPUDef docs: Clarify /domain/cpu/@match description Introduce /domain/cpu/@check XML attribute qemu: Set default values for CPU check attribute qemu: Refactor Hyper-V features check qemu: Refactor KVM features check qemu: Refactor CPU features check qemu: Refactor qemuProcessVerifyGuestCPU qemu: Use ARCH_IS_X86 in qemuMonitorJSONGetGuestCPU qemu: Ask QEMU for filtered CPU features qemu: Update CPU definition according to QEMU qemu: Enforce guest CPU specification docs/formatdomain.html.in | 52 ++++- docs/schemas/cputypes.rng | 10 + docs/schemas/domaincommon.rng | 3 + src/conf/cpu_conf.c | 30 +++ src/conf/cpu_conf.h | 12 ++ src/conf/domain_conf.c | 21 ++ src/cpu/cpu.c | 45 +++++ src/cpu/cpu.h | 12 ++ src/cpu/cpu_x86.c | 105 ++++++++++ src/libvirt_private.syms | 1 + src/qemu/qemu_domain.c | 42 ++++ src/qemu/qemu_monitor.c | 11 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_monitor_json.c | 38 +++- src/qemu/qemu_monitor_json.h | 3 +- src/qemu/qemu_process.c | 225 +++++++++++++-------- tests/domaincapstest.c | 38 ++-- tests/qemumonitorjsontest.c | 4 +- .../qemuxml2argv-aarch64-gic-host.xml | 2 +- .../qemuxml2argv-aarch64-gic-v2.xml | 2 +- .../qemuxml2argv-aarch64-gic-v3.xml | 2 +- .../qemuxml2argv-cpu-check-default-none.args | 21 ++ .../qemuxml2argv-cpu-check-default-none.xml | 19 ++ .../qemuxml2argv-cpu-check-default-none2.args | 21 ++ .../qemuxml2argv-cpu-check-default-none2.xml | 21 ++ .../qemuxml2argv-cpu-check-default-partial.args | 22 ++ .../qemuxml2argv-cpu-check-default-partial.xml | 19 ++ .../qemuxml2argv-cpu-check-default-partial2.args | 21 ++ .../qemuxml2argv-cpu-check-default-partial2.xml | 21 ++ .../qemuxml2argv-cpu-check-full.args | 1 + .../qemuxml2argv-cpu-check-full.xml | 21 ++ .../qemuxml2argv-cpu-check-none.args | 21 ++ .../qemuxml2argv-cpu-check-none.xml | 21 ++ .../qemuxml2argv-cpu-check-partial.args | 1 + .../qemuxml2argv-cpu-check-partial.xml | 21 ++ tests/qemuxml2argvtest.c | 8 + .../qemuxml2xmlout-aarch64-aavmf-virtio-mmio.xml | 2 +- ...qemuxml2xmlout-aarch64-video-virtio-gpu-pci.xml | 2 +- .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 2 +- ...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 2 +- .../qemuxml2xmlout-cpu-check-default-none.xml | 28 +++ .../qemuxml2xmlout-cpu-check-default-none2.xml | 30 +++ .../qemuxml2xmlout-cpu-check-default-partial.xml | 30 +++ .../qemuxml2xmlout-cpu-check-default-partial2.xml | 30 +++ .../qemuxml2xmlout-cpu-check-full.xml | 30 +++ .../qemuxml2xmlout-cpu-check-none.xml | 30 +++ .../qemuxml2xmlout-cpu-check-partial.xml | 30 +++ .../qemuxml2xmlout-cpu-eoi-disabled.xml | 2 +- .../qemuxml2xmlout-cpu-eoi-enabled.xml | 2 +- .../qemuxml2xmlout-cpu-host-kvmclock.xml | 2 +- .../qemuxml2xmlout-cpu-host-model-features.xml | 2 +- ...emuxml2xmlout-cpu-host-passthrough-features.xml | 2 +- .../qemuxml2xmlout-cpu-kvmclock.xml | 2 +- .../qemuxml2xmlout-graphics-spice-timeout.xml | 2 +- tests/qemuxml2xmltest.c | 8 + tests/testutilsqemu.c | 48 ++--- 56 files changed, 1039 insertions(+), 167 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-none2.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-default-partial2.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-full.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-none.xml create mode 120000 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-check-partial.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-none2.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-default-partial2.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-full.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-none.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-cpu-check-partial.xml -- 2.12.0

2 16

[libvirt] [PATCH 0/4] qemu: fix handling of 'group_name' disk io tuning parameter
by Peter Krempa 17 Mar '17

17 Mar '17

Fix a crasher and an invalid configuration. Peter Krempa (4): qemu: Don't steal pointers from 'persistentDef' in qemuDomainGetBlockIoTune qemu: command: Extract blkdeviotune checks into a separate function qemu: command: Extract tests for subsets of blkdeviotune settings qemu: command: Don't allow setting 'group_name' alone src/qemu/qemu_command.c | 181 ++++++++++++++++++++++++++++++------------------ src/qemu/qemu_driver.c | 22 ++++-- 2 files changed, 127 insertions(+), 76 deletions(-) -- 2.12.0

2 5

[libvirt] Failure to probe cpu definitions for e.g. qemu-system-mips
by Guido Günther 17 Mar '17

17 Mar '17

Hi, while looking into a regression failing to start any mips qemu systems (http://bugs.debian.org/854125) I noticed that querying cpu definition does not work for lots of non intel architectures like mips due to lack of support for the query-cpu-definition monitor command: 2017-03-15 04:23:55.336+0000: 4238: warning : virQEMUCapsLogProbeFailure:4838 : Failed to probe capabilities for /usr/bin/qemu-system-mips: internal error: unable to execute QEMU command 'query-cpu-definitions': The command query-cpu-definitions has not been found 2017-03-15 04:23:55.374+0000: 4238: error : qemuMonitorJSONCheckError:387 : internal error: unable to execute QEMU command 'query-cpu-definitions': The command query-cpu-definitions has not been found Is support for query-cpu-definition a hard requirement or should we fail gracefully in this case? If not I can look into restoring that behaviour but would be happy about pointers what would be the best way forward. Cheers, -- Guido

3 6

[libvirt] [PATCH] perf: remote: Compare perf nparams against the correct constant
by Nitesh Konkar 17 Mar '17

17 Mar '17

Currently 'virsh perf domain' errors out as the perf nparams is incorrectly compared against REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX instead of REMOTE_DOMAIN_PERF_EVENTS_MAX. Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- daemon/remote.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/remote.c b/daemon/remote.c index f2b9b9a..1c9708c 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -3105,7 +3105,7 @@ remoteDispatchDomainGetPerfEvents(virNetServerPtr server ATTRIBUTE_UNUSED, if (virDomainGetPerfEvents(dom, &params, &nparams, args->flags) < 0) goto cleanup; - if (nparams > REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX) { + if (nparams > REMOTE_DOMAIN_PERF_EVENTS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; } -- 1.9.3

2 1