- Devel - libvirt List Archives

[libvirt] [PATCH 0/5] Use non-blacklisted family/model/stepping for Haswell CPU model
by Eduardo Habkost 12 Jan '17

12 Jan '17

A recent glibc commit[1] added a blacklist to ensure it won't use TSX on hosts that are known to have a broken TSX implementation. Our existing Haswell CPU model has a blacklisted family/model/stepping combination, so it has to be updated to make sure guests will really use TSX. This is done by patch 5/5. However, to do this safely we need to ensure the host CPU is not a blacklisted one, so we won't mislead guests by exposing known-to-be-good FMS values on a known-to-be-broken host. This is done by patch 3/5. [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=2702856bf45c82cf8e69f206… --- Cc: dgilbert(a)redhat.com Cc: fweimer(a)redhat.com Cc: carlos(a)redhat.com Cc: triegel(a)redhat.com Cc: berrange(a)redhat.com Cc: jdenemar(a)redhat.com Cc: pbonzini(a)redhat.com Eduardo Habkost (5): i386: Add explicit array size to x86_cpu_vendor_words2str() i386: host_vendor_fms() helper function i386/kvm: Blacklist TSX on known broken hosts pc: Add 2.9 machine-types i386: Change stepping of Haswell to non-blacklisted value include/hw/i386/pc.h | 6 ++++++ target/i386/cpu.h | 1 + hw/i386/pc_piix.c | 15 ++++++++++++--- hw/i386/pc_q35.c | 13 +++++++++++-- target/i386/cpu.c | 32 ++++++++++++++++++++++---------- target/i386/kvm.c | 17 +++++++++++++++++ 6 files changed, 69 insertions(+), 15 deletions(-) -- 2.11.0.259.g40922b1

4 12

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"
by Marcelo Tosatti 12 Jan '17

12 Jan '17

Hi, Comments/questions related to: https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html 1) root s2600wt:~/linux# virsh cachetune kvm02 --l3.count 2 How does allocation of code/data look like? 2) 'nodecachestats' command: 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 Does this take into account that only contiguous regions of cbm masks can be used for allocations? Also, it should return the amount of free cache on each cacheid. 3) The interface should support different sizes for different cache-ids. See the KVM-RT use case at https://www.redhat.com/archives/libvir-list/2017-January/msg00415.html "WHAT THE USER NEEDS TO SPECIFY FOR VIRTUALIZATION (KVM-RT)". 4) Usefulness of exposing minimum unit size. Rather than specify unit sizes (which forces the user to convert every time the command is executed), why not specify in kbytes and round up? <resctrl name='L3' unit='KiB' cache_size='56320' cache_unit='2816'/> As noted in item 1 of https://www.redhat.com/archives/libvir-list/2017-January/msg00494.html, "1) Convertion of kbytes (user specification) --> number of CBM bits for host.", the format where the size is stored is kbytes, so its awkward to force users and OpenStack to perform the convertion themselves (and zero benefits... nothing changes if you know the unit size). Thanks!

3 7

[libvirt] [PATCH] news: document drive addresses fix
by Marc Hartmayer 12 Jan '17

12 Jan '17

Signed-off-by: Marc Hartmayer <mhartmay(a)linux.vnet.ibm.com> --- docs/news.xml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index 8175fd0..92e39f9 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -195,6 +195,15 @@ separate path which is also correctly labeled. </description> </change> + <change> + <summary> + conf: Reject domains with duplicate drive addresses + </summary> + <description> + Reject duplicate drive addresses for disks and hostdevs at + domain definition. + </description> + </change> </section> </release> <release version="v2.5.0" date="2016-12-04"> -- 2.5.5

2 2

[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 12 Jan '17

12 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 12 Jan '17

12 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