- Devel - libvirt List Archives

[libvirt] [PATCH] tools: virt-host-validate: fix KVM check on s390
by Bjoern Walk 29 Mar '16

29 Mar '16

Since kernel version 4.5, s390 has the 'sie' flag to declare its hardware virtualization support. Let's make virt-host-validate aware so this check is passed correctly. Signed-off-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- tools/virt-host-validate-qemu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/virt-host-validate-qemu.c b/tools/virt-host-validate-qemu.c index a9f6c1e..01fb24b 100644 --- a/tools/virt-host-validate-qemu.c +++ b/tools/virt-host-validate-qemu.c @@ -31,7 +31,8 @@ int virHostValidateQEMU(void) virHostMsgCheck("QEMU", "%s", ("for hardware virtualization")); if (virHostValidateHasCPUFlag("svm") || - virHostValidateHasCPUFlag("vmx")) { + virHostValidateHasCPUFlag("vmx") || + virHostValidateHasCPUFlag("sie")) { virHostMsgPass(); if (virHostValidateDeviceExists("QEMU", "/dev/kvm", VIR_HOST_VALIDATE_FAIL, -- 2.6.5

4 3

[libvirt] [PATCH 0/2] bhyve: tiny cleanup and fix
by Maxim Nestratov 29 Mar '16

29 Mar '16

Maxim Nestratov (2): bhyve: cleanup unnecessary variables bhyve: fix invalid hostsysinfo freeing src/bhyve/bhyve_driver.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) -- 2.4.3

2 5

[libvirt] [PATCH] qemu: tolerate panic device on S390
by Boris Fiuczynski 29 Mar '16

29 Mar '16

If a panic device is being defined without a model in a domain the default value is always overwritten with model ISA. An ISA bus does not exist on S390 and therefore specifying a panic device results in an unsupported configuration. Since the s390 architecture inherently provides a crash detection capability the panic device should be tolerated in the domain xml. This patch achieves the toleration by setting the model to the default value in case the architecture is S390. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> Reviewed-by: Cornelia Huck <cornelia.huck(a)de.ibm.com> --- src/qemu/qemu_domain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 9f9fae3..96561c0 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -1605,6 +1605,9 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, if (ARCH_IS_PPC64(def->os.arch) && STRPREFIX(def->os.machine, "pseries")) dev->data.panic->model = VIR_DOMAIN_PANIC_MODEL_PSERIES; + else if (ARCH_IS_S390(def->os.arch)) + /* since S390 does not support ISA use default for toleration */ + dev->data.panic->model = VIR_DOMAIN_PANIC_MODEL_DEFAULT; else dev->data.panic->model = VIR_DOMAIN_PANIC_MODEL_ISA; } -- 2.5.0

2 1

[libvirt] [PATCH] SCSI storage: Initialise the pool size parameters to zero while refreshing
by Nitesh Konkar 29 Mar '16

29 Mar '16

If the pool creation thread happens to detect the luns in the scsi target,the size parameters will be populated as part of the refresh called from storagePoolCreate(). The commit <4a85bf3e2f> added additional refresh for SCSI which should also have these values initialised to zero, otherwise the values would appear exactly double. A separate refresh would correct the values, but without an explicit pool-refresh, the allocation/capacity would appear exactly double after pool-create. --- src/storage/storage_backend_scsi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c index 670cc4d..7c7d7d0 100644 --- a/src/storage/storage_backend_scsi.c +++ b/src/storage/storage_backend_scsi.c @@ -614,6 +614,9 @@ virStoragePoolFCRefreshThread(void *opaque) */ VIR_DEBUG("Attempt FC Refresh for pool='%s' name='%s' tries='%d'", pool->def->name, fchost_name, tries); + + pool->def->allocation = pool->def->capacity = pool->def->available = 0; + if (virStoragePoolObjIsActive(pool) && virGetSCSIHostNumber(fchost_name, &host) == 0 && virStorageBackendSCSITriggerRescan(host) == 0) { -- 1.8.3.1

2 1

[libvirt] [PATCH] docs: Document NSS module
by Michal Privoznik 29 Mar '16

29 Mar '16

While we have a wiki page describing the feature [1] since the feature is distributed in our .tar.gz we ought to document it. So I went ahead, copied the wiki page and reformatted so it fits our docs coding style. 1: http://wiki.libvirt.org/page/NSS_module Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/nss.html.in | 141 +++++++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 2 files changed, 145 insertions(+) create mode 100644 docs/nss.html.in diff --git a/docs/nss.html.in b/docs/nss.html.in new file mode 100644 index 0000000..84ea8df --- /dev/null +++ b/docs/nss.html.in @@ -0,0 +1,141 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Libvirt NSS module</h1> + + <ul id="toc"></ul> + + <p> + When it comes to managing guests and executing commands inside them, logging + into guest operating system and doing the job is convenient. Users are used + to ssh in this case. Ideally: + </p> + + <code>ssh user@virtualMachine</code> + + <p> + would be nice. But depending on virtual network configuration it might not + be always possible. For instance, when using libvirt NATed network it's + dnsmasq (spawned by libvirt) who assigns IP addresses to domains. But by + default, the dnsmasq process is then not consulted when it comes to host + name translation. Users work around this problem by configuring their + libvirt network to assign static IP addresses and maintaining + <code>/etc/hosts</code> file in sync. But this puts needless burden onto + users. This is where NSS module comes handy. + </p> + + <h2><a name="Installation">Installation</a></h2> + + <p> + Installing the module is really easy: + </p> + +<pre> +# yum install libvirt-nss +</pre> + + <h2><a name="Configuration">Configuration</a></h2> + + <p> + Enabling the module is really easy. Just add <b>libvirt</b> into + <code>/etc/nsswitch.conf</code> file. For instance: + </p> + +<pre> +$ cat /etc/nsswitch.conf +# /etc/nsswitch.conf: +passwd: compat +shadow: compat +group: compat +hosts: files libvirt dns +# ... +</pre> + + <p> + So, in this specific case, whenever ssh program is looking up the host user + is trying to connect to, <b>files</b> module is consulted first (which + boils down to looking up the host name in <code>/etc/hosts</code> file), if + not found <b>libvirt</b> module is consulted then. The DNS is the last + effort then, if none of the previous modules matched the host in question. + Therefore users should consider the order in which they want the modules to + lookup given host name. + </p> + + <h2><a name="Internals">How does it work?</a></h2> + + <p> + Whenever an Unix process wants to do a host name translation + <a href="http://linux.die.net/man/3/gethostbyname"><code>gethostbyname()</code></a> + or some variant of it is called. This is a glibc function that takes a + string containing the host name, crunch it and produces a list of IP + addresses assigned to that host. Now, glibc developers made a really good + decision when implementing the internals of the function when they decided + to make the function pluggable. Since there can be several sources for the + records (e.g. <code>/etc/hosts</code> file, DNS, LDAP, etc.) it would not + make much sense to create one big implementation containing all possible + cases. What they have done instead is this pluggable mechanism. Small + plugins implementing nothing but specific technology for lookup process are + provided and the function then calls those plugins. There is just one + configuration file that instructs the lookup function in which order should + the plugins be called and which plugins should be loaded. For more info + reading <a href="https://en.wikipedia.org/wiki/Name_Service_Switch">wiki + page</a> is recommended. + </p> + + <p> + And this is point where libvirt comes in. Libvirt provides plugin for the + NSS ecosystem. For some time now libvirt keeps a list of assigned IP + addresses for libvirt networks. The NSS plugin does no more than search the + list trying to find matching record for given host name. When found, + matching IP address is returned to the caller. If not found, translation + process continues with the next plugin configured. At this point it is + important to stress the order in which plugins are called. Users should be + aware that a hostname might match in multiple plugins and right after first + match, translation process is terminated and no other plugin is consulted. + Therefore, if there are two different records for the same host name users + should carefully chose the lookup order. + </p> + + <h2><a name="Limitations">Limitations</a></h2> + + <ol> + <li>The libvirt NSS module matches only hostnames provided by guest. If + the libvirt name and one advertised by guest differs, the latter is + matched.</li> + <li>The module works only in that cases where IP addresses are assigned by + dnsmasq spawned by libvirt. Libvirt NATed networks are typical + example.</li> + </ol> + + <p> + These limitation are result of libvirt's internal implementation. While + libvirt can report IP addresses regardless of their origin, a public API + must be used to obtain those. However, for the API a connection object is + required. Doing that for every name translation request would be too + costly. Fortunately, libvirt spawns dnsmasq for NATed networks. Not only + that, it provides small executable that on each IP address space change + updates an internal list of addresses thus keeping it in sync. The NSS + module then merely consults the list trying to find the match. Users can + view the list themselves: + </p> + +<pre> +virsh net-dhcp-leases $network +</pre> + + <p> + where <code>$network</code> iterates through all running networks. So the module + does merely the same as + </p> + +<pre> +virsh domifaddr --source lease $domain +</pre> + + <p> + If there's no record for either of the aforementioned commands, it's very + likely that NSS module won't find anything and vice versa. + </p> + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 7e3746e..22e410c 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -120,6 +120,10 @@ <a href="hooks.html">Hooks</a> <span>Hooks for system specific management</span> </li> + <li> + <a href="nss.html">NSS module</a> + <span>Enable domain host name translation to IP addresses</span> + </li> </ul> </li> <li> -- 2.7.3

2 1

[libvirt] [PATCH v3 0/2] qemu: Support for QXL heads
by Martin Kletzander 29 Mar '16

29 Mar '16

v3: - rebase on top of current master in order to cleanly apply v2: - don't change heads when migrating - https://www.redhat.com/archives/libvir-list/2016-March/msg00811.html v1: - https://www.redhat.com/archives/libvir-list/2016-March/msg00410.html Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283207 Martin Kletzander (2): qemu: Check for qxl's max_outputs parameter qemu: Add support to QXL's max_outputs parameter src/qemu/qemu_capabilities.c | 4 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 8 +++ src/qemu/qemu_migration.c | 64 ++++++++++++++++++++-- .../qemuxml2argv-video-qxl-heads.args | 28 ++++++++++ .../qemuxml2argv-video-qxl-heads.xml | 47 ++++++++++++++++ tests/qemuxml2argvtest.c | 8 +++ .../qemuxml2xmlout-video-qxl-heads.xml | 47 ++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 9 files changed, 204 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-video-qxl-heads.xml -- 2.7.4

2 4

[libvirt] Publishing libvirt 'patches' JSON database?
by Kashyap Chamarthy 29 Mar '16

29 Mar '16

I'd imagine most developers on this list have their own workflows to track/apply/test patches from the mailing list. I normally just save patches in Mutt's Maildir and apply them manually to a Git branch. I recently began using the 'patches'[1] tool, that some of you on this list must be familiar with, to test arbitrary QEMU patches from the mailing list, and found it relatively easy large patch series from mailing list. I'm writing this to check if the libvirt upstream community finds it desirable to setup such a patches database. What is 'patches'? ------------------ Quoting the README[2]: "patches is a patch tracking system. It consists of two parts: a set of commands that build a database of patches from a mailing list and then a set of commands that can search that database. It supports the following features: - Tracking patch status by determining which patches are already committed, have newer versions posted, are RFC, etc. - Applying patches or pull requests with a single command. - Searching for patches using a rich query language." A quick workflow to test patches from mailing list --------------------------------------------------- FWIW, this is my rudimentary use-case. Clone the repo, and fetch the patches database (may take a few minutes): $ git clone https://github.com/stefanha/patches.git $ cd patches $ ./patches fetch http://wiki.qemu.org/patches/patches.json And, suppose, I want to test Dan's LUKS encryption support (26) patch series, I go find the message ID: $ ./patches list | grep -B5 "Support LUKS encryption" Message-id: 1456747261-22032-1-git-send-email-berrange(a)redhat.com From: Daniel P. Berrange <berrange(a)redhat.com> Date: 2016-02-29 Tags: v4 [0/26] Support LUKS encryption in block devices Trivially apply it (assuming you have a test branch): $ ./patches apply --git-dir ~/src/qemu/ \ id:1456747261-22032-1-git-send-email-berrange@redhat.com Applying: crypto: add cryptographic random byte source Applying: crypto: add support for PBKDF2 algorithm Applying: crypto: add support for generating initialization vectors Applying: crypto: add support for anti-forensic split algorithm Applying: crypto: skip testing of unsupported cipher algorithms [...] Test away! Rinse, repeat: "The `fetch` command should be run whenever you want to refresh the patch database; it will download any new patches that have arrived since the last time you did a fetch." Here's[3] the documentation to setup the patches database. [1] https://github.com/stefanha/patches/tree/stefanha-tweaks [2] https://github.com/stefanha/patches/blob/stefanha-tweaks/README.md [3] https://github.com/stefanha/patches/blob/stefanha-tweaks/README-server.md -- /kashyap

3 7

[libvirt] Request for testing: migration of libvirt wiki site
by Daniel P. Berrange 29 Mar '16

29 Mar '16

I'm preparing for a migration of the libvirt wiki off the host it is currently running on, to OpenShift hosting. This isn't entirely straightforward, as I'm also upgrading the version of mediawiki and as a result had to re-write the CSS customization from scratch. I may well have messed something up, so would appreciate if people could have a quick look at this testing instance of the wiki and confirm that it looks / works reasonably for them. http://wiki-libvirt.rhcloud.com NB, any edits you make in this test instance will be discarded when I load a fresh database dump from the current live wiki. If all looks good, I'll look at getting DNS updated to switch over later this week. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

5 12

[libvirt] [PATCH 00/10] Introduce worker tuning APIs
by Erik Skultety 29 Mar '16

29 Mar '16

Erik Skultety (10): libvirt-host: Move virTypedParam* to libvirt-common admin: Enable usage of typed parameters admin: Introduce virAdmConnectServerLookupByName util: Refactor thread creation by introducing virThreadPoolExpand util: Report system error when virThreadCreateFull fails util: Add more getters to threadpool parameters admin: Prepare admin protocol for future worker related procedures admin: Introduce virAdmServerGethreadPoolParameters admin: Introduce virAdmServerSetThreadPoolParameters virt-admin: Introduce srv-workertune command cfg.mk | 2 +- daemon/admin.c | 129 ++++++++++++++++++++++++ daemon/admin_server.c | 129 ++++++++++++++++++++++++ daemon/admin_server.h | 15 +++ include/libvirt/libvirt-admin.h | 74 ++++++++++++++ include/libvirt/libvirt-common.h.in | 185 ++++++++++++++++++++++++++++++++++ include/libvirt/libvirt-host.h | 186 ---------------------------------- include/libvirt/virterror.h | 1 + po/POTFILES.in | 4 +- src/admin/admin_protocol.x | 67 +++++++++++- src/admin/admin_remote.c | 104 +++++++++++++++++++ src/admin_protocol-structs | 52 ++++++++++ src/libvirt-admin.c | 114 +++++++++++++++++++++ src/libvirt_admin_private.syms | 5 + src/libvirt_admin_public.syms | 3 + src/libvirt_private.syms | 4 + src/rpc/virnetserver.c | 37 +++++++ src/rpc/virnetserver.h | 13 +++ src/util/virerror.c | 6 ++ src/util/virthreadpool.c | 196 ++++++++++++++++++++++++------------ src/util/virthreadpool.h | 8 ++ tools/virt-admin.c | 132 ++++++++++++++++++++++++ 22 files changed, 1212 insertions(+), 254 deletions(-) -- 2.4.3

3 13

[libvirt] [PATCH] rbd: use unsigned long long instead of uint64_t
by Shanzhi Yu 29 Mar '16

29 Mar '16

Fix below error: storage/storage_backend_rbd.c: In function 'virStorageBackendRBDSetAllocation': storage/storage_backend_rbd.c:337:5: error: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint64_t' [-Werror=format=] VIR_DEBUG("Found %llu bytes allocated for RBD image %s", Signed-off-by: Shanzhi Yu <shyu(a)redhat.com> --- src/storage/storage_backend_rbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index c9b47e2..dec0905 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -324,7 +324,7 @@ virStorageBackendRBDSetAllocation(virStorageVolDefPtr vol, rbd_image_info_t *info) { int r, ret = -1; - uint64_t allocation = 0; + unsigned long long allocation = 0; if ((r = rbd_diff_iterate2(image, NULL, 0, info->size, 0, 1, &virStorageBackendRBDRefreshVolInfoCb, -- 1.8.3.1

2 1