- Devel - libvirt List Archives

[libvirt] any better way to treat device-detach timeout ?
by Zhangbo (Oscar) 14 Mar '16

14 Mar '16

Hi,all: I find that we remove devices only after DEVICE_DELETED event.(patch:3fbf78bd). And it treats TIMEOUT as success. The detailed codes are shown as below: rc = qemuDomainWaitForDeviceRemoval(vm); if (rc == 0 || rc == 1) ret = qemuDomainRemoveDiskDevice(driver, vm, detach); else ret = 0; Here comes the problem: If 1. We pass flags=3(VIR_DOMAIN_AFFECT_LIVE|VIR_DOMAIN_AFFECT_CONFIG) to virDomainDetachDeviceFlags, 2. It timed out to receive DEVICE_DELETED event, virDomainDetachDeviceFlags api will return 0(succeed). Please be aware that: vm->newdef(persistent) removes the device while vm->def(transient) keeps it untouched. 3. Then we try to attach the same device with flag 3, because it differs in newDef and def, the API virDomainDetachDeviceFlags() returns ERROR. Consequent attach/detach jobs all fail after then. So, shall we make it return FAIL when it fails in qemuDomainWaitForDeviceRemoval()? Or just remove the device in def after we get the DEVICE_DELETED event? Any ideas, thanks!

2 5

[libvirt] [PATCH REPOST 0/8] Reorganize qemu_command.c in smaller piles (round 2)
by John Ferlan 11 Mar '16

11 Mar '16

Rather than hope for a review of 25 patches or creating some remote place to place a branch - I'll repost the original: http://www.redhat.com/archives/libvir-list/2016-February/msg00975.html in smaller chunks. Differences in this set of patches vs. original series includes handling merge conflicts for logManager series plus a few minor edits/tweaks for better formatting/flow. This series was based off of git head commit 'ef2ab8fdc' which is the round 1 of the split: http://www.redhat.com/archives/libvir-list/2016-March/msg00288.html John Ferlan (8): qemu: Introduce qemuBuildSmartcardCommandLine qemu: Introduce qemuBuildSerialCommandLine qemu: Introduce qemuBuildParallelsCommandLine qemu: Introduce qemuBuildChannelsCommandLine qemu: Introduce qemuBuildConsoleCommandLine qemu: Modify qemuBuildTPMCommandLine qemu: Introduce qemuBuildInputCommandLine qemu: Introduce qemuBuildVideoCommandLine src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 1410 +++++++++++++++++++++++------------------- src/qemu/qemu_command.h | 6 +- 4 files changed, 760 insertions(+), 660 deletions(-) -- 2.5.0

2 16

[libvirt] [PATCH] Added qt-virt-manager to Application docs.
by F1ash 11 Mar '16

11 Mar '16

*** BLURB HERE *** F1ash (1): added qt-virt-manager to Application docs; docs/apps.html.in | 4 ++++ 1 file changed, 4 insertions(+) -- 2.7.2

1 1

[libvirt] [libvirt-glib v2 0/9] gconfig: Add hostdev support
by Christophe Fergeau 11 Mar '16

11 Mar '16

Hey, While reviewing Zeeshan's libvirt-gconfig hostdev series, I fixed up a few things, and added a few additional helpers/getters in order to simplify the code/make the test case more complete. This series contains this new code. The changes I made to Zeeshan's initial patches are in separate fixup! commits to make reviewing them easier (for you Zeeshan ;). I expect these to be squashed in the main commits before being pushed. Zeeshan's commits are unchanged from v1. Christophe

2 14

[libvirt] [libvirt-glib v3 1/5] gconfig: Add gvir_config_object_has_child
by Christophe Fergeau 11 Mar '16

11 Mar '16

--- libvirt-gconfig/libvirt-gconfig-object-private.h | 2 ++ libvirt-gconfig/libvirt-gconfig-object.c | 13 +++++++++++++ 2 files changed, 15 insertions(+) diff --git a/libvirt-gconfig/libvirt-gconfig-object-private.h b/libvirt-gconfig/libvirt-gconfig-object-private.h index e91c4ef..7a0d21f 100644 --- a/libvirt-gconfig/libvirt-gconfig-object-private.h +++ b/libvirt-gconfig/libvirt-gconfig-object-private.h @@ -117,6 +117,8 @@ GVirConfigObject *gvir_config_object_get_child(GVirConfigObject *object, GVirConfigObject *gvir_config_object_get_child_with_type(GVirConfigObject *object, const gchar *child_name, GType child_type); +gboolean gvir_config_object_has_child(GVirConfigObject *object, + const gchar *child_name); G_END_DECLS diff --git a/libvirt-gconfig/libvirt-gconfig-object.c b/libvirt-gconfig/libvirt-gconfig-object.c index bf328f3..6225de2 100644 --- a/libvirt-gconfig/libvirt-gconfig-object.c +++ b/libvirt-gconfig/libvirt-gconfig-object.c @@ -970,3 +970,16 @@ gvir_config_object_get_child(GVirConfigObject *object, child_name, GVIR_CONFIG_TYPE_OBJECT); } + +G_GNUC_INTERNAL gboolean +gvir_config_object_has_child(GVirConfigObject *object, const gchar *child_name) +{ + xmlNodePtr node; + + g_return_val_if_fail(GVIR_CONFIG_IS_OBJECT(object), FALSE); + g_return_val_if_fail(child_name != NULL, FALSE); + + node = gvir_config_xml_get_element(object->priv->node, child_name, NULL); + + return (node != NULL); +} -- 2.5.0

1 4

Re: [libvirt] dist-git build problem on epel-6-x86_64 chroot
by Jean-Marc LIGER 11 Mar '16

11 Mar '16

Le 19/02/2016 11:40, Miroslav Suchý a écrit : > Dne 19.1.2016 v 17:01 Jean-Marc LIGER napsal(a): >> Hy, >> >> I'm facing the problem below on epel-6-x86_64 chroot for both from URL and upload SRPM : >> >> [2016-01-19 15:16:26,790][ INFO][PID:3241] Setting up builder: 172.25.94.167 >> [2016-01-19 15:16:27,991][ INFO][PID:3241] marking build dir with build_id, >> [2016-01-19 15:16:27,992][ INFO][PID:3241] Start build: BuildJob<id: 154509, owner: jmliger, project: virt6-upstream, >> git branch: el6, git_hash: acef5efd6153aa8f9ea760f468333e65c9b46a4e, status: 3 > >> [2016-01-19 15:16:27,993][ INFO][PID:3241] putting into minimal buildroot of epel-6-x86_64 >> [2016-01-19 15:16:28,902][ INFO][PID:3241] Cloning Dist Git repo jmliger/virt6-upstream/libvirt, branch >> acef5efd6153aa8f9ea760f468333e65c9b46a4e, hash el6 >> [2016-01-19 15:16:30,906][ ERROR][PID:3241] Failed to obtain srpm from dist-git >> Traceback (most recent call last): >> File "/usr/share/copr/backend/mockremote/builder.py", line 209, in download_job_pkg_to_builder >> self.remote_pkg_path = list(results["contacted"].values())[0][u"stdout"].split("Wrote: ")[1] >> IndexError: list index out of range >> [2016-01-19 15:16:30,911][ ERROR][PID:3241] builder.build error building pkg `libvirt`: BuildError: Failed to obtain >> srpm from dist-git: ansible results {'dark': {}, 'contacted': {'172.25.94.167': {'cmd': 'rm -rf /tmp/build_package_repo >> && mkdir /tmp/build_package_repo && cd /tmp/build_package_repo && git clone >> http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libvir… && cd libvirt && git checkout >> acef5efd6153aa8f9ea760f468333e65c9b46a4e && fedpkg-copr --dist el6 srpm', 'end': '2016-01-19 15:16:30.308282', 'stdout': >> 'Downloading libvirt-1.3.1.tar.gz\n\r >> 0.0%\r >> 100.0%\r######################################################################## 100.0%', 'changed': True, 'start': >> '2016-01-19 15:16:28.758321', 'delta': '0:00:01.549961', 'stderr': "Cloning into 'libvirt'...\nNote: checking out >> 'acef5efd6153aa8f9ea760f468333e65c9b46a4e'.\n\nYou are in 'detached HEAD' state. You can look around, make >> experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any >> branches by performing another checkout.\n\nIf you want to create a new branch to retain commits you create, you may\ndo >> so (now or later) by using -b with the checkout command again. Example:\n\n git checkout -b <new-branch-name>\n\nHEAD >> is now at acef5ef... import_srpm\nerror: line 1800: Trigger fired by the same package is already defined in spec file: >> %post daemon-config-network\n\nerror: query of specfile /tmp/build_package_repo/libvirt/libvirt.spec failed, can't >> parse\n\nCould not execute srpm: Could not get n-v-r-e from '\\n\\n'", 'rc': 1, 'invocation': {'module_name': 'shell', >> 'module_complex_args': {}, 'module_args': u'rm -rf /tmp/build_package_repo && mkdir /tmp/build_package_repo && cd >> /tmp/build_package_repo && git clone http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libvir… && >> cd libvirt && git checkout acef5efd6153aa8f9ea760f468333e65c9b46a4e && fedpkg-copr --dist el6 srpm'}, 'warnings': >> ['Consider using file module with state=absent rather than running rm']}}} >> [2016-01-19 15:16:31,759][ INFO][PID:3241] End Build: BuildJob<id: 154509, owner: jmliger, project: virt6-upstream, git >> branch: el6, git_hash: acef5efd6153aa8f9ea760f468333e65c9b46a4e, status: 3 > >> >> https://copr.fedoraproject.org/coprs/jmliger/virt6-upstream/builds/ >> >> Regards, >> Jean-Marc LIGER >> >> >> _______________________________________________ >> copr-devel mailing list >> copr-devel(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/admin/lists/copr-devel@lists.fedorahosted.org > It is some problem with your spec file. > You can reproduce it by installing fedpkg-copr from our Copr project and > git clone http://copr-dist-git.fedorainfracloud.org/git/jmliger/virt6-upstream/libvir… > cd libvirt > git checkout acef5efd6153aa8f9ea760f468333e65c9b46a4e > fedpkg-copr -vvv --dist el6 srpm > > Which will fails on: > > rpm --define '_sourcedir /tmp/libvirt' --define '_specdir /tmp/libvirt' --define '_builddir /tmp/libvirt' --define > '_srcrpmdir /tmp/libvirt' --define '_rpmdir /tmp/libvirt' --define 'dist .el6' --define 'rhel 6' --eval '%undefine > fedora' --define 'el6 1' --eval '%undefine fc23' -q --qf "%{NAME} %{EPOCH} %{VERSION} %{RELEASE}??" --specfile > /tmp/libvirt/libvirt.spec > > error: line 1800: Trigger fired by the same package is already defined in spec file: %post daemon-config-network > error: query of specfile /tmp/libvirt/libvirt.spec failed, can't parse > > And your spec file is so complex that I have no idea why it is failing. You may ask on RPM mailing list. > Thanks for your reply, I'm addressing this problem to the libvirt list.

1 1

[libvirt] [PATCH V3 0/2] libxl: support assignment VF to guest from a pool of SRIOV VFs
by Chunyan Liu 11 Mar '16

11 Mar '16

This patch series is to support assigning VF to guest from a pool of SRIOV VFs in libxl driver, detailed usage can be referred to: http://wiki.libvirt.org/page/Networking#Assignment_from_a_pool_of_SRIOV_VFs… Chunyan Liu (2): libxl_conf: reuse virDomainNetGetActualtype in libxlMakeNicList libxl: support assignment from a pool of SRIOV VFs src/libxl/libxl_conf.c | 3 ++- src/libxl/libxl_domain.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ src/libxl/libxl_driver.c | 12 ++++++++++++ tests/Makefile.am | 3 +++ 4 files changed, 63 insertions(+), 1 deletion(-) -- 2.1.4

3 5

[libvirt] [PATCH 0/2] RFC: qemu: aarch64 virtio-pci work
by Cole Robinson 10 Mar '16

10 Mar '16

These patches apply on top of the series I just posted: [PATCH 0/9] tests: qemu: unconditionally enable QEMU_CAPS_DEVICE https://www.redhat.com/archives/libvir-list/2016-January/msg01233.html These specific changers were discussed here: https://www.redhat.com/archives/libvir-list/2015-December/msg00217.html We need a way for apps to tell libvirt 'use virtio-pci not virtio-mmio' for aarch64 -M virt. We can't really make use this by default yet since most OS don't actually support it. So we decided the best course of interaction is to allow users to pass a manual pci controller, and libvirt will interpret that to mean it's okay to use virtio-pci. Patch #1 undoes the current behavior of unconditionally adding a q35 style PCIe controller setup for mach-virt that supports it. In the future we will probably re-enable something like this, but maybe not for a year or so until the bits proliferate to distros. Patch #2 tries to implement the manual pci controller bit. Unfortunately it's not that easy get the ideal XML to work, so this isn't ready for committing. See the commit message for more details Cole Robinson (2): qemu: aarch64: Don't add PCIe controller by default HACK: qemu: aarch64: Use virtio-pci if user specifies PCI controller src/qemu/qemu_command.c | 34 ++++++++---- src/qemu/qemu_domain.c | 4 -- ...l2argv-aarch64-pci-manual-nocontroller-fail.xml | 43 ++++++++++++++++ .../qemuxml2argv-aarch64-virtio-pci-default.args | 2 - ...l2argv-aarch64-virtio-pci-manual-addresses.args | 2 - ...ml2argv-aarch64-virtio-pci-manual-addresses.xml | 1 + ...2argv-aarch64-virtio-pci-manual-controller.args | 36 +++++++++++++ ...l2argv-aarch64-virtio-pci-manual-controller.xml | 50 ++++++++++++++++++ tests/qemuxml2argvtest.c | 22 ++++++-- .../qemuxml2xmlout-aarch64-virtio-pci-default.xml | 10 ---- ...2xmlout-aarch64-virtio-pci-manual-addresses.xml | 11 +--- ...xmlout-aarch64-virtio-pci-manual-controller.xml | 60 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 6 +++ 13 files changed, 239 insertions(+), 42 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-pci-manual-nocontroller-fail.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-controller.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-aarch64-virtio-pci-manual-controller.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-aarch64-virtio-pci-manual-controller.xml -- 2.5.0

4 15

[libvirt] [PATCH v4 0/2] qemu: add debug-threads support
by Marc-André Lureau 10 Mar '16

10 Mar '16

QEMU (somewhere around 2.0) added a new sub-option to the -name flag -name debug-threads=on This causes the naming of individual QEMU threads to be helpful; e.g. 'CPU/KVM 0' or 'migration' these show up in top once the H key is pressed, and also show up in a core dump, making it easy to figure out which thread is which. The following 2 patches add a capability check and enable debug-threads if supported. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1140121 cheers v3->v4: - simplify a bit command generation - added a test v2->v3: - move -name command generation in seperate function - fix syntax-check - fix leak v1->v2: - drop the configuration, enable debug-thread automatically Marc-André Lureau (2): qemu: check for debug-threads capability qemu: enable debug threads src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 34 +++++++++++++++++----- tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + .../qemuxml2argv-debug-threads.args | 22 ++++++++++++++ .../qemuxml2argv-debug-threads.xml | 34 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 2 ++ 10 files changed, 91 insertions(+), 8 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-debug-threads.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-debug-threads.xml -- 2.5.0

3 4

[libvirt] [PATCH v3 0/2] qemu: add debug-threads support
by Marc-André Lureau 10 Mar '16

10 Mar '16

QEMU (somewhere around 2.0) added a new sub-option to the -name flag -name debug-threads=on This causes the naming of individual QEMU threads to be helpful; e.g. 'CPU/KVM 0' or 'migration' these show up in top once the H key is pressed, and also show up in a core dump, making it easy to figure out which thread is which. The following 2 patches add a capability check and enable debug-threads if supported. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1140121 cheers v2->v3: - move -name command generation in seperate function - fix syntax-check - fix leak v1->v2: - drop the configuration, enable debug-thread automatically Marc-André Lureau (2): qemu: check for debug-threads capability qemu: enable debug threads src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 40 ++++++++++++++++++++++------ tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + 7 files changed, 39 insertions(+), 8 deletions(-) -- 2.5.0

3 5