January 2017 - Devel - libvirt List Archives

[libvirt] [PATCH] news: document events changes and lxc fix
by Daniel P. Berrange 12 Jan '17

12 Jan '17

Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/news.xml | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 300e553..23ff40f 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -14,6 +14,25 @@ <section title="New features"> <change> <summary> + Domain events for metadata content changes + </summary> + <description> + The domain events framework has a new event ID that can + be used to get notifications when domain metadata content + changes. + </description> + </change> + <change> + <summary> + Event notifications for the secret object + </summary> + <description> + The secret object now supports event notifications, covering + lifcycle changes and secret value changes. + </description> + </change> + <change> + <summary> New localPtr attribute for "ip" element in network XML </summary> </change> @@ -67,6 +86,17 @@ <section title="Improvements"> <change> <summary> + lxc: fix accidental killing of containers during libvirtd restart + </summary> + <description> + The libvirt_lxc process was previously not moved into the + container scope. As a result, if systemd reloads its config + after a container is started, when libvirtd is later restarted + it will accidentally kill the containers. + </description> + </change> + <change> + <summary> perf: Add more perf statistics </summary> <description> -- 2.9.3

2 1

[libvirt] [PATCH] docs: Add pit timer policy change description to news.xml
by Maxim Nestratov 12 Jan '17

12 Jan '17

Add bug fix description of appying correct pit timer policy. --- docs/news.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index e341ba2..d616ebd 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -184,6 +184,17 @@ libvirt can recognize. </description> </change> + <change> + <summary> + qemu: Fix pit timer tick policy + </summary> + <description> + By a mistake, when <code>policy=delay</code> pit timer tick policy + was specified, <code>policy=discard</code> was used instead. Now it + is possible to use both <code>discard</code> and <code>delay</code> + policies correctly. + </description> + </change> </section> </release> <release version="v2.5.0" date="2016-12-04"> -- 2.4.11

2 1

[libvirt] [V3] RFC for support cache tune in libvirt
by Qiao, Liyong 12 Jan '17

12 Jan '17

Add support for cache allocation. Thanks Martin for the previous version comments, this is the v3 version for RFC , I’v have some PoC code [2]. The follow changes are partly finished by the PoC. #Propose Changes ## virsh command line 1. Extend output of nodeinfo, to expose L3 cache size for Level 3 (last level cache size). This will expose how many cache on a host which can be used. root@s2600wt:~/linux# virsh nodeinfo | grep L3 L3 cache size: 56320 KiB 2. Extend capabilities outputs. virsh capabilities | grep resctrl <cpu> ... <resctrl name='L3' unit='KiB' cache_size='56320' cache_unit='2816'/> </cpu> This will tell that the host have enabled resctrl(which you can find it in /sys/fs/resctrl), And it supports to allocate 'L3' type cache, total 'L3' cache size is 56320 KiB, and the minimum unit size of 'L3' cache is 2816 KiB. P.S. L3 cache size unit is the minum l3 cache unit can be allocated. It's hardware related and can not be changed. 3. Add new virsh command 'nodecachestats': This API is to expose vary cache resouce left on each hardware (cpu socket). It will be formated as: <resource_type>.<resource_id>: left size KiB for example I have a 2 socket cpus host, and I'v enabled cat_l3 feature only root@s2600wt:~/linux# virsh nodecachestats L3.0 : 56320 KiB L3.1 : 56320 KiB P.S. resource_type can be L3, L3DATA, L3CODE, L2 for now. 4. Add new interface to manage how many cache can be allociated for a domain root@s2600wt:~/linux# virsh cachetune kvm02 --l3.count 2 root@s2600wt:~/linux# virsh cachetune kvm02 l3.count : 2 This will allocate 2 units(2816 * 2) l3 cache for domain kvm02 ## Domain XML changes Cache Tuneing <domain> ... <cachetune> <l3_cache_count>2</l3_cache_count> </cachetune> ... </domain> ## Restriction for using cache tune on multiple sockets' host. The l3 cache is per socket resource, kernel need to konw about what's affinity looks like, so for a VM which running on a mulitple socket's host, it should have NUMA setting or vcpuset pin setting. Or cache tune will fail. [1] kernel support https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/arch/x86/kern… [2] libvirt PoC(not finished yet) https://github.com/taget/libvirt/commits/cat_new Best Regards Eli Qiao(乔立勇）OpenStack Core team OTC Intel. --

4 13

[libvirt] Query regarding sharing of vcpu's (cpu alloc ratio 1.0) between VM's
by BharaniKumar Gedela 12 Jan '17

12 Jan '17

HI, I have a Q about sharing a vcpu across Vm's (cpu alloc ratio 1.0 and HT not enabled)? I have a Use case where a VM needs vcpu's and one of the vcpu is dedicated to the VM for some traffic processing. We want the other vcpu which is used for control processing and can be shared with a similar VM's control processing. Is this possible and support in openstack/libvirt/KVM? If so could you please advice how to test it? Regards, Bharani..

2 1

[libvirt] Regarding Migration Statistics
by Anubhav Guleria 12 Jan '17

12 Jan '17

Greetings, I am writing a code using libvirt API to migrate VM between two physical hosts *(QEMU/KVM) , *say some *n *number of times. *1)* I am using right now* virDomainPtr virDomainMigrate (.......) *and to calculate the total migration time I am using something like this: *clock_gettime(CLOCK_MONOTONIC_RAW,&begin); * *migrate*(domainToMigrate,nodeToMigrate); *clock_gettime(CLOCK_MONOTONIC_RAW,&end);* *Total Migration Time = end.tv_sec-begin.tv_sec* Is this correct way to calculate total migration time. And is there some way to calculate the downtime (not how to set it)? *2) *I am interested in identifying in particular other statistics of migration like : *Number of iterations in Pre Copy*, *Memory transferred in each iteration* etc. I was going through the API and found* virDomainJobInfo <http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainJobInfo> and virDomainGetJobStats <http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainGetJobStats> *functions.But how to use them is not very clear. Can anyone point me to right place to achieve this objective? Thanks in advance. And sorry if that was too silly to ask. Anubhav

2 1

[libvirt] OpenStack/libvirt CAT interface
by Marcelo Tosatti 11 Jan '17

11 Jan '17

There have been queries about the OpenStack interface for CAT: http://bugzilla.redhat.com/show_bug.cgi?id=1299678 Comment 2 says: Sahid Ferdjaoui 2016-01-19 10:58:48 EST A spec will have to be addressed, after a first look this feature needs some work in several components of Nova to maintain/schedule/consume host's cache. I can work on that spec and implementation it when libvirt will provides information about cache and feature to use it for guests. I could add a comment about parameters to resctrltool, but since this depends on the libvirt interface, it would be good to know what the libvirt interface exposes first. I believe it should be essentially similar to OpenStack's "reserved_host_memory_mb": Set the reserved_host_memory_mb to reserve RAM for host processes. For the purposes of testing I am going to use the default of 512 MB: reserved_host_memory_mb=512 But rather use: rdt_cat_cache_reservation=type=code/data/both,size=10mb,cacheid=2; type=code/data/both,size=2mb,cacheid=1;... (per-vcpu). Where cache-id is optional. What is cache-id (from Documentation/x86/intel_rdt_ui.txt on recent kernel sources): Cache IDs --------- On current generation systems there is one L3 cache per socket and L2 caches are generally just shared by the hyperthreads on a core, but this isn't an architectural requirement. We could have multiple separate L3 caches on a socket, multiple cores could share an L2 cache. So instead of using "socket" or "core" to define the set of logical cpus sharing a resource we use a "Cache ID". At a given cache level this will be a unique number across the whole system (but it isn't guaranteed to be a contiguous sequence, there may be gaps). To find the ID for each logical CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id WHAT THE USER NEEDS TO SPECIFY FOR VIRTUALIZATION (KVM-RT) ========================================================== For virtualization the following scenario is desired, on a given socket: * VM-A with VCPUs VM-A.vcpu-1, VM-A.vcpu-2. * VM-B with VCPUs VM-B.vcpu-1, VM-B.vcpu-2. With one realtime workload on each vcpu-2. Assume VM-A.vcpu-2 on pcpu 3. Assume VM-B.vcpu-2 on pcpu 5. Assume pcpus 0-5 on cacheid 0. We want VM-A.vcpu-2 to have a certain region of cache reserved, and VM-B.vcpu-2 as well. vcpu-1 for both VMs can use the default group (that is not have reserved L3 cache). This translates to the following resctrltool-style reservations: res.vm-a.vcpu-2 type=both,size=VM-A-RESSIZE,cache-id=0 res.vm-b.vcpu-2 type=both,size=VM-B-RESSIZE,cache-id=0 Which translate to the following in resctrlfs: res.vm-a.vcpu-2 type=both,size=VM-A-RESSIZE,cache-id=0 type=both,size=default-size,cache-id=1 ... res.vm-b.vcpu-2 type=both,size=VM-B-RESSIZE,cache-id=0 type=both,size=default-size,cache-id=1 ... Which is what we want, since the VCPUs are pinned. res.vm-a.vcpu-1 and res.vm-b.vcpu-1 don't need to be assigned to any reservation, which means they'll remain on the default group. RESTRICTIONS TO THE SYNTAX ABOVE ================================ Rules for the parameters: * type=code must be paired with type=data entry. ABOUT THE LIST INTERFACE ======================== About an interface for listing the reservations of the system to OpenStack. I think that what OpenStack needs is to check, before starting a guest on a given host, that there is sufficient space available for the reservation. To do that, it can: 1) resctrltool list (the end of the output mentions how much free space available there is), or via resctrlfs directly (have to lock the filesystem, read each directory, AND each schemata, and count number of zero bits). 2) Via libvirt Should fix resctrltool/API to list amount of contiguous free space BTW.

3 5

[libvirt] RFC: Use __attribute__ ((cleanup) in libvirt ?
by Daniel P. Berrange 11 Jan '17

11 Jan '17

For those who don't already know, GCC and CLang both implement a C language extension that enables automatic free'ing of resources when variables go out of scope. This is done by annotating the variable with the "cleanup" attribute, pointing to a function the compiler will wire up a call to when unwinding the stack. Since the annotation points to an arbitrary user defined function, you're not limited to simple free() like semantics. The cleanup function could unlock a mutex, or decrement a reference count, etc This annotation is used extensively by systemd, and libguestfs, amongst other projects. This obviously doesn't bring full garbage collection to C, but it does enable the code to be simplified. By removing the need to put in many free() (or equiv) calls to cleanup state, the "interesting" logic in the code stands out more, not being obscured by cleanup calls and goto jumps. I'm wondering what people think of making use of this in libvirt ? To my mind the only real reason to *not* use it, would be to maintain code portability to non-GCC/non-CLang compilers. OS-X, *BSD and *Linux all use GCC or CLang or both, so its a non-issue there. So the only place this could cause pain is people building libvirt on Win32, who are using the Microsoft compilers instead og GCC. IMHO, it is perfectly valid for us to declare that MSVC is unsupported with Libvirt and users must use GCC to build on Windows, either natively via cygwin, or cross-build from Linux hosts. As an example of what it would involve... This commit enables the basic helper macros in libguestfs: https://github.com/libguestfs/libguestfs/commit/98b64650c852ccc9a8eef8b9691… These commits make use of them https://github.com/libguestfs/libguestfs/commit/61162bdce1a00a921a47eb3e788… https://github.com/libguestfs/libguestfs/commit/5a3da366268825b26b470cde356… https://github.com/libguestfs/libguestfs/commit/791ad3e9e600ef528e3e5a8d50b… Finally, I'm absolutely *not* volunteering to actually implement this idea myself, as I don't have the free time. I just want to raise it as a discussion item, and if we agree its something we'd do, then we can make it a GSoC idea, or let any other interested person hack on it at will. There's no need for a "big bang" convert everything approach, we can do it incrementally. 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/ :|

7 14

[libvirt] Question about hypervisor <features> that are not tristate
by Jim Fehlig 11 Jan '17

11 Jan '17

Happy new year! Nearly a year ago I reported an issue with the <hap> hypervisor feature on Xen [1] and am now seeing a similar issue with the <pae> feature. Setting the default value of pae changed between xend and libxl. When not specified, xend would enable pae for HVM domains. Clients such as xm and the old libvirt driver did not have to explicitly enable it. In libxl, the pae field within libxl_domain_build_info is initialized to 0. Clients must enable pae, and indeed xl will do so if pae=1 is not specified in the xl.cfg. The xend behavior prevents libvirt from disabling pae, whereas the libxl behvior causes a guest ABI change (config that worked with libvirt+xend doesn't with libvirt+libxl). The libxl behavior also forces management software (e.g. OpenStack nova) to add <pae> where it wasn't needed before. To solve this problem for <hap>, it was changed it to a tristate [2], allowing it to be turned off with explicit <hap state='off'/>, and on if not specified or <hap/> or <hap state='on'/>. Should <pae> (and the remaining hypervisor features that are not tristate) be converted to tristate similar to <hap>? Alternatively, I could simply set pae=1 for all HVM domains in the libxl driver. Like the old libvirt+xend behavior it couldn't be turned off, but I don't think there is a practical use-case to do so. At least no one has complained over all the years of libvirt+xend use. Regards, Jim [1] https://www.redhat.com/archives/libvir-list/2016-February/msg00197.html [2] https://www.redhat.com/archives/libvir-list/2016-March/msg00001.html

4 6

[libvirt] [PATCH] news: Reflect hugepages patch
by Michal Privoznik 11 Jan '17

11 Jan '17

In f55afd8 I've made libvirt to construct hugepage path on per-domain basis. However, this change was not reflected in the NEWS file. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- I'd push this right away, but I rather wait for our NEWS police^Wvolunteer to check it. docs/news.xml | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index e341ba248..f6f17d55f 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -184,6 +184,17 @@ libvirt can recognize. </description> </change> + <change> + <summary> + qemu: Create hugepage path on per domain basis + </summary> + <description> + Historically, all hugepage enabled domains shared the same path under + hugetlbfs. This left libvirt unable to correctly set security labels + on it. With this release, however, each domain is put into a + separate path which is also correctly labeled. + </description> + </change> </section> </release> <release version="v2.5.0" date="2016-12-04"> -- 2.11.0

2 1

[libvirt] [PATCH] qemuDomainSetupAllInputs: Update debug message
by Michal Privoznik 11 Jan '17

11 Jan '17

Due to a copy-paste error, the debug message reads: Setting up disks It should have been: Setting up inputs. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial rule. src/qemu/qemu_domain.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index b26c02bda..473d0c1a2 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -7275,14 +7275,14 @@ qemuDomainSetupAllInputs(virQEMUDriverPtr driver, { size_t i; - VIR_DEBUG("Setting up disks"); + VIR_DEBUG("Setting up inputs"); for (i = 0; i < vm->def->ninputs; i++) { if (qemuDomainSetupInput(driver, vm->def->inputs[i], devPath) < 0) return -1; } - VIR_DEBUG("Setup all disks"); + VIR_DEBUG("Setup all inputs"); return 0; } -- 2.11.0

1 0