- Devel - libvirt List Archives

[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

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

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

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

12 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

[libvirt] [PATCH for 3.0.0 0/2] Fix qemuMonitorJSONParseCPUModelProperty
by Jiri Denemark 12 Jan '17

12 Jan '17

qemuMonitorJSONParseCPUModelProperty was made a little bit to strict which could cause compatibility issues between libvirt 3.0.0 and QEMU 2.9.0 (or newer depending on when query-cpu-model-expansion is implemented for x86). Jiri Denemark (2): qemu: Don't check CPU model property key qemu: Ignore non-boolean CPU model properties src/qemu/qemu_monitor_json.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) -- 2.11.0

2 3

[libvirt] [PATCH 00/11] Adjust build/start format checking for fs, disk, and logical backends
by John Ferlan 12 Jan '17

12 Jan '17

Two of these patches (2 and 10) are followups to no-overwrite patches previously posted (I left links in the patches for reference). Essentially this series works to unify the probing code from the file system backend using blkid and the parted format reading code from the disk backend in one common set of functions. In doing so, the disk backend will now pick up the ability to use the blkid 'partitions' APIs in order to "probe" the target device for a valid/known partition format type. Additionally, the file system probe will pick up a fallback to the parted mechanism from the disk backend if the 'blkid' APIs are not built into the system. A few extra bells/whistles were added for fs pool startup to ensure that the format in the startup XML matches the format on the target disk, which is essentially the mechanism the disk backend used (although it was slightly broken). Then in order to really pile on, the overwrite logic was added to the logical pool which didn't have any such checking (both build and start). Testing was done locally using an iSCSI device and laying down different formats and seeing what would happen on various usages of the format (with --overwrite and --no-overwrite). John Ferlan (11): storage: Introduce virStorageBackendDeviceProbeEmpty storage: Fix implementation of no-overwrite for file system backend storage: Add partition type checks for BLKID probing storage: Add writelabel bool for virStorageBackendDeviceProbe storage: For FS pool check for properly formatted target volume storage: Move and rename disk backend label checking storage: Adjust disk label found to match labels storage: Clean up logical pool devices on build failure storage: Extract logical device initialize into a helper storage: Add overwrite flag checking for logical pool storage: Validate the device formats at logical startup src/libvirt_private.syms | 1 + src/storage/storage_backend.c | 396 ++++++++++++++++++++++++++++++++++ src/storage/storage_backend.h | 4 + src/storage/storage_backend_disk.c | 150 ++----------- src/storage/storage_backend_fs.c | 118 ++-------- src/storage/storage_backend_fs.h | 5 - src/storage/storage_backend_logical.c | 180 ++++++++++------ tools/virsh-pool.c | 2 +- tools/virsh.pod | 42 ++-- 9 files changed, 585 insertions(+), 313 deletions(-) -- 2.7.4

3 22

[libvirt] [PATCH v2] libxl: fix usb inputs loop error
by Cédric Bosdonnat 12 Jan '17

12 Jan '17

List indexes where mixed up in the code looping over the USB input devices. --- * v2: Increment nusbdevice if LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST is not defined. src/libxl/libxl_conf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index ac83b51c7..a24f9e052 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -479,7 +479,8 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, if (VIR_EXPAND_N(b_info->u.hvm.usbdevice_list, nusbdevice, 1) < 0) return -1; #else - if (i > 1) { + nusbdevice++; + if (nusbdevice > 1) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("libxenlight supports only one input device")); return -1; @@ -487,7 +488,7 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, #endif #ifdef LIBXL_HAVE_BUILDINFO_USBDEVICE_LIST - usbdevice = &b_info->u.hvm.usbdevice_list[i]; + usbdevice = &b_info->u.hvm.usbdevice_list[nusbdevice - 1]; #else usbdevice = &b_info->u.hvm.usbdevice; #endif -- 2.11.0

2 1