- Devel - libvirt List Archives

[libvirt] ideas on virDomainListBlockStats for allocation numbers
by Eric Blake 24 Nov '14

24 Nov '14

Based on Dan's recommendation [1], I'm looking at enhancing virDomainListBlockStats to report the allocation numbers of a backing file during a virDomainBlockCommit operation. Getting the information from qemu is not difficult, but the question is how should it be represented to the end user. See below for my ideas, and I'm open to feedback. [1] https://www.redhat.com/archives/libvir-list/2014-November/msg00604.html Some background - highest allocation is mainly applicable to using a qcow2 format on top of a raw block device (that's the only time that libvirt reports a different number based on querying qemu, other file formats just go off of stat information), so even setting this up to test can be interesting. Also, while qemu reports wr_highest_offset during 'query-blockstats', a disk has to actually have write activity performed during that given qemu process before the offset will be accurate. It took me a while to figure this out; when I set up a dummy guest with no OS (and therefore no writes), the offset being reported was 0 even when I had used qemu-io to poke data into the file prior to starting qemu. I finally figured out that metadata writes also count as part of the highest offset visited; so using 'blockdev-snapshot-internal-sync' followed by 'blockdev-snapshot-delete-internal-sync' is sufficient to cause qemu to write metadata and therefore reveal the highest offset. So I set up a playground to test things, where I first created two 1G partitions, then use this script to re-create a guest each time I want to reset things: ====== #!/bin/sh cd /tmp rm -f wrapper.qcow2 virsh destroy testvm2 2>/dev/null qemu-img create -f qcow2 /dev/sda6 $((750*1024*1024)) qemu-img create -f qcow2 /dev/sda6 $((1250*1024*1024)) virsh create /dev/stdin <<EOF <domain type='kvm'> <name>testvm2</name> <memory unit='MiB'>256</memory> <vcpu>1</vcpu> <os> <type arch='x86_64'>hvm</type> </os> <devices> <disk type='block' device='disk'> <driver name='qemu' type='qcow2'/> <source dev='/dev/sda6'/> <target dev='vda' bus='virtio'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='qcow2'/> <source dev='/dev/sda7'/> <target dev='vdb' bus='virtio'/> </disk> <graphics type='vnc'/> </devices> </domain> EOF virsh qemu-monitor-command testvm2 \ '{"execute":"blockdev-snapshot-internal-sync",' \ '"arguments":{"device":"drive-virtio-disk0", "name":"snap1"}}' virsh qemu-monitor-command testvm2 \ '{"execute":"blockdev-snapshot-delete-internal-sync",' \ '"arguments":{"device":"drive-virtio-disk0", "name":"snap1"}}' virsh domblkinfo testvm2 vda virsh domblkinfo testvm2 vdb ======== which shows this for my starting point: # virsh domblkinfo testvm2 vda Capacity: 786432000 Allocation: 458752 Physical: 1073741824 # virsh domblkinfo testvm2 vdb Capacity: 1310720000 Allocation: 0 Physical: 1073741824 After that, I can create external snapshots: # virsh snapshot-create-as testvm2 --disk-only --no-metadata \ --diskspec vda,file=/tmp/wrapper.qcow2 --diskspec vdb,snapshot=no at which point dumpxml shows this subset: <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/tmp/wrapper.qcow2'/> <backingStore type='block' index='1'> <format type='qcow2'/> <source dev='/dev/sda6'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> Next, I can play with blockcommit, where a qemu-monitor-command on 'query-blockstats' will show me the growing allocation when the backing file is being written during the commit. The other useful output is the new virDomainListBlockStats: # virsh domstats --block testvm2Domain: 'testvm2' block.count=2 block.0.name=vda block.0.rd.reqs=1 block.0.rd.bytes=512 block.0.rd.times=31635 block.0.wr.reqs=0 block.0.wr.bytes=0 block.0.wr.times=0 block.0.fl.reqs=0 block.0.fl.times=0 block.0.allocation=458752 block.0.capacity=786432000 block.1.name=vdb block.1.rd.reqs=0 block.1.rd.bytes=0 block.1.rd.times=0 block.1.wr.reqs=0 block.1.wr.bytes=0 block.1.wr.times=0 block.1.fl.reqs=0 block.1.fl.times=0 block.1.allocation=0 block.1.capacity=1310720000 The problem is that once we have a domain with more than one <disk>, and where one or all disks have more than one <backingStore>, then how should virDomainListBlockStats represent that? One idea I have is to just expose a block.count equal to the total number of devices I'm about to report on, where the array can be larger than the number of disks, and using the name field to correlate back to dumpxml layout: block.count=3 block.0.name=vda # information on wrapper.qcow2 ... block.1.name=vda[1] # information on backingStore index 1 of vda block.1.rd.reqs=0 #+ that is, on /dev/sda6 ... block.2.name=vdb # information on /dev/sda7 ... It may make things easier if I also add a block.n.path that lists the file name of the block being described (might get tricky with NBD/gluster/sheepdog network disks). Also, I'm thinking of adding block.n.physical to match the older virDomainGetBlockInfo() information. Another possible layout is to mirror the nesting of XML backingChain. Something like: block.count=2 block.0.name=vda block.0.backing=1 block.0.allocation=... # information on /tmp/wrapper.qcow2 ... block.0.0.allocation=... # information on /dev/sda6 ... block.1.name=vdb block.1.backing=0 block.1.allocation=... # information on /dev/sda7 But there, we run into a possible problem: virTypedParameter has a finite length for field names, so we can only cover a finite depth of backing chain before we run out of space and can't report on the full chain. Any other ideas for the best way to lay this out, and for how to make it as easy as possible for client applications to correlate information on allocation back to the appropriate block device in the chain? I also wonder if adding more information to the existing --block flag for stats is okay, or whether it is better to add yet another statistics flag grouping that must be requested to turn on information about backing files. Technically, it's still block-related statistics, but as we have already got released libvirt that still has a 1:1 block.n mapping to <disk> elements, using a new flag would make it easier to learn if libvirt is new enough to support information on backing chains, all without confusing existing clients that aren't expecting backing chain stats. This question needs answering regardless of which layout we choose above for representing backing chain stats. Thoughts welcome. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

3 3

[libvirt] strange behavior when using iotune
by Vasiliy Tolstov 24 Nov '14

24 Nov '14

Hi. I'm try to shape disk via total_iops_sec in libvirt libvirt 1.2.10 qemu 2.0.0 Firstly when i'm run vm with predefined <total_iops_sec>5000</total_iops_sec> i have around 11000 iops (dd if=/dev/sda bs=512K of=/dev/null) After that i'm try to set via virsh --total_iops_sec 10 to want to minimize io, but nothing changed. After that i'm reboot vm with <total_iops_sec>10</total_iops_sec> and get very slow io, but this expected. But libvirt says that i have is around 600 iops. My questions is - why i can't change total_iops_sec in run-time, and why entered values does not equal values getting from libvirt ? Thanks for any suggestions and any help. -- Vasiliy Tolstov, e-mail: v.tolstov(a)selfip.ru jabber: vase(a)selfip.ru

2 4

[libvirt] [PATCH v3 0/5] Guest filesystem information API
by Tomoki Sekiyama 24 Nov '14

24 Nov '14

Hi, This is v3 of patchset to add virDomainGetFSInfo API. * changes in v2->v3: -[all] squashed fixup patches by John Ferlan (thanks!) -[all] added 'ndevAlias' filed instead of NULL-termination of devAlias -[all] renamed 'type' field to 'fstype' to avoid wireshark genxdrstub.pl error -[2/5] use @acl: domain:fs_freeze (v2: http://www.redhat.com/archives/libvir-list/2014-November/msg00559.html ) * changes in v1->v2: -[all] removed redundant NULL element at the last of returned info array -[3/5] make error messages in qemu_agent.c consistent with other commands -[4/5] added a test case for 2 items in info->devAliases -[5/5] added a pod document for virsh domfsinfo command (v1: http://www.redhat.com/archives/libvir-list/2014-October/msg00001.html ) * summary This series implements a new virDomainGetFSInfo API, that returns a list of mounted filesystems information in the guest, collected via the guest agent. The returned info contains mountpoints and disk device alias named in libvirt, so we can know which mountpoints should be frozen by virDomainFSFreeze to take snapshots of a part of disks. --- Tomoki Sekiyama (5): Implement public API for virDomainGetFSInfo remote: Implement the remote protocol for virDomainGetFSInfo qemu: Implement the qemu driver for virDomainGetFSInfo qemu: add test for qemuAgentGetFSInfo virsh: expose virDomainGetFSInfo daemon/remote.c | 113 +++++++++++++++++++ include/libvirt/libvirt-domain.h | 22 ++++ src/conf/domain_conf.c | 71 ++++++++++++ src/conf/domain_conf.h | 6 + src/driver-hypervisor.h | 6 + src/libvirt.c | 68 ++++++++++++ src/libvirt_private.syms | 1 src/libvirt_public.syms | 6 + src/qemu/qemu_agent.c | 176 ++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 2 src/qemu/qemu_driver.c | 48 ++++++++ src/remote/remote_driver.c | 93 ++++++++++++++++ src/remote/remote_protocol.x | 32 +++++ src/remote_protocol-structs | 21 ++++ src/rpc/gendispatch.pl | 1 tests/Makefile.am | 1 tests/qemuagentdata/qemuagent-fsinfo.xml | 39 +++++++ tests/qemuagenttest.c | 144 +++++++++++++++++++++++++ tools/virsh-domain.c | 70 ++++++++++++ tools/virsh.pod | 9 ++ 20 files changed, 928 insertions(+), 1 deletion(-) create mode 100644 tests/qemuagentdata/qemuagent-fsinfo.xml -- Tomoki Sekiyama

2 6

[libvirt] [PATCHv2 0/5] Add agent lifecycle event
by Peter Krempa 24 Nov '14

24 Nov '14

I'll post the promised channel state event later in a separate series. Peter Krempa (5): qemu: chardev: Extract more information about character devices qemu: process: Refresh virtio channel guest state when connecting to mon event: Add guest agent lifecycle event examples: Add support for the guest agent lifecycle event qemu: Emit the guest agent lifecycle event daemon/remote.c | 36 +++++++++++++++ examples/object-events/event-test.c | 67 ++++++++++++++++++++++++++- include/libvirt/libvirt-domain.h | 41 +++++++++++++++++ src/conf/domain_event.c | 78 ++++++++++++++++++++++++++++++++ src/conf/domain_event.h | 9 ++++ src/libvirt_private.syms | 2 + src/qemu/qemu_driver.c | 6 +++ src/qemu/qemu_monitor.c | 13 +++++- src/qemu/qemu_monitor.h | 6 +++ src/qemu/qemu_monitor_json.c | 51 ++++++++++++++------- src/qemu/qemu_monitor_text.c | 17 ++++--- src/qemu/qemu_process.c | 90 ++++++++++++++++++++++++++++++++++--- src/remote/remote_driver.c | 31 +++++++++++++ src/remote/remote_protocol.x | 16 ++++++- src/remote_protocol-structs | 7 +++ tests/qemumonitorjsontest.c | 41 ++++++++++++++--- tools/virsh-domain.c | 39 ++++++++++++++++ 17 files changed, 513 insertions(+), 37 deletions(-) -- 2.1.0

2 13

[libvirt] Plan for next releases
by Daniel Veillard 24 Nov '14

24 Nov '14

We are getting close to the end of the month and in theory we should enter freeze around next week if we want to release 1.2.11 early Dec. However: - we have 'only' 150 commits since 1.2.10 - December is usually heavilly truncated due to Xmas/etc... vacations - I'm actually on vacations next week and while I could try to push the release candidates while on the road it's not ideal What about pushing the 1.2.11 release to around 15th December (maybe a bit earlier) then push the following release to the last week of January, just before FOSDEM so it's available then, and also because Feb is really short. Opinions ? I'm tempted to do that '2 release in 3 months' trick, we did that in the past for end of year, Any objections ? thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

2 2

[libvirt] Error starting domain: internal error: missing IFLA_VF_INFO in netlink response
by Hong-Hua.Yin＠freescale.com 24 Nov '14

24 Nov '14

Hi, We try PCI Passthrough of host network devices on PPC platform. http://wiki.libvirt.org/page/Networking#Assignment_with_.3Cinterface_type.3… But we got a similar issue as below that reported on RedHat before: https://bugzilla.redhat.com/show_bug.cgi?id=1040626 With <hostdev>, it could start VM successfully. <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x01' slot='0x00' function='0x4'/> </source> </hostdev> Logged into VM and checked for VF using lspci root@model : qemu ppce500:~# lspci 00:00.0 PCI bridge: Freescale Semiconductor Inc MPC8533E 00:02.0 Power PC: Freescale Semiconductor Inc Device 0000 (rev 20) 00:03.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon But it will fail if using <interface type="hostdev">: <interface type="hostdev" managed="yes"> <mac address="00:e0:0c:00:20:01"/> <source> <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x4"/> </source> </interface> # virsh create vf.xml 2014-11-24 11:08:31.390+0000: 3556: info : libvirt version: 1.2.2 2014-11-24 11:08:31.390+0000: 3556: debug : virLogParseOutputs:1378 : outputs=1:file:virsh.log error: Failed to create domain from vf.xml error: internal error: missing IFLA_VF_INFO in netlink response Exactly We're using max_vfs=2 and libnl-3.2.22 # ls -l /usr/lib64/libnl-3.so.200.17.0 -rwxr-xr-x 1 root root 154440 Sep 17 07:15 /usr/lib64/libnl-3.so.200.17.0 Why this issue happened on PPC? Is there anything architecture-specific support needed to add? Thanks, Olivia

1 0

[libvirt] [PATCH] spec: Automatically apply all patches with git
by Jiri Denemark 24 Nov '14

24 Nov '14

With this change, any patch declared in libvirt.spec with Patch[0-9]* is automatically applied in %prep. Unlike with the standard %patch[0-9]*, patches are applied with "git am" to avoid some unexpected results. However, as a result of this, all patches must be in the right format for "git am" to be able to apply them; they should ideally be generated from git using "git format-patch". Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 6fcaa3e..0959483 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -425,6 +425,7 @@ BuildRequires: gettext-devel BuildRequires: libtool BuildRequires: /usr/bin/pod2man %endif +BuildRequires: git BuildRequires: perl BuildRequires: python %if %{with_systemd} @@ -1198,6 +1199,41 @@ driver %prep %setup -q +# Patches have to be stored in a temporary file because RPM has +# a limit on the length of the result of any macro expansion; +# if the string is longer, it's silently cropped +%{lua: + tmp = os.tmpname(); + f = io.open(tmp, "w+"); + count = 0; + for i, p in ipairs(patches) do + f:write(p.."\n"); + count = count + 1; + end; + f:close(); + print("PATCHCOUNT="..count.."\n") + print("PATCHLIST="..tmp.."\n") +} + +git init -q +git config user.name rpm-build +git config user.email rpm-build +git config gc.auto 0 +git add . +git commit -q -a --author 'rpm-build <rpm-build>' \ + -m '%{name}-%{version} base' + +COUNT=$(grep '\.patch$' $PATCHLIST | wc -l) +if [ $COUNT -ne $PATCHCOUNT ]; then + echo "Found $COUNT patches in $PATCHLIST, expected $PATCHCOUNT" + exit 1 +fi +if [ $COUNT -gt 0 ]; then + xargs git am <$PATCHLIST || exit 1 +fi +echo "Applied $COUNT patches" +rm -f $PATCHLIST + %build %if ! %{with_xen} %define _without_xen --without-xen -- 2.1.3

3 3

[libvirt] lxcContainerResolveSymlinks failing on cascading FS
by Cedric Bosdonnat 24 Nov '14

24 Nov '14

Hi all, As an example, the following command virt-sandbox-service create --network dhcp,source=default --unitfile sshd.service mysshd -i 512 generates a container definition containing these filesystems (in the same order): <filesystem type='file' accessmode='passthrough'> <source file='/var/lib/libvirt/images/mysshd.raw'/> <target dir='/var/lib/libvirt/filesystems/mysshd'/> </filesystem> <filesystem type='bind' accessmode='passthrough'> <source dir='/var/lib/libvirt/filesystems/mysshd/var'/> <target dir='/var'/> </filesystem> Since /var/lib/libvirt/filesystems/mysshd contains nothing, the second FS needs the first one to be mounted for the source directory to exist. The problem comes with lxcContainerResolveSymlinks() being run before any file system is actually mounted. So the container can't be started and we get the following error: Failed to access '/var/lib/libvirt/filesystems/mysshd/var': No such file or directory This would work if the symlinks were resolved right before mounting the FS instead of before mounting any of them. Any strong opinion against it? -- Cedric

2 1

[libvirt] [PATCH V2 0/4] libxl migration improvements
by Jim Fehlig 21 Nov '14

21 Nov '14

V2 of https://www.redhat.com/archives/libvir-list/2014-November/msg00423.html Patch 1 has been fixed based on Michal's feedback. Patch 2 is new in V2. I mistakenly dropped it when reordering the patches for the V1 submission. Patches 3 and 4 also have some minor adjustments from V1. See individual patches for details. Jim Fehlig (4): libxl: Receive migration data in a thread libxl: acquire job in migration finish phase libxl: start domain paused on migration dst libxl: destroy domain in migration finish phase on failure src/libxl/libxl_driver.c | 17 +++++--- src/libxl/libxl_migration.c | 103 +++++++++++++++++++++++++++++++++----------- 2 files changed, 90 insertions(+), 30 deletions(-) -- 1.8.4.5

2 6

Re: [libvirt] [Xen-devel] dom0 kenrel crashes for openstack + libvirt + libxl
by Ian Campbell 21 Nov '14

21 Nov '14

On Fri, 2014-11-21 at 14:18 +0000, David Vrabel wrote: > On 21/11/14 14:05, Ian Campbell wrote: > > On Fri, 2014-11-21 at 09:28 +0000, Ian Campbell wrote: > >> I think libvirt is wrong to specify an absolute path here, IMHO by > >> default it should just specify "pygrub" and let libxl figure out the > >> correct path. Jim, what do you think? > > > > e.g. something like the following untested (but pretty obvious[0]) > > patch. > [...] > > +# define "pygrub" > > I'm going to go with pretty obviously broken. You're missing the macro > name. Doh! Indeed... Lets try that again... 8<---------- >From 9f2d8da8264b426f54b92378e9e00973694193d4 Mon Sep 17 00:00:00 2001 From: Ian Campbell <ian.campbell(a)citrix.com> Date: Fri, 21 Nov 2014 14:00:38 +0000 Subject: [PATCH] libxl: Allow libxl to find pygrub binary. Specifying an explicit path to pygrub (e.g. BINDIR "/pygrub") only works if Xen and libvirt happen to be installed to the same prefix. A more flexible approach is to simply specify "pygrub" which will cause libxl to use the correct path which it knows (since it is built with the same prefix as pygrub). This is particular problematic in the Debian packaging, since the Debian Xen package relocates pygrub into a libexec dir, however I think this change makes sense upstream. Signed-off-by: Ian Campbell <ian.campbell(a)citrix.com> --- .gnulib | 2 +- src/libxl/libxl_conf.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.gnulib b/.gnulib index 9565c3b..2d28074 160000 --- a/.gnulib +++ b/.gnulib @@ -1 +1 @@ -Subproject commit 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d +Subproject commit 2d280742a9e30088aa169f53353765d5daafe4c0 diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h index 25f77ea..d7a3971 100644 --- a/src/libxl/libxl_conf.h +++ b/src/libxl/libxl_conf.h @@ -53,7 +53,7 @@ # define LIBXL_LIB_DIR LOCALSTATEDIR "/lib/libvirt/libxl" # define LIBXL_SAVE_DIR LIBXL_LIB_DIR "/save" # define LIBXL_DUMP_DIR LIBXL_LIB_DIR "/dump" -# define LIBXL_BOOTLOADER_PATH BINDIR "/pygrub" +# define LIBXL_BOOTLOADER_PATH "pygrub" /* libxl interface for setting VCPU affinity changed in 4.5. In fact, a new * parameter has been added, representative of 'VCPU soft affinity'. If one -- 1.7.10.4

2 2