Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
Am 01.07.2013 04:26, schrieb Gao feng: Well, given that we're at rc2 now I'm still unclear about how some aspects of the userns setup is working, I'm afraid we'll have to wait until 1.1.1 for the userns LXC code to merge. I'll aim todo it next week, so that we have plenty of time for further testing before the 1.1.1 release. Ok, I think Richard had tested the userns support. Hi Richard, can you give me your ack or tested-by? I'm still facing one userns related issue. Create a container like this one: ---cut--- domain type='lxc' nametesti/name memory102400/memory os typeexe/type init/bin/bash/init /os idmap uid start='0' target='10' count='10'/ gid start='0' target='10' count='10'/ /idmap devices console type='pty'/ filesystem type='mount' source dir='/some/where/rootfs'/ target dir='/'/ /filesystem interface type='network' source network='default'/ mac address=52:54:00:be:49:be/ /interface /devices /domain ---cut--- After creating it attach to it's console, you'll find bash as pid 1. And you'll find that /proc/1/ is not fully uid/gid-mapped: ---cut--- # ls -la /proc/1/ total 0 dr-xr-xr-x 8 root root0 Jul 1 06:06 . dr-xr-xr-x 74 nobody nogroup 0 Jul 1 06:06 .. dr-xr-xr-x 2 root root0 Jul 1 06:06 attr -r 1 nobody nogroup 0 Jul 1 06:06 auxv -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 cgroup --w--- 1 nobody nogroup 0 Jul 1 06:06 clear_refs -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 cmdline -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 comm -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 coredump_filter -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 cpuset lrwxrwxrwx 1 nobody nogroup 0 Jul 1 06:06 cwd - / -r 1 nobody nogroup 0 Jul 1 06:06 environ lrwxrwxrwx 1 nobody nogroup 0 Jul 1 06:06 exe - /bin/bash dr-x-- 2 nobody nogroup 0 Jul 1 06:06 fd dr-x-- 2 nobody nogroup 0 Jul 1 06:06 fdinfo -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 gid_map -r 1 nobody nogroup 0 Jul 1 06:06 io -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 limits -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 loginuid -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 maps -rw--- 1 nobody nogroup 0 Jul 1 06:06 mem -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 mountinfo -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 mounts -r 1 nobody nogroup 0 Jul 1 06:06 mountstats dr-xr-xr-x 10 root root0 Jul 1 06:06 net dr-x--x--x 2 nobody nogroup 0 Jul 1 06:06 ns -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 numa_maps -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 oom_adj -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 oom_score -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 oom_score_adj -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 pagemap -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 personality -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 projid_map lrwxrwxrwx 1 nobody nogroup 0 Jul 1 06:06 root - / -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 schedstat -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 sessionid -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 smaps -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 stack -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 stat -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 statm -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 status -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 syscall dr-xr-xr-x 3 root root0 Jul 1 06:06 task -rw-r--r-- 1 nobody nogroup 0 Jul 1 06:06 uid_map -r--r--r-- 1 nobody nogroup 0 Jul 1 06:06 wchan ---cut--- Systemd suffers from this issue because it needs to read from /proc/1/environ. After one exec /proc seems to be fixed: ---cut--- # cat /proc/1/environ cat: /proc/1/environ: Permission denied # exec /bin/bash # cat /proc/1/environ TERM=linuxPATH=/bin:/sbinPWD=/container_uuid=fabc42f8-cdee-461c-9a21-93902ab52b40SHLVL=0LIBVIRT_LXC_UUID=fabc42f8-cdee-461c-9a21-93902ab52b40LIBVIRT_LXC_NAME=testicontainer=lxc-libvirt ---cut--- If I turn lxcContainerDropCapabilities() into a NOP the permissions in /proc are no longer clobbered. Another (maybe related issue), No capabilities seem to get dropped. (Of course tested where lxcContainerDropCapabilities() is not a NOP :) ) ---cut--- # /usr/bin/pscap -a ppid pid namecommand capabilities 0 1 rootbash full ---cut--- Any ideas what's going on here? Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] LXC: autostart feature does set all interfaces to state up.
Hi! If you have multiple LXC containers with networking and the autostart feature enabled libvirtd fails to up some veth interfaces on the host side. Most of the time only the first veth device is in state up, all others are down. Reproducing is easy. 1. Define a few containers (5 in my case) 2. Run virsh autostart ... on each one. 3. stop/start libvirtd You'll observe that all containers are running, but ip a will report on the host side that not all veth devices are up and are not usable within the containers. This is not userns related, just retested with libvirt of today. Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Document security reporting handling process
On 07/01/2013 05:09 AM, Daniel Veillard wrote: On Fri, Jun 28, 2013 at 11:45:59AM -0600, Eric Blake wrote: On 06/04/2013 09:33 AM, Eric Blake wrote: On 06/04/2013 04:06 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com Signed-off-by: Daniel P. Berrange berra...@redhat.com --- docs/bugs.html.in| 12 + docs/contact.html.in | 12 + docs/securityprocess.html.in | 113 +++ docs/sitemap.html.in | 4 ++ 4 files changed, 141 insertions(+) create mode 100644 docs/securityprocess.html.in Did this ever get pushed? It should go in before 1.1.0 is released, particularly since we have already used this list to discuss CVE-2013-2218 (more details on Monday when embargo ends). Right, I pushed it ! thanks ! Daniel It's still missing from the web - I see the link under Bug reports, but http://libvirt.org/securityprocess.html gives me 404. Jan -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V2] Expose all CPU features in host definition
On Fri, Jun 28, 2013 at 02:26:02PM -0600, Don Dugger wrote: On Fri, Jun 28, 2013 at 09:03:55PM +0100, Daniel P. Berrange wrote: On Fri, Jun 28, 2013 at 11:51:32AM -0600, Don Dugger wrote: On Fri, Jun 28, 2013 at 10:24:48AM +0100, Daniel P. Berrange wrote: On Thu, Jun 27, 2013 at 10:35:58AM -0600, Don Dugger wrote: On Mon, Jun 17, 2013 at 10:27:36AM +0200, Jiri Denemark wrote: On Fri, Jun 14, 2013 at 12:32:35 -0600, Don Dugger wrote: On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote: I was just trying to say that it doesn't provide anything more than it's supported by the host CPU, which gives mostly no value in the context of libvirt. Can you explain more what the use case is in which a virt client would need to know what specific feature are supported by host CPU? I feel like we should avoid people from being under the impression that they can actually use the CPU capabilities for checking whether a host can run guests that require specific CPU features. The specific use case I'm trying to address is a cloud environment where, with hundreds of hosts, you might want to schedule an instance to a host that supports a particular HW acceleration, like AES/NI. I agree, what I `really` want is an API that shows the capabilities of a specific guest that could be created on the host but, absent that API, at least knowing that a host doesn't support the feature is more information than I can get right now. Hmm, fair enough. Let's wait a few days for Daniel to return from vacation in case he wants to express his opinion here. So, any progress here? I believe the cloud use case above is approaching the problem in the wrong way. We designed our APIs such that apps should never need to write logic for comparing CPU features directly. If an application has a set of CPU features it requires from the host, then it should use a libvirt API to query whether those features are available, not try to write the CPU fetaure comparison logic itself. You can already pretty much do this with te virConnectCompareCPU() method, by passing an XML document which specifies the AES/NI feature flag that you want to check for support of. Then libvirt will tell you whether the host CPU can support it. It is entirely possible to make use of this capability as is in OpenStack. I don't think this would work with the way scheduling in OpenStack works. The problem is that the OpenStack scheduler doesn't want to query each node in the system on every schedule request (with 100s if not 1,000s of compute nodes this would not be practical). Instead the scheduler maintains info about all of the compute nodes and, when a request comes in, the scheduler identifies the best compute node for the request and then causes the VM to be started on that node. Apriori the scheduler doesn't even know which CPU features users are interested in, that information only becomes available when a schedule request comes in so trying to do a `virConnectCompareCPU()' call at that point in time is too late. I think your model for user interaction is wrong here. I don't believe that OpenStack should be directly exposing the ability for a user to explicitly request individual CPU flags for individual VMs. This is too risky from a cloud administrator POV, because it could result in a user monopolizing a small subset of machines in the guest with particular features. Instead an administrator should be defining new flavours with specific CPU feature characteristics. The user can That's the exact mechanism that is being proposed, the ability to define a flavor that specifies capabilities that are required. The issue is that the flavor is defined independently from the scheduler, it's only when a schedule request is made that the flavor is presented to the scheduler and then the scheduler needs to identify which of 1,000s of nodes can satisfy that flavor. Every 60 seconds or so, every node issues an update indicating what its capabilities are. In that update the nodes could do the CPU compatbility checks and then include the list of which flavours they are capable of executing in their capability update, so that it is then available to the schedular when needed then choose the flavour with the CPU characteristics. In this way the system can know ahead of time what flavours are possible on what host, and do you don't need to query all nodes at scheduling time. Note I am not proposing that we make a query at schedule time. The system is already setup to have the compute nodes send configuration info to the scheduler, all I want to do is
Re: [libvirt] [PATCH] Document security reporting handling process
On Mon, Jul 01, 2013 at 10:37:29AM +0200, Ján Tomko wrote: On 07/01/2013 05:09 AM, Daniel Veillard wrote: On Fri, Jun 28, 2013 at 11:45:59AM -0600, Eric Blake wrote: On 06/04/2013 09:33 AM, Eric Blake wrote: On 06/04/2013 04:06 AM, Daniel P. Berrange wrote: From: Daniel P. Berrange berra...@redhat.com Signed-off-by: Daniel P. Berrange berra...@redhat.com --- docs/bugs.html.in| 12 + docs/contact.html.in | 12 + docs/securityprocess.html.in | 113 +++ docs/sitemap.html.in | 4 ++ 4 files changed, 141 insertions(+) create mode 100644 docs/securityprocess.html.in Did this ever get pushed? It should go in before 1.1.0 is released, particularly since we have already used this list to discuss CVE-2013-2218 (more details on Monday when embargo ends). Right, I pushed it ! thanks ! Daniel It's still missing from the web - I see the link under Bug reports, but http://libvirt.org/securityprocess.html gives me 404. I had to speed up the checkout on the web site, it's up there now ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Am 01.07.2013 04:26, schrieb Gao feng: Well, given that we're at rc2 now I'm still unclear about how some aspects of the userns setup is working, I'm afraid we'll have to wait until 1.1.1 for the userns LXC code to merge. I'll aim todo it next week, so that we have plenty of time for further testing before the 1.1.1 release. Ok, I think Richard had tested the userns support. Hi Richard, can you give me your ack or tested-by? I'm still facing one userns related issue. [snip] After creating it attach to it's console, you'll find bash as pid 1. And you'll find that /proc/1/ is not fully uid/gid-mapped: ---cut--- # ls -la /proc/1/ total 0 dr-xr-xr-x 8 root root0 Jul 1 06:06 . dr-xr-xr-x 74 nobody nogroup 0 Jul 1 06:06 .. dr-xr-xr-x 2 root root0 Jul 1 06:06 attr [snip] Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Am 01.07.2013 04:26, schrieb Gao feng: Well, given that we're at rc2 now I'm still unclear about how some aspects of the userns setup is working, I'm afraid we'll have to wait until 1.1.1 for the userns LXC code to merge. I'll aim todo it next week, so that we have plenty of time for further testing before the 1.1.1 release. Ok, I think Richard had tested the userns support. Hi Richard, can you give me your ack or tested-by? I'm still facing one userns related issue. [snip] After creating it attach to it's console, you'll find bash as pid 1. And you'll find that /proc/1/ is not fully uid/gid-mapped: ---cut--- # ls -la /proc/1/ total 0 dr-xr-xr-x 8 root root0 Jul 1 06:06 . dr-xr-xr-x 74 nobody nogroup 0 Jul 1 06:06 .. dr-xr-xr-x 2 root root0 Jul 1 06:06 attr [snip] Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. Feel free to add: Acked-by: Richard Weinberger rich...@nod.at Tested-by: Richard Weinberger rich...@nod.at Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote: Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. Yeah, I've reproduced this problem with standalone code outside of libvirt. Take the attached code and run # gcc -Wall -o userns_child_exec userns_child_exec.c # ./userns_child_exec -U -M '0 1000 1' -G '0 1000 8' bash Launching child init # id uid=0(root) gid=7(lp) groups=0(root),65534(nfsnobody) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # ls -al /proc/1/environ -r. 1 nfsnobody nfsnobody 0 Jul 1 12:14 /proc/1/environ # cat /proc/1/environ cat: /proc/1/environ: Permission denied and this demo program isn't attempting to touch capabilties at all. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
Am 01.07.2013 13:22, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote: Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. Yeah, I've reproduced this problem with standalone code outside of libvirt. Take the attached code and run -ENOATTACHMENT :-( Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2] docs: Document hypervisor drivers that support certain timer models
Not every timer model is supported with each hypervisor. Explicitly mention the driver supporting each timer model. --- Notes: Version 2: - corrected the support of HPET (xen, libxl, qemu) and KVMCLOCK (just qemu) timers docs/formatdomain.html.in | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index cc4c5ea..47d91ab 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1310,8 +1310,10 @@ dtcodename/code/dt dd The codename/code attribute selects which timer is -being modified, and can be one of platform, hpet, -kvmclock, pit, rtc, or tsc. +being modified, and can be one of +platform (currently unsupported), +hpet (libxl, xen, qemu), kvmclock (qemu), +pit (qemu), rtc (qemu), or tsc (libxl). /dd dtcodetrack/code/dt dd -- 1.8.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
On Mon, Jul 01, 2013 at 01:25:28PM +0200, Richard Weinberger wrote:
Am 01.07.2013 13:22, schrieb Daniel P. Berrange:
On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote:
Am 01.07.2013 12:33, schrieb Daniel P. Berrange:
On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote:
Any ideas what's going on here?
No, it is very odd. It smells like a kernel issue to me. What
version are you running ?
I see this issue on all kernels.
Currently I'm using vanilla v3.9.x and v3.10.
I've also tried running the demo programs shown on the LWN.net
article
https://lwn.net/Articles/532593/
and they don't operate in the way described by the article - the demo
programs continue to ru as 'nfsnobody' even after the mappings are
setup.
I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled
in KConfig. I'm wondering if there is still stuff missing in 3.9.x
that prevents this from working properly, or if the kernel behaviour
changed after those LWN articles were written.
To me it looks like the capability system behaves odd.
The mappings in /proc are fine as long I do not call capng_updatev().
Also calling capng_updatev() with parameters that do not change the
current cap set
triggers the odd behavior too.
So we see two (related?) issues:
1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files
till we exec().
2. Dropping capabilities does not work we always gain a fresh and full
capability set.
BTW: I'm sure the issues are not caused by Gau Feng's userns patches.
Yeah, I've reproduced this problem with standalone code outside of
libvirt.
Take the attached code and run
-ENOATTACHMENT :-(
Now really attached.
I think I might know what is happening now though. When you start a new
namespace, you must mount a new instance of 'proc' filesystem. We are
not synchronizing this wrt setup of the uid/gid mappings though, so we
are racy. So I have a feeling we're creating the proc filesystem before
the mappings are setup. I'm going to add some synchronization in to see
if it makes a difference in this respect.
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 :|
/* userns_child_exec.c
Copyright 2013, Michael Kerrisk
Licensed under GNU General Public License v2 or later
Create a child process that executes a shell command in new
namespace(s); allow UID and GID mappings to be specified when
creating a user namespace.
*/
#define _GNU_SOURCE
#include sched.h
#include unistd.h
#include stdlib.h
#include sys/wait.h
#include signal.h
#include fcntl.h
#include stdio.h
#include string.h
#include limits.h
#include errno.h
/* A simple error-handling function: print an error message based
on the value in 'errno' and terminate the calling process */
#define errExit(msg)do { perror(msg); exit(EXIT_FAILURE); \
} while (0)
struct child_args {
char **argv;/* Command to be executed by child, with arguments */
intpipe_fd[2]; /* Pipe used to synchronize parent and child */
};
static int verbose;
static void
usage(char *pname)
{
fprintf(stderr, Usage: %s [options] cmd [arg...]\n\n, pname);
fprintf(stderr, Create a child process that executes a shell command
in a new user namespace,\n
and possibly also other new namespace(s).\n\n);
fprintf(stderr, Options can be:\n\n);
#define fpe(str) fprintf(stderr, %s, str);
fpe(-i New IPC namespace\n);
fpe(-m New mount namespace\n);
fpe(-n New network namespace\n);
fpe(-p New PID namespace\n);
fpe(-u New UTS namespace\n);
fpe(-U New user namespace\n);
fpe(-M uid_map Specify UID map for user namespace\n);
fpe(-G gid_map Specify GID map for user namespace\n);
fpe(If -M or -G is specified, -U is required\n);
fpe(-v Display verbose messages\n);
fpe(\n);
fpe(Map strings for -M and -G consist of records of the form:\n);
fpe(\n);
fpe(ID-inside-ns ID-outside-ns len\n);
fpe(\n);
fpe(A map string can contain multiple records, separated by commas;\n);
fpe(the commas are replaced by newlines before writing to map files.\n);
exit(EXIT_FAILURE);
}
/* Update the mapping file 'map_file', with the value provided in
'mapping', a string that defines a UID or GID mapping. A UID or
GID mapping consists of one or more newline-delimited records
of the form:
ID_inside-nsID-outside-ns length
Requiring the user to supply a string that contains newlines is
of course inconvenient for command-line use. Thus, we permit the
[libvirt] Release of libvirt-1.1.0
As planned I released libvirt-1.1.0 a couple of hours ago after a couple more patches and a fix for CVE-2013-2218 were applied. It should be available on the server along with the rpms: ftp://libvirt.org/libvirt/ The biggest feature leading to the bump in medium release number is the adition of ACL for individual access control of each API, until now there was only two classes of access read-only and read write, this feature is a big enhancement we have been thinking about for years! This version includes a relatively smaller amount of patches though, around 200, with a balanced set of bug fixes and enhancements, plus the fix for CVE-2013-2218 which is afftecting 1.0.6 release. Features: - Extensible migration APIs (Jiri Denemark) - Fine grained ACL support for the API (Daniel P. Berrange) - various improvements in the Xen driver (Jim Fehlig and Marek Marczykowski-Górecki) - improve networking support on BSD (Roman Bogorodskiy) - agent based vCPU hotplug support (Peter Krempa) Security: - CVE-2013-2218: Fix crash listing network interfaces with filters (Daniel P. Berrange) Documentation: - Document security reporting handling process (Daniel P. Berrange) - Fix reference to #elementsUSB (Philipp Hahn) - Fix sample TPM XML (Stefan Berger) - correct and update network vlan example (Laine Stump) - add spaces to formatstorage.html (Ján Tomko) Portability: - spec: require xen-devel for libxl driver (Eric Blake) - Conditionalize use of IF_MAXUNIT in virnetdevtap.c (Daniel P. Berrange) - Replace use of 'in_addr_t' with 'struct in_addr' (Daniel P. Berrange) - build: Fix VPATH build for access/* (Viktor Mihajlovski) - util: fix build error on non-Linux systems (Laine Stump) - conf: Swap order of AddImplicitControllers and DomainDefPostParse (Viktor Mihajlovski) - S390: Testcase for console default target type (virtio) (Viktor Mihajlovski) - Fix units in virNetDevBridgeSetSTPDelay on BSD (Roman Bogorodskiy) - build: Fix check-aclrules in VPATH build (Jiri Denemark) - build: Fix build with -Werror (Jim Fehlig) - use net/if.h instead of linux/if.h (Roman Bogorodskiy) - build: fix build without posix_fallocate (Eric Blake) - spec: Explicitly require libgcrypt-devel (Jiri Denemark) Bug Fixes: - pci: initialize virtual_functions array pointer to avoid segfault (Laine Stump) - node device driver: update driver name during dumpxml (Laine Stump) - Resolve valgrind errors for nodedev cap parsing (John Ferlan) - Resolve valgrind error in remoteConfigGetStringList() (John Ferlan) - Resolve valgrind error in virStorageBackendCreateQemuImgCmd() (John Ferlan) - Resolve valgrind error in virNetDevVlanParse() (John Ferlan) - Fix vPort management: FC vHBA creation (Dennis Chen) - bridge: don't crash on bandwidth unplug with no bandwidth (Ján Tomko) - Plug leak in virCgroupMoveTask (Ján Tomko) - Fix invalid read in virCgroupGetValueStr (Ján Tomko) - qemu: fix infinite loop in OOM error path (Laine Stump) - pci: fix dangling pointer in qemuDomainReAttachHostdevDevices (Laine Stump) - pci: eliminate leak in OOM condition (Laine Stump) - util: fix bug found by Coverity (Laine Stump) - Fix possible NULL dereference during migration (Jiri Denemark) - virsh: edit: don't leak XML string on reedit or redefine (Ján Tomko) - qemu: don't reset PCI devices being assigned with VFIO (Laine Stump) - pci: eliminate memory leak in virPCIDeviceReattach (Laine Stump) - qemu: check if block I/O limits fit into long long (Ján Tomko) - network: increase max number of routes (Laine Stump) - lxc: Resolve issue with GetScheduler APIs for non running domain (John Ferlan) - qemu: Resolve issue with GetScheduler APIs for non running domain (John Ferlan) - qemu: Avoid leaking uri in qemuMigrationPrepareDirect (Jiri Denemark) - udev: fix crash in libudev logging (Ján Tomko) - remote: Fix client crash when URI path is empty when using ssh (Peter Krempa) - remote: Forbid default /session connections when using ssh transport (Peter Krempa) - nodedev: fix vport detection for FC HBA (Ján Tomko) - qemu: Fix memory leak in Prepare phase (Jiri Denemark) - virSocketAddrIsWildcard: Use IN6_IS_ADDR_UNSPECIFIED correctly (Michal Privoznik) - Fix ordering of file open in virProcessGetNamespaces (Richard Weinberger) - qemuDomainGetVcpusFlags: Initialize ncpuinfo (Michal Privoznik) - virtlockd: fix socket path (Ján Tomko) - nwfilter: grab driver lock earlier during init (bz96649) (Stefan Berger) - Fix a invalid usage of virDomainNetDef in OpenVZ driver (Alvaro Polo) - use virBitmapFree instead of VIR_FREE for cpumask (Ján Tomko) - usb: don't spoil decimal addresses (Martin Kletzander) Improvements: - Allow RO connections to interface udev backend (Doug Goldstein) - virsh: Add parenthesis into virsh nodedev-detach help (xuzhang) - nodedev: add iommuGroup to node device object (Laine Stump) - pci: new iommu_group functions (Laine Stump) - network: allow vlan in type='hostdev' networks (Laine Stump) - test: include qemuhotplugtest data files in source rpm
[libvirt] [PATCH v2 1/5] snapshot: define new API virDomainSnapshotDeleteByName
This is to delete a snapshot object atomically, the API accepts
argments: domain object, snapshot name and flags. When name is
NULL, the current snapshot object will be deleted
include/libvirt/libvirt.h.in: Declare virDomainSnapshotDeleteByName
src/driver.h: (virDrvDomainSnapshotDeleteByName)
src/libvirt.c: Implement the public API
src/libvirt_public.syms: Export the symbol to public
---
include/libvirt/libvirt.h.in | 4 +++
src/driver.h | 6
src/libvirt.c| 71
src/libvirt_public.syms | 5
4 files changed, 86 insertions(+)
diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index b791125..e7e75c0 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -4433,6 +4433,10 @@ typedef enum {
int virDomainSnapshotDelete(virDomainSnapshotPtr snapshot,
unsigned int flags);
+int virDomainSnapshotDeleteByName(virDomainPtr domain,
+ const char *name,
+ unsigned int flags);
+
int virDomainSnapshotRef(virDomainSnapshotPtr snapshot);
int virDomainSnapshotFree(virDomainSnapshotPtr snapshot);
diff --git a/src/driver.h b/src/driver.h
index 31851cb..8651603 100644
--- a/src/driver.h
+++ b/src/driver.h
@@ -801,6 +801,11 @@ typedef int
unsigned int flags);
typedef int
+(*virDrvDomainSnapshotDeleteByName)(virDomainPtr domain,
+const char *cmd,
+unsigned int flags);
+
+typedef int
(*virDrvDomainQemuMonitorCommand)(virDomainPtr domain,
const char *cmd,
char **result,
@@ -1272,6 +1277,7 @@ struct _virDriver {
virDrvDomainSnapshotHasMetadata domainSnapshotHasMetadata;
virDrvDomainRevertToSnapshot domainRevertToSnapshot;
virDrvDomainSnapshotDelete domainSnapshotDelete;
+virDrvDomainSnapshotDeleteByName domainSnapshotDeleteByName;
virDrvDomainQemuMonitorCommand domainQemuMonitorCommand;
virDrvDomainQemuAttach domainQemuAttach;
virDrvDomainQemuAgentCommand domainQemuAgentCommand;
diff --git a/src/libvirt.c b/src/libvirt.c
index bc1694a..aa04959 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -20158,6 +20158,10 @@ error:
* libvirt metadata to track snapshots, then this flag is silently
* ignored.
*
+ * Note that this command is inherently racy: another connection can
+ * delete the snapshot object between a call to virDomainSnapshotLookupByName()
+ * and this call.
+ *
* Returns 0 if the selected snapshot(s) were successfully deleted,
* -1 on error.
*/
@@ -20207,6 +20211,73 @@ error:
}
/**
+ * virDomainSnapshotDeleteByName:
+ * @domain: pointer to the domain object
+ * @name : snapshot name or NULL
+ * @flags: bitwise-OR of supported virDomainSnapshotDeleteFlags
+ *
+ * Delete the snapshot.
+ *
+ * If @flags is 0, then just this snapshot is deleted, and changes
+ * from this snapshot are automatically merged into children
+ * snapshots. If @flags includes VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN,
+ * then this snapshot and any descendant snapshots are deleted. If
+ * @flags includes VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY, then any
+ * descendant snapshots are deleted, but this snapshot remains. These
+ * two flags are mutually exclusive.
+ *
+ * If @flags includes VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY, then
+ * any snapshot metadata tracked by libvirt is removed while keeping
+ * the snapshot contents intact; if a hypervisor does not require any
+ * libvirt metadata to track snapshots, then this flag is silently
+ * ignored.
+ *
+ * Returns 0 if the selected snapshot(s) were successfully deleted,
+ * -1 on error.
+ */
+int
+virDomainSnapshotDeleteByName(virDomainPtr domain,
+ const char *name,
+ unsigned int flags)
+{
+VIR_DOMAIN_DEBUG(domain, name=%s, flags=%x, name, flags);
+
+virResetLastError();
+
+if (!VIR_IS_DOMAIN(domain)) {
+virLibDomainError(VIR_ERR_INVALID_DOMAIN, __FUNCTION__);
+virDispatchError(NULL);
+return -1;
+}
+
+if (domain-conn-flags VIR_CONNECT_RO) {
+virLibConnError(VIR_ERR_OPERATION_DENIED, __FUNCTION__);
+goto error;
+}
+
+if ((flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN)
+(flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY)) {
+virReportInvalidArg(flags,
+_(children and children_only flags in %s are
+ mutually exclusive),
+__FUNCTION__);
+goto error;
+}
+
+if (domain-conn-driver-domainSnapshotDelete) {
+int ret = domain-conn-driver-domainSnapshotDeleteByName(domain,
name, flags);
+if (ret 0)
+goto error;
+return ret;
+}
+
+virLibConnError(VIR_ERR_NO_SUPPORT,
[libvirt] [PATCH v2 2/5] snapshot: auto generate RPC calls for remoteDomainSnapshotDeleteByName
Let gendispatch.pl generate codes for both server side and client side.
*src/remote/remote_driver.c:
Add remoteDomainSnapshotDeleteByName into remote driver
*src/remote/remote_protocol.x:
New RPC procedure REMOTE_PROC_DOMAIN_SNAPSHOT_DELETE_BY_NAME
and its argument structs
*src/remote_protocol-structs: edit it to match
---
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 14 +-
src/remote_protocol-structs | 6 ++
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c
index 7a0c1f6..fe7b836 100644
--- a/src/remote/remote_driver.c
+++ b/src/remote/remote_driver.c
@@ -6721,6 +6721,7 @@ static virDriver remote_driver = {
.domainSnapshotIsCurrent = remoteDomainSnapshotIsCurrent, /* 0.9.13 */
.domainSnapshotHasMetadata = remoteDomainSnapshotHasMetadata, /* 0.9.13 */
.domainSnapshotDelete = remoteDomainSnapshotDelete, /* 0.8.0 */
+.domainSnapshotDeleteByName = remoteDomainSnapshotDeleteByName, /* 1.1.1 */
.domainQemuMonitorCommand = remoteDomainQemuMonitorCommand, /* 0.8.3 */
.domainQemuAttach = remoteDomainQemuAttach, /* 0.9.4 */
.domainQemuAgentCommand = remoteDomainQemuAgentCommand, /* 0.10.0 */
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index 2e9dc1d..aa3266b 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -2475,6 +2475,12 @@ struct remote_domain_snapshot_delete_args {
unsigned int flags;
};
+struct remote_domain_snapshot_delete_by_name_args {
+remote_nonnull_domain dom;
+remote_string name;
+unsigned int flags;
+};
+
struct remote_domain_open_console_args {
remote_nonnull_domain dom;
remote_string dev_name;
@@ -4944,6 +4950,12 @@ enum remote_procedure {
* @generate: none
* @acl: domain:migrate
*/
-REMOTE_PROC_DOMAIN_MIGRATE_CONFIRM3_PARAMS = 307
+REMOTE_PROC_DOMAIN_MIGRATE_CONFIRM3_PARAMS = 307,
+
+/**
+ * @generate: both
+ * @acl: domain:snapshot
+ */
+REMOTE_PROC_DOMAIN_SNAPSHOT_DELETE_BY_NAME = 308
};
diff --git a/src/remote_protocol-structs b/src/remote_protocol-structs
index e38d24a..d9f5a68 100644
--- a/src/remote_protocol-structs
+++ b/src/remote_protocol-structs
@@ -1904,6 +1904,11 @@ struct remote_domain_snapshot_delete_args {
remote_nonnull_domain_snapshot snap;
u_int flags;
};
+struct remote_domain_snapshot_delete_by_name_args {
+remote_nonnull_domain dom;
+remote_string name;
+u_int flags;
+};
struct remote_domain_open_console_args {
remote_nonnull_domain dom;
remote_string dev_name;
@@ -2601,4 +2606,5 @@ enum remote_procedure {
REMOTE_PROC_DOMAIN_MIGRATE_PERFORM3_PARAMS = 305,
REMOTE_PROC_DOMAIN_MIGRATE_FINISH3_PARAMS = 306,
REMOTE_PROC_DOMAIN_MIGRATE_CONFIRM3_PARAMS = 307,
+REMOTE_PROC_DOMAIN_SNAPSHOT_DELETE_BY_NAME = 308,
};
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
Am 01.07.2013 13:35, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 01:25:28PM +0200, Richard Weinberger wrote: Am 01.07.2013 13:22, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote: Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. Yeah, I've reproduced this problem with standalone code outside of libvirt. Take the attached code and run -ENOATTACHMENT :-( Now really attached. I think I might know what is happening now though. When you start a new namespace, you must mount a new instance of 'proc' filesystem. We are not synchronizing this wrt setup of the uid/gid mappings though, so we are racy. So I have a feeling we're creating the proc filesystem before the mappings are setup. I'm going to add some synchronization in to see if it makes a difference in this respect. So you mount /proc and write the uid/gid mappings in parallel? Both has to be done on the host side. Why is this parallel? Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 5/5] virsh: use virDomainSnapshotDeleteByName in cmdSnapshotDelete
---
tools/virsh-snapshot.c | 65 ++
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c
index 7e75772..15bdcd7 100644
--- a/tools/virsh-snapshot.c
+++ b/tools/virsh-snapshot.c
@@ -1966,37 +1966,82 @@ cmdSnapshotDelete(vshControl *ctl, const vshCmd *cmd)
const char *name = NULL;
virDomainSnapshotPtr snapshot = NULL;
unsigned int flags = 0;
+bool snapshotname = false;
+bool children = vshCommandOptBool(cmd, children);
+bool metadata = vshCommandOptBool(cmd, metadata);
+bool children_only = vshCommandOptBool(cmd, children-only);
+bool current = vshCommandOptBool(cmd, current);
+
+VSH_EXCLUSIVE_OPTIONS_VAR(children, children_only);
+
+if (vshCommandOptStringReq(ctl, cmd, snapshotname, name) 0)
+goto cleanup;
+
+if (current name) {
+snapshotname = true;
+VSH_EXCLUSIVE_OPTIONS_VAR(current, snapshotname);
+}
dom = vshCommandOptDomain(ctl, cmd, NULL);
if (dom == NULL)
goto cleanup;
+if (children)
+flags |= VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN;
+if (metadata)
+flags |= VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY;
+if (children_only)
+flags |= VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY;
+
+if (current || name) {
+if (virDomainSnapshotDeleteByName(dom, name, flags) == 0)
+goto finished;
+} else {
+vshError(ctl, _(--snapshotname or --current is required));
+goto cleanup;
+}
+
+if (last_error last_error-code == VIR_ERR_NO_SUPPORT) {
+vshResetLibvirtError();
+goto fallback;
+}
+
+goto error;
+
+fallback:
if (vshLookupSnapshot(ctl, cmd, snapshotname, true, dom,
snapshot, name) 0)
goto cleanup;
-if (vshCommandOptBool(cmd, children))
-flags |= VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN;
-if (vshCommandOptBool(cmd, children-only))
-flags |= VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY;
-if (vshCommandOptBool(cmd, metadata))
-flags |= VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY;
-
/* XXX If we wanted, we could emulate DELETE_CHILDREN_ONLY even on
* older servers that reject the flag, by manually computing the
* list of descendants. But that's a lot of code to maintain. */
-if (virDomainSnapshotDelete(snapshot, flags) == 0) {
+if (virDomainSnapshotDelete(snapshot, flags) 0)
+goto error;
+
+finished:
+if (name) {
if (flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY)
vshPrint(ctl, _(Domain snapshot %s children deleted\n), name);
else
vshPrint(ctl, _(Domain snapshot %s deleted\n), name);
} else {
-vshError(ctl, _(Failed to delete snapshot %s), name);
-goto cleanup;
+if (flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY)
+vshPrint(ctl, _(Domain current snapshot children deleted\n));
+else
+vshPrint(ctl, _(Domain current snapshot deleted\n));
}
ret = true;
+error:
+if (ret == false) {
+if (name)
+vshError(ctl, _(Failed to delete snapshot %s), name);
+else
+vshError(ctl, _(Failed to delete current snapshot));
+}
+
cleanup:
if (snapshot)
virDomainSnapshotFree(snapshot);
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/5]Atomic API to delete snapshot object
v1: https://www.redhat.com/archives/libvir-list/2013-June/msg00573.html v1-v2: Remove VIR_DOMAIN_SNAPSHOT_DELETE_CURRENT flag (name == NULL) means deleting current snapshot object Rebase work Add a new snapshot API to delete snapshot object atomically int virDomainSnapshotDeleteByName(virDomainPtr domain, const char *name, unsigned int flags); The existing virDomainSnapshotDelete API accepts the snapshot object being deleted as an argument that would be not API atomic. Guannan Ren(5) [PATCH v2 1/5] snapshot: define new API virDomainSnapshotDeleteByName [PATCH v2 2/5] auto generate RPC calls for remoteDomainSnapshotDeleteByName [PATCH v2 3/5] qemu: implement SnapshotDeleteByName [PATCH v2 4/5] python: make auto-generated function name nicer [PATCH v2 5/5] virsh: use virDomainSnapshotDeleteByName in virsh include/libvirt/libvirt.h.in | 4 python/generator.py | 3 +++ src/driver.h | 6 ++ src/libvirt.c| 71 +++ src/libvirt_public.syms | 5 + src/qemu/qemu_driver.c | 103 +-- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 14 +- src/remote_protocol-structs | 6 ++ tools/virsh-snapshot.c | 65 +++-- 10 files changed, 245 insertions(+), 33 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 4/5] python: make auto-generated function name nicer
--- python/generator.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/python/generator.py b/python/generator.py index da642eb..91f17de 100755 --- a/python/generator.py +++ b/python/generator.py @@ -1078,6 +1078,9 @@ def nameFixup(name, classe, type, file): elif name[0:12] == virDomainGet: func = name[12:] func = string.lower(func[0:1]) + func[1:] +elif name[0:29] == virDomainSnapshotDeleteByName: +func = name[9:] +func = string.lower(func[0:1]) + func[1:] elif name[0:29] == virDomainSnapshotLookupByName: func = name[9:] func = string.lower(func[0:1]) + func[1:] -- 1.8.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 3/5] qemu: implement SnapshotDeleteByName
Refactor orgininal qemuDomainSnapshotDelete() into a common
function qemuDomainSnapshotDeleteImpl() which is used by both
APIs SnapshotDelete() and SnapshotDeleteByName()
---
src/qemu/qemu_driver.c | 103 ++---
1 file changed, 81 insertions(+), 22 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f51e766..e494a8a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13387,34 +13387,20 @@ qemuDomainSnapshotReparentChildren(void *payload,
rep-cfg-snapshotDir);
}
-
-static int qemuDomainSnapshotDelete(virDomainSnapshotPtr snapshot,
-unsigned int flags)
+static int
+qemuDomainSnapshotDeleteImpl(virQEMUDriverPtr driver,
+ virDomainObjPtr *vmptr,
+ virDomainSnapshotObjPtr snap,
+ unsigned int flags)
{
-virQEMUDriverPtr driver = snapshot-domain-conn-privateData;
-virDomainObjPtr vm = NULL;
+virDomainObjPtr vm = *vmptr;
int ret = -1;
-virDomainSnapshotObjPtr snap = NULL;
virQEMUSnapRemove rem;
virQEMUSnapReparent rep;
bool metadata_only = !!(flags VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY);
int external = 0;
-virQEMUDriverConfigPtr cfg = NULL;
-
-virCheckFlags(VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN |
- VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY |
- VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY, -1);
-
-if (!(vm = qemuDomObjFromSnapshot(snapshot)))
-return -1;
-
-cfg = virQEMUDriverGetConfig(driver);
-
-if (virDomainSnapshotDeleteEnsureACL(snapshot-domain-conn, vm-def) 0)
-goto cleanup;
-if (!(snap = qemuSnapObjFromSnapshot(vm, snapshot)))
-goto cleanup;
+virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
if (!metadata_only) {
if (!(flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY)
@@ -13492,9 +13478,81 @@ endjob:
vm = NULL;
cleanup:
+virObjectUnref(cfg);
+return ret;
+}
+
+static
+int qemuDomainSnapshotDelete(virDomainSnapshotPtr snapshot,
+ unsigned int flags)
+{
+virConnectPtr conn = snapshot-domain-conn;
+virQEMUDriverPtr driver = conn-privateData;
+virDomainObjPtr vm = NULL;
+virDomainSnapshotObjPtr snap = NULL;
+int ret = -1;
+
+virCheckFlags(VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN |
+ VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY |
+ VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY, -1);
+
+if (!(vm = qemuDomObjFromSnapshot(snapshot)))
+return -1;
+
+if (virDomainSnapshotDeleteEnsureACL(conn, vm-def) 0)
+goto cleanup;
+
+if (!(snap = qemuSnapObjFromSnapshot(vm, snapshot)))
+goto cleanup;
+
+ret = qemuDomainSnapshotDeleteImpl(driver, vm, snap, flags);
+
+cleanup:
+ if (vm)
+ virObjectUnlock(vm);
+ return ret;
+}
+
+static int
+qemuDomainSnapshotDeleteByName(virDomainPtr domain,
+ const char *name,
+ unsigned int flags)
+{
+virConnectPtr conn = domain-conn;
+virQEMUDriverPtr driver = conn-privateData;
+virDomainObjPtr vm = NULL;
+virDomainSnapshotObjPtr snap = NULL;
+const char *snapname = name;
+int ret = -1;
+
+virCheckFlags(VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN |
+ VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY |
+ VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY, -1);
+
+if (!(vm = qemuDomObjFromDomain(domain)))
+goto cleanup;
+
+if (virDomainSnapshotDeleteByNameEnsureACL(conn, vm-def) 0)
+goto cleanup;
+
+if (name == NULL) {
+if (!vm-current_snapshot) {
+virReportError(VIR_ERR_NO_DOMAIN_SNAPSHOT, %s,
+ _(the domain does not have a current snapshot));
+goto cleanup;
+}
+
+snapname = vm-current_snapshot-def-name;
+}
+
+if (!(snap = qemuSnapObjFromName(vm, snapname)))
+goto cleanup;
+
+ret = qemuDomainSnapshotDeleteImpl(driver, vm, snap, flags);
+
+cleanup:
if (vm)
virObjectUnlock(vm);
-virObjectUnref(cfg);
return ret;
}
@@ -16012,6 +16070,7 @@ static virDriver qemuDriver = {
.domainSnapshotHasMetadata = qemuDomainSnapshotHasMetadata, /* 0.9.13 */
.domainRevertToSnapshot = qemuDomainRevertToSnapshot, /* 0.8.0 */
.domainSnapshotDelete = qemuDomainSnapshotDelete, /* 0.8.0 */
+.domainSnapshotDeleteByName = qemuDomainSnapshotDeleteByName, /* 1.1.1 */
.domainQemuMonitorCommand = qemuDomainQemuMonitorCommand, /* 0.8.3 */
.domainQemuAttach = qemuDomainQemuAttach, /* 0.9.4 */
.domainQemuAgentCommand = qemuDomainQemuAgentCommand, /* 0.10.0 */
--
1.8.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/5]Atomic API to delete snapshot object
On Mon, Jul 01, 2013 at 07:47:06PM +0800, Guannan Ren wrote: v1: https://www.redhat.com/archives/libvir-list/2013-June/msg00573.html v1-v2: Remove VIR_DOMAIN_SNAPSHOT_DELETE_CURRENT flag (name == NULL) means deleting current snapshot object Rebase work Add a new snapshot API to delete snapshot object atomically int virDomainSnapshotDeleteByName(virDomainPtr domain, const char *name, unsigned int flags); The existing virDomainSnapshotDelete API accepts the snapshot object being deleted as an argument that would be not API atomic. You can already do: ss = virDomainSnapshotLookupByName(dom, name); virDomainSnapshotDelete(ss, flags); and your patch is just enabling: virDomainSnapshotDeleteByName(dom, name, flags); I really don't see any reason to add this new API, as it does not offer any functionality that was not already available. NACK unless there's better justification of why this is needed. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
Am 01.07.2013 13:44, schrieb Richard Weinberger: Am 01.07.2013 13:35, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 01:25:28PM +0200, Richard Weinberger wrote: Am 01.07.2013 13:22, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote: Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. Yeah, I've reproduced this problem with standalone code outside of libvirt. Take the attached code and run -ENOATTACHMENT :-( Now really attached. I think I might know what is happening now though. When you start a new namespace, you must mount a new instance of 'proc' filesystem. We are not synchronizing this wrt setup of the uid/gid mappings though, so we are racy. So I have a feeling we're creating the proc filesystem before the mappings are setup. I'm going to add some synchronization in to see if it makes a difference in this respect. So you mount /proc and write the uid/gid mappings in parallel? Both has to be done on the host side. Why is this parallel? Forget this one... :D Thanks, //richard -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
On 07/01/2013 07:05 PM, Richard Weinberger wrote: Am 01.07.2013 12:33, schrieb Daniel P. Berrange: On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: Am 01.07.2013 04:26, schrieb Gao feng: Well, given that we're at rc2 now I'm still unclear about how some aspects of the userns setup is working, I'm afraid we'll have to wait until 1.1.1 for the userns LXC code to merge. I'll aim todo it next week, so that we have plenty of time for further testing before the 1.1.1 release. Ok, I think Richard had tested the userns support. Hi Richard, can you give me your ack or tested-by? I'm still facing one userns related issue. [snip] After creating it attach to it's console, you'll find bash as pid 1. And you'll find that /proc/1/ is not fully uid/gid-mapped: ---cut--- # ls -la /proc/1/ total 0 dr-xr-xr-x 8 root root0 Jul 1 06:06 . dr-xr-xr-x 74 nobody nogroup 0 Jul 1 06:06 .. dr-xr-xr-x 2 root root0 Jul 1 06:06 attr [snip] Any ideas what's going on here? No, it is very odd. It smells like a kernel issue to me. What version are you running ? I see this issue on all kernels. Currently I'm using vanilla v3.9.x and v3.10. I've also tried running the demo programs shown on the LWN.net article https://lwn.net/Articles/532593/ and they don't operate in the way described by the article - the demo programs continue to ru as 'nfsnobody' even after the mappings are setup. I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled in KConfig. I'm wondering if there is still stuff missing in 3.9.x that prevents this from working properly, or if the kernel behaviour changed after those LWN articles were written. To me it looks like the capability system behaves odd. The mappings in /proc are fine as long I do not call capng_updatev(). Also calling capng_updatev() with parameters that do not change the current cap set triggers the odd behavior too. This issue is occured after we call setuid, the init task of container is set to be un-dumpable after setuid. I don't know why, the kernel set the owner of /proc/pid/* to root user of host when the task is un-dumpable. So we see two (related?) issues: 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files till we exec(). 2. Dropping capabilities does not work we always gain a fresh and full capability set. This problem disappeared after 1, remove capabilities dropping 2, call prctl(PR_SET_DUMPABLE, 1) after setuid/gid. BTW: I'm sure the issues are not caused by Gau Feng's userns patches. I think this more like a kernel bug. we should set the owner of /proc/pid/* to the root user of container not the host. Feel free to add: Acked-by: Richard Weinberger rich...@nod.at Tested-by: Richard Weinberger rich...@nod.at Thanks for your help! Gao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/4] security: Introduce method for labeling file descriptors of created files
On 06/27/13 20:51, Daniel P. Berrange wrote:
On Wed, Jun 26, 2013 at 03:01:49PM +0200, Peter Krempa wrote:
The method labels the file descriptor even if dynamic labeling/relabeling
is turned off. This is needed for files created by libvirt and then
passed along to qemu as a FD.
---
src/libvirt_private.syms| 1 +
src/security/security_dac.c | 9 +
src/security/security_driver.h | 4
src/security/security_manager.c | 16
src/security/security_manager.h | 3 +++
src/security/security_nop.c | 1 +
src/security/security_selinux.c | 21 +
src/security/security_stack.c | 19 +++
8 files changed, 74 insertions(+)
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index 7802dda..5894259 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -2446,6 +2446,26 @@
virSecuritySELinuxGetSecurityMountOptions(virSecurityManagerPtr mgr,
return opts;
}
+static int
+virSecuritySELinuxSetCreatedFDLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED,
+virDomainDefPtr def,
+int fd)
+{
+virSecurityLabelDefPtr secdef;
+
+if ((secdef = virDomainDefGetSecurityLabelDef(def,
SECURITY_SELINUX_NAME))) {
+if (!secdef-imagelabel)
+secdef-imagelabel = virSecuritySELinuxGenImageLabel(mgr, def);
This is really dubious. None of the methods except for GenSecurityLabel
should be making changes to the secdef state.
There is already an exception: virSecuritySELinuxGetSecurityMountOptions().
+} else {
+return -1;
+}
The style with nested if()s here is not following the pattern used in other
methods here either.
h ... ok
+
+if (secdef-imagelabel == NULL)
+return 0;
+
+return virSecuritySELinuxFSetFilecon(fd, secdef-imagelabel);
+}
In general I'm not really convinced we should be adding a new method
here, as opposed to making the existing SetImageFDLabel do the right
thing.
I was going to suggest expanding the function prototype with a bool that
would allow to choose whether to label the image always or only if
relabeling is enabled but looking through the code I noticed that
actually every caller would need to have this flag enabled.
There are currently 4 places this method is called:
qemuDumpToFd() - labels a FD of a freshly created file for the memory dump
qemuMigrationToFile() - again a new file FD is labeled, used for
(managed) save and dumping of memory
doTunnelMigrate() - the FD's of a pipe used for extracting data into the
stream are labeled, again this would probably fail with static labeling.
qemuProcessStart() - the migration FD is labelled on process start.
I think it's safe (and necessary) to relabel these even if relabeling is
disabled and thus we can change the function to always label FD's.
Do you agree?
Daniel
Peter
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC PATCH 2/2] LXC: Create ro overlay mounts only if we're not within a user namespace
On 07/01/2013 07:57 PM, Gao feng wrote:
On 07/01/2013 07:05 PM, Richard Weinberger wrote:
Am 01.07.2013 12:33, schrieb Daniel P. Berrange:
On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote:
Am 01.07.2013 04:26, schrieb Gao feng:
Well, given that we're at rc2 now I'm still unclear about how some
aspects of the userns setup is working, I'm afraid we'll have to wait
until 1.1.1 for the userns LXC code to merge. I'll aim todo it next
week, so that we have plenty of time for further testing before the
1.1.1 release.
Ok, I think Richard had tested the userns support.
Hi Richard, can you give me your ack or tested-by?
I'm still facing one userns related issue.
[snip]
After creating it attach to it's console, you'll find bash as pid 1.
And you'll find that /proc/1/ is not fully uid/gid-mapped:
---cut---
# ls -la /proc/1/
total 0
dr-xr-xr-x 8 root root0 Jul 1 06:06 .
dr-xr-xr-x 74 nobody nogroup 0 Jul 1 06:06 ..
dr-xr-xr-x 2 root root0 Jul 1 06:06 attr
[snip]
Any ideas what's going on here?
No, it is very odd. It smells like a kernel issue to me. What
version are you running ?
I see this issue on all kernels.
Currently I'm using vanilla v3.9.x and v3.10.
I've also tried running the demo programs shown on the LWN.net
article
https://lwn.net/Articles/532593/
and they don't operate in the way described by the article - the demo
programs continue to ru as 'nfsnobody' even after the mappings are
setup.
I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled
in KConfig. I'm wondering if there is still stuff missing in 3.9.x
that prevents this from working properly, or if the kernel behaviour
changed after those LWN articles were written.
To me it looks like the capability system behaves odd.
The mappings in /proc are fine as long I do not call capng_updatev().
Also calling capng_updatev() with parameters that do not change the current
cap set
triggers the odd behavior too.
This issue is occured after we call setuid, the init task of container is set
to be un-dumpable
after setuid. I don't know why, the kernel set the owner of /proc/pid/* to
root user of host when
the task is un-dumpable.
So we see two (related?) issues:
1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files
till we exec().
2. Dropping capabilities does not work we always gain a fresh and full
capability set.
This problem disappeared after
1, remove capabilities dropping
2, call prctl(PR_SET_DUMPABLE, 1) after setuid/gid.
BTW: I'm sure the issues are not caused by Gau Feng's userns patches.
I think this more like a kernel bug. we should set the owner of /proc/pid/*
to the root user
of container not the host.
You can try the program attached, the owner of /proc/pid of this program/* is
incorrect too.
Hmm, it's better to fix this problem in kernel. it's most like a userns bug.
Thanks
#include stdio.h
#include sys/types.h
#include unistd.h
int main()
{
setreuid(10,10);
setregid(10,10);
sleep(10);
return 0;
}
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/5]Atomic API to delete snapshot object
On 07/01/2013 07:51 PM, Daniel P. Berrange wrote: On Mon, Jul 01, 2013 at 07:47:06PM +0800, Guannan Ren wrote: v1: https://www.redhat.com/archives/libvir-list/2013-June/msg00573.html v1-v2: Remove VIR_DOMAIN_SNAPSHOT_DELETE_CURRENT flag (name == NULL) means deleting current snapshot object Rebase work Add a new snapshot API to delete snapshot object atomically int virDomainSnapshotDeleteByName(virDomainPtr domain, const char *name, unsigned int flags); The existing virDomainSnapshotDelete API accepts the snapshot object being deleted as an argument that would be not API atomic. You can already do: ss = virDomainSnapshotLookupByName(dom, name); virDomainSnapshotDelete(ss, flags); Yeah, right now, virsh tool uses this format to delete a snapshot. and your patch is just enabling: virDomainSnapshotDeleteByName(dom, name, flags); I really don't see any reason to add this new API, as it does not offer any functionality that was not already available. NACK unless there's better justification of why this is needed. Daniel This patchset just try to follow the scenario of *LIstAll* APIs for atomic operation for SnapshotDelete. I don't know if this is necessary in practice. just in theory. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5] qemu: Implement CPUs check against machine type's cpu-max
On 06/26/2013 05:46 PM, Michal Novotny wrote: Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. Differences between v4 and v5 (this one): - Changed type to unsigned int - Renamed variable to maxCpus to match previous naming - When machines types are parsed from command line set maxCpus = 0 to don't show Differences between v3 and v4: - Rebased to latest libvirt version - Capability XML output extended by maxCpus field - Extended caps-qemu-kvm.xml test by maxCpus for one of test emulators On older versions of QEMU the check is disabled. Signed-off-by: Michal Novotny minov...@redhat.com --- I polished the commit message (removed the differences) and pushed the patch. Martin -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5] qemu: Implement CPUs check against machine type's cpu-max
On 07/01/2013 02:38 PM, Martin Kletzander wrote: On 06/26/2013 05:46 PM, Michal Novotny wrote: Implement check whether (maximum) vCPUs doesn't exceed machine type's cpu-max settings. Differences between v4 and v5 (this one): - Changed type to unsigned int - Renamed variable to maxCpus to match previous naming - When machines types are parsed from command line set maxCpus = 0 to don't show Differences between v3 and v4: - Rebased to latest libvirt version - Capability XML output extended by maxCpus field - Extended caps-qemu-kvm.xml test by maxCpus for one of test emulators On older versions of QEMU the check is disabled. Signed-off-by: Michal Novotny minov...@redhat.com --- I polished the commit message (removed the differences) and pushed the patch. Martin Thanks a lot! :-) Michal -- Michal Novotny minov...@redhat.com, RHCE, Red Hat Virtualization | libvirt-php bindings | php-virt-control.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/5]Atomic API to delete snapshot object
On Mon, Jul 01, 2013 at 08:43:16PM +0800, Guannan Ren wrote: On 07/01/2013 07:51 PM, Daniel P. Berrange wrote: On Mon, Jul 01, 2013 at 07:47:06PM +0800, Guannan Ren wrote: v1: https://www.redhat.com/archives/libvir-list/2013-June/msg00573.html v1-v2: Remove VIR_DOMAIN_SNAPSHOT_DELETE_CURRENT flag (name == NULL) means deleting current snapshot object Rebase work Add a new snapshot API to delete snapshot object atomically int virDomainSnapshotDeleteByName(virDomainPtr domain, const char *name, unsigned int flags); The existing virDomainSnapshotDelete API accepts the snapshot object being deleted as an argument that would be not API atomic. You can already do: ss = virDomainSnapshotLookupByName(dom, name); virDomainSnapshotDelete(ss, flags); Yeah, right now, virsh tool uses this format to delete a snapshot. and your patch is just enabling: virDomainSnapshotDeleteByName(dom, name, flags); I really don't see any reason to add this new API, as it does not offer any functionality that was not already available. NACK unless there's better justification of why this is needed. Daniel This patchset just try to follow the scenario of *LIstAll* APIs for atomic operation for SnapshotDelete. I don't know if this is necessary in practice. just in theory. That is a completely different scenario. We had two APIs for each object eg virConnectListDomainIDs virConnectListDefinedDomains if you ran both those methods, at the same time as a VM moved from shutoff - running, in between calling virConnectListDomainIDs and virConnectListDomainIDs, you would loose it entirely. This does not apply to the virDomainSnapshotDeleteByName method. So again NACK to this series. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] BlockPivot issues
https://bugzilla.redhat.com/show_bug.cgi?id=977678 Ján Tomko (2): qemu: fix return value of qemuDomainBlockPivot on errors blockjob: make PIVOT and ASYNC flags mutually exclusive src/qemu/qemu_driver.c | 15 +++ tools/virsh-domain.c | 9 ++--- 2 files changed, 17 insertions(+), 7 deletions(-) -- 1.8.1.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] qemu: fix return value of qemuDomainBlockPivot on errors
If qemuMonitorBlockJob returned 0, qemuDomainBlockPivot
might return 0 even if an error occured.
https://bugzilla.redhat.com/show_bug.cgi?id=977678
---
src/qemu/qemu_driver.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index f51e766..6a83fda 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13844,7 +13844,7 @@ qemuDomainBlockPivot(virConnectPtr conn,
virQEMUDriverPtr driver, virDomainObjPtr vm,
const char *device, virDomainDiskDefPtr disk)
{
-int ret = -1;
+int ret = -1, rc;
qemuDomainObjPrivatePtr priv = vm-privateData;
virDomainBlockJobInfo info;
const char *format = virStorageFileFormatTypeToString(disk-mirrorFormat);
@@ -13857,17 +13857,17 @@ qemuDomainBlockPivot(virConnectPtr conn,
/* Probe the status, if needed. */
if (!disk-mirroring) {
qemuDomainObjEnterMonitor(driver, vm);
-ret = qemuMonitorBlockJob(priv-mon, device, NULL, 0, info,
+rc = qemuMonitorBlockJob(priv-mon, device, NULL, 0, info,
BLOCK_JOB_INFO, true);
qemuDomainObjExitMonitor(driver, vm);
-if (ret 0)
+if (rc 0)
goto cleanup;
if (!virDomainObjIsActive(vm)) {
virReportError(VIR_ERR_OPERATION_INVALID, %s,
_(domain is not running));
goto cleanup;
}
-if (ret == 1 info.cur == info.end
+if (rc == 1 info.cur == info.end
info.type == VIR_DOMAIN_BLOCK_JOB_TYPE_COPY)
disk-mirroring = true;
}
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] blockjob: make PIVOT and ASYNC flags mutually exclusive
https://bugzilla.redhat.com/show_bug.cgi?id=977678
---
src/qemu/qemu_driver.c | 7 +++
tools/virsh-domain.c | 9 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6a83fda..aa7affe 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14153,6 +14153,13 @@ qemuDomainBlockJobAbort(virDomainPtr dom, const char
*path, unsigned int flags)
virCheckFlags(VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC |
VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT, -1);
+if ((flags VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC)
+(flags VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)) {
+virReportError(VIR_ERR_INVALID_ARG, %s,
+ _(asynchronnous pivot not supported));
+return -1;
+}
+
if (!(vm = qemuDomObjFromDomain(dom)))
return -1;
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 5257416..2653388 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -1919,11 +1919,14 @@ cmdBlockJob(vshControl *ctl, const vshCmd *cmd)
virDomainBlockJobInfo info;
const char *type;
int ret;
-bool abortMode = (vshCommandOptBool(cmd, abort) ||
- vshCommandOptBool(cmd, async) ||
- vshCommandOptBool(cmd, pivot));
+bool abort = vshCommandOptBool(cmd, abort);
+bool async = vshCommandOptBool(cmd, async);
+bool pivot = vshCommandOptBool(cmd, pivot);
bool infoMode = vshCommandOptBool(cmd, info);
bool bandwidth = vshCommandOptBool(cmd, bandwidth);
+bool abortMode = abort || async || pivot;
+
+VSH_EXCLUSIVE_OPTIONS_VAR(async, pivot);
if (abortMode + infoMode + bandwidth 1) {
vshError(ctl, %s,
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt compliation from git source fails with gnulib/tests/Makefile.in' not found error
On 06/29/2013 11:43 PM, Eric Blake wrote: On 06/17/2013 03:57 AM, chandrashekar shastri wrote: Hi, I am compiling the libvirt from source and I am getting the following error: We need more details - are you trying to compile libvirt.git (if so, what commit are you on), or a tarball (and if so, where did you download the tarball from)? What platform are you on? What versions of automake and autoconf do you have installed? Unless I can reproduce the failure, I can't do much to help debug it. We pull from libvirt.git Branch master SHA1 24d0e67aba6b9d62cfee95582f211b4d850373d3 Fedora ( x86_64) kernel version : 3.10.0-rc5+ automake --version automake (GNU automake) 1.12.2 autoconf --version autoconf (GNU Autoconf) 2.69 Please let me know if you need more info. Thanks, Shastri autoreconf: running: automake --add-missing --copy --force-missing configure.ac:2424: required file `gnulib/lib/Makefile.in' not found configure.ac:2424: required file `gnulib/tests/Makefile.in' not found Since gnulib/lib/Makefile.am exists, I have to wonder if this might be a problem with your version of automake, but without knowing your version of automake, I can't be positive. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] qemu: fix return value of qemuDomainBlockPivot on errors
On 07/01/13 15:09, Ján Tomko wrote: If qemuMonitorBlockJob returned 0, qemuDomainBlockPivot might return 0 even if an error occured. https://bugzilla.redhat.com/show_bug.cgi?id=977678 --- src/qemu/qemu_driver.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) ACK Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Release of libvirt-1.1.0
On Mon, Jul 01, 2013 at 07:42:56PM +0800, Daniel Veillard wrote: As planned I released libvirt-1.1.0 a couple of hours ago after a couple more patches and a fix for CVE-2013-2218 were applied. It should be available on the server along with the rpms: ftp://libvirt.org/libvirt/ The biggest feature leading to the bump in medium release number is the adition of ACL for individual access control of each API, until now there was only two classes of access read-only and read write, this feature is a big enhancement we have been thinking about for years! This version includes a relatively smaller amount of patches though, around 200, with a balanced set of bug fixes and enhancements, plus the fix for CVE-2013-2218 which is afftecting 1.0.6 release. FYI, I pushed the fix for the CVE to the v1.0.6-maint branch. 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: add macvlan delete to qemuDomainAttachNetDevice cleanup
From: Matthew Rosato mjros...@linux.vnet.ibm.com
If an error occurs during qemuDomainAttachNetDevice after the macvtap
was created in qemuPhysIfaceConnect, the macvtap device gets left behind.
This patch adds code to the cleanup routine to delete the macvtap.
Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com
Reviewed-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com
---
src/qemu/qemu_hotplug.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 46875ad..c6045a0 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -965,6 +965,16 @@ cleanup:
if (iface_connected) {
virDomainConfNWFilterTeardown(net);
+if (virDomainNetGetActualType(net) == VIR_DOMAIN_NET_TYPE_DIRECT) {
+ignore_value(virNetDevMacVLanDeleteWithVPortProfile(
+ net-ifname, net-mac,
+ virDomainNetGetActualDirectDev(net),
+ virDomainNetGetActualDirectMode(net),
+ virDomainNetGetActualVirtPortProfile(net),
+ cfg-stateDir));
+VIR_FREE(net-ifname);
+}
+
vport = virDomainNetGetActualVirtPortProfile(net);
if (vport vport-virtPortType ==
VIR_NETDEV_VPORT_PROFILE_OPENVSWITCH)
ignore_value(virNetDevOpenvswitchRemovePort(
--
1.7.9.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] blockjob: make PIVOT and ASYNC flags mutually exclusive
(CC'd Eric)
On 07/01/13 15:09, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=977678
---
src/qemu/qemu_driver.c | 7 +++
tools/virsh-domain.c | 9 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6a83fda..aa7affe 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14153,6 +14153,13 @@ qemuDomainBlockJobAbort(virDomainPtr dom, const char
*path, unsigned int flags)
virCheckFlags(VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC |
VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT, -1);
+if ((flags VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC)
+(flags VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)) {
+virReportError(VIR_ERR_INVALID_ARG, %s,
+ _(asynchronnous pivot not supported));
+return -1;
+}
+
I agree with this hunk.
if (!(vm = qemuDomObjFromDomain(dom)))
return -1;
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 5257416..2653388 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -1919,11 +1919,14 @@ cmdBlockJob(vshControl *ctl, const vshCmd *cmd)
virDomainBlockJobInfo info;
const char *type;
int ret;
-bool abortMode = (vshCommandOptBool(cmd, abort) ||
- vshCommandOptBool(cmd, async) ||
- vshCommandOptBool(cmd, pivot));
+bool abort = vshCommandOptBool(cmd, abort);
+bool async = vshCommandOptBool(cmd, async);
+bool pivot = vshCommandOptBool(cmd, pivot);
bool infoMode = vshCommandOptBool(cmd, info);
bool bandwidth = vshCommandOptBool(cmd, bandwidth);
+bool abortMode = abort || async || pivot;
+
+VSH_EXCLUSIVE_OPTIONS_VAR(async, pivot);
.. but I don't think we should forbid this combination in virsh. I think
could happen that we might need this combination. I think that the
combination of _ABORT and _PIVOT is less usefull.
Eric, what do you think?
(Or if we do forbid it, we need to document it, and ban it at library
level instead of qemu driver)
if (abortMode + infoMode + bandwidth 1) {
vshError(ctl, %s,
Peter
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V2] Expose all CPU features in host definition
On Mon, Jul 01, 2013 at 09:44:52AM +0100, Daniel P. Berrange wrote: On Fri, Jun 28, 2013 at 02:26:02PM -0600, Don Dugger wrote: On Fri, Jun 28, 2013 at 09:03:55PM +0100, Daniel P. Berrange wrote: On Fri, Jun 28, 2013 at 11:51:32AM -0600, Don Dugger wrote: On Fri, Jun 28, 2013 at 10:24:48AM +0100, Daniel P. Berrange wrote: On Thu, Jun 27, 2013 at 10:35:58AM -0600, Don Dugger wrote: On Mon, Jun 17, 2013 at 10:27:36AM +0200, Jiri Denemark wrote: On Fri, Jun 14, 2013 at 12:32:35 -0600, Don Dugger wrote: On Fri, Jun 14, 2013 at 03:06:52PM +0200, Jiri Denemark wrote: I was just trying to say that it doesn't provide anything more than it's supported by the host CPU, which gives mostly no value in the context of libvirt. Can you explain more what the use case is in which a virt client would need to know what specific feature are supported by host CPU? I feel like we should avoid people from being under the impression that they can actually use the CPU capabilities for checking whether a host can run guests that require specific CPU features. The specific use case I'm trying to address is a cloud environment where, with hundreds of hosts, you might want to schedule an instance to a host that supports a particular HW acceleration, like AES/NI. I agree, what I `really` want is an API that shows the capabilities of a specific guest that could be created on the host but, absent that API, at least knowing that a host doesn't support the feature is more information than I can get right now. Hmm, fair enough. Let's wait a few days for Daniel to return from vacation in case he wants to express his opinion here. So, any progress here? I believe the cloud use case above is approaching the problem in the wrong way. We designed our APIs such that apps should never need to write logic for comparing CPU features directly. If an application has a set of CPU features it requires from the host, then it should use a libvirt API to query whether those features are available, not try to write the CPU fetaure comparison logic itself. You can already pretty much do this with te virConnectCompareCPU() method, by passing an XML document which specifies the AES/NI feature flag that you want to check for support of. Then libvirt will tell you whether the host CPU can support it. It is entirely possible to make use of this capability as is in OpenStack. I don't think this would work with the way scheduling in OpenStack works. The problem is that the OpenStack scheduler doesn't want to query each node in the system on every schedule request (with 100s if not 1,000s of compute nodes this would not be practical). Instead the scheduler maintains info about all of the compute nodes and, when a request comes in, the scheduler identifies the best compute node for the request and then causes the VM to be started on that node. Apriori the scheduler doesn't even know which CPU features users are interested in, that information only becomes available when a schedule request comes in so trying to do a `virConnectCompareCPU()' call at that point in time is too late. I think your model for user interaction is wrong here. I don't believe that OpenStack should be directly exposing the ability for a user to explicitly request individual CPU flags for individual VMs. This is too risky from a cloud administrator POV, because it could result in a user monopolizing a small subset of machines in the guest with particular features. Instead an administrator should be defining new flavours with specific CPU feature characteristics. The user can That's the exact mechanism that is being proposed, the ability to define a flavor that specifies capabilities that are required. The issue is that the flavor is defined independently from the scheduler, it's only when a schedule request is made that the flavor is presented to the scheduler and then the scheduler needs to identify which of 1,000s of nodes can satisfy that flavor. Every 60 seconds or so, every node issues an update indicating what its capabilities are. In that update the nodes could do the CPU compatbility checks and then include the list of which flavours they are capable of executing in their capability update, so that it is then available to the schedular when needed This doesn't work for multiple reasons. 1. Ultimately, I want to remove the periodic capability update completely. The better technique is to update compute node state when the state
[libvirt] [PATCH] qemu: indentation fix
--- Pushed as trivial. src/qemu/qemu_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 4d70004..ba93233 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7003,7 +7003,7 @@ qemuBuildCommandLine(virConnectPtr conn, virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _(unsupported rtc tickpolicy '%s'), virDomainTimerTickpolicyTypeToString(def-clock.timers[i]-tickpolicy)); -goto error; +goto error; } } else if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_RTC) (def-clock.timers[i]-tickpolicy -- 1.8.1.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: don't use deprecated -no-kvm-pit-reinjection
Since qemu-kvm 1.1 [1] '-no-kvm-pit-reinjection' has been deprecated
in favor of '-global kvm-pit.lost_tick_policy=discard'
In upstream qemu since 1.3 [2].
https://bugzilla.redhat.com/show_bug.cgi?id=978719
[1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39
[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f
---
src/qemu/qemu_capabilities.c | 12 ++--
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 5 -
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 969b001..c6df463 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -233,6 +233,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
mlock,
vnc-share-policy, /* 150 */
+ kvm-pit-property,
);
struct _virQEMUCaps {
@@ -2468,13 +2469,12 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps,
/*
* Currently only x86_64 and i686 support PCI-multibus,
- * -no-acpi and -no-kvm-pit-reinjection.
+ * -no-acpi
*/
if (qemuCaps-arch == VIR_ARCH_X86_64 ||
qemuCaps-arch == VIR_ARCH_I686) {
virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS);
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
-virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT);
}
ret = 0;
@@ -2640,6 +2640,14 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
if (virQEMUCapsProbeQMPCommandLine(qemuCaps, mon) 0)
goto cleanup;
+/* -global kvm-pit.lost_tick_policy=discard */
+if ((qemuCaps-arch == VIR_ARCH_X86_64 ||
+ qemuCaps-arch == VIR_ARCH_I686)
+(qemuCaps-version = 1003000 ||
+ virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM))) {
+virQEMUCapsSet(qemuCaps, QEMU_CAPS_KVM_PIT_PROPERTY);
+}
+
ret = 0;
cleanup:
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 7088747..c64f648 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -189,6 +189,7 @@ enum virQEMUCapsFlags {
QEMU_CAPS_DRIVE_DISCARD = 148, /* -drive
discard=off(ignore)|on(unmap) */
QEMU_CAPS_MLOCK = 149, /* -realtime mlock=on|off */
QEMU_CAPS_VNC_SHARE_POLICY = 150, /* set display sharing policy */
+QEMU_CAPS_KVM_PIT_PROPERTY = 151, /* -global kvm-pit.lost_tick_policy */
QEMU_CAPS_LAST, /* this must always be the last item */
};
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index ba93233..a678666 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7024,7 +7024,10 @@ qemuBuildCommandLine(virConnectPtr conn,
case VIR_DOMAIN_TIMER_TICKPOLICY_DELAY:
/* delay is the default if we don't have kernel
(-no-kvm-pit), otherwise, the default is catchup. */
-if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT))
+if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_KVM_PIT_PROPERTY))
+virCommandAddArgList(cmd, -global,
+ kvm-pit.lost_tick_policy=discard,
NULL);
+else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT))
virCommandAddArg(cmd, -no-kvm-pit-reinjection);
break;
case VIR_DOMAIN_TIMER_TICKPOLICY_CATCHUP:
--
1.8.1.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] blockjob: make PIVOT and ASYNC flags mutually exclusive
On 07/01/2013 07:09 AM, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=977678
---
src/qemu/qemu_driver.c | 7 +++
tools/virsh-domain.c | 9 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6a83fda..aa7affe 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14153,6 +14153,13 @@ qemuDomainBlockJobAbort(virDomainPtr dom, const char
*path, unsigned int flags)
virCheckFlags(VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC |
VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT, -1);
+if ((flags VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC)
+(flags VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)) {
+virReportError(VIR_ERR_INVALID_ARG, %s,
+ _(asynchronnous pivot not supported));
s/asynchronnous/asynchronous/
Should this restriction be enforced at the API level in src/libvirt.c
instead? Probably not, because it might be conceivable that some types
of pivot operations might be long-running.
Next, do we need the restriction? If the 'async' flag merely means
return as fast as possible, and pivots (currently) always return
immediately (no long-running operations), then we can declare that use
or absence of the async flag makes no difference, and can silently
ignore it instead of forcefully rejecting it.
I'm inclined to NACK this patch, if we can't come up with a better
explanation of why it is needed.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] docs: Document hypervisor drivers that support certain timer models
On 07/01/2013 05:27 AM, Peter Krempa wrote: Not every timer model is supported with each hypervisor. Explicitly mention the driver supporting each timer model. --- Notes: Version 2: - corrected the support of HPET (xen, libxl, qemu) and KVMCLOCK (just qemu) timers docs/formatdomain.html.in | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) ACK. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 0/2] pci: make virPCIDeviceReset more autonomous
This replaces the earlier single patch by the same name (which I somehow managed to send without testing it :-() This time it's split into two patches because some of the static functions in virpci.c needed re-ordering for successful compilation, so I made that movement a separate patch. Laine Stump (2): pci: reorder static functions pci: make virPCIDeviceReset more autonomous src/qemu/qemu_hostdev.c | 6 +- src/qemu/qemu_hotplug.c | 5 +- src/util/virpci.c | 204 +++- 3 files changed, 118 insertions(+), 97 deletions(-) -- 1.7.11.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 2/2] pci: make virPCIDeviceReset more autonomous
I recently patches the callers to virPCIDeviceReset() to not call it
if the current driver for a device was vfio-pci (since that driver
will always reset the device itself when appropriate. At the time, Dan
Berrange suggested that I could instead modify virPCIDeviceReset
to check the currently bound driver for the device, and decide
for itself whether or not to go ahead with the reset.
This patch removes the previously added checks, and replaces them with
a check down in virPCIDeviceReset(), as suggested.
The functional difference here is that previously we were deciding
based on either the hostdev configuration or the value of
stubDriverName in the virPCIDevice object, but now we are actually
comparing to the driver link in the device's sysfs entry
directly. In practice, both should be the same.
---
src/qemu/qemu_hostdev.c | 6 ++
src/qemu/qemu_hotplug.c | 5 ++---
src/util/virpci.c | 27 ---
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c
index 404939e..3001d6b 100644
--- a/src/qemu/qemu_hostdev.c
+++ b/src/qemu/qemu_hostdev.c
@@ -544,8 +544,7 @@ int qemuPrepareHostdevPCIDevices(virQEMUDriverPtr driver,
* can safely reset them */
for (i = 0; i virPCIDeviceListCount(pcidevs); i++) {
virPCIDevicePtr dev = virPCIDeviceListGet(pcidevs, i);
-if (STREQ_NULLABLE(virPCIDeviceGetStubDriver(dev), vfio-pci))
-continue;
+
if (virPCIDeviceReset(dev, driver-activePciHostdevs,
driver-inactivePciHostdevs) 0)
goto reattachdevs;
@@ -1116,8 +1115,7 @@ void qemuDomainReAttachHostdevDevices(virQEMUDriverPtr
driver,
for (i = 0; i virPCIDeviceListCount(pcidevs); i++) {
virPCIDevicePtr dev = virPCIDeviceListGet(pcidevs, i);
-if (STREQ_NULLABLE(virPCIDeviceGetStubDriver(dev), vfio-pci))
-continue;
+
if (virPCIDeviceReset(dev, driver-activePciHostdevs,
driver-inactivePciHostdevs) 0) {
virErrorPtr err = virGetLastError();
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 46875ad..5edd36e 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -2528,9 +2528,8 @@ qemuDomainDetachHostPciDevice(virQEMUDriverPtr driver,
if (pci) {
activePci = virPCIDeviceListSteal(driver-activePciHostdevs, pci);
if (activePci
-(subsys-u.pci.backend == VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO ||
- virPCIDeviceReset(activePci, driver-activePciHostdevs,
- driver-inactivePciHostdevs) == 0)) {
+virPCIDeviceReset(activePci, driver-activePciHostdevs,
+ driver-inactivePciHostdevs) == 0) {
qemuReattachPciDevice(activePci, driver);
ret = 0;
} else {
diff --git a/src/util/virpci.c b/src/util/virpci.c
index fc76952..15de3f9 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -883,8 +883,10 @@ virPCIDeviceReset(virPCIDevicePtr dev,
virPCIDeviceList *activeDevs,
virPCIDeviceList *inactiveDevs)
{
+char *drvPath = NULL;
+char *drvName = NULL;
int ret = -1;
-int fd;
+int fd = -1;
if (activeDevs virPCIDeviceListFind(activeDevs, dev)) {
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -892,8 +894,24 @@ virPCIDeviceReset(virPCIDevicePtr dev,
return -1;
}
+/* If the device is currently bound to vfio-pci, ignore all
+ * requests to reset it, since the vfio-pci driver will always
+ * reset it whenever appropriate, so doing it ourselves would just
+ * be redundant.
+ */
+if (virPCIDeviceGetDriverPathAndName(dev, drvPath, drvName) 0)
+goto cleanup;
+
+if (STREQ_NULLABLE(drvName, vfio-pci)) {
+VIR_DEBUG(Device %s is bound to vfio-pci - skip reset,
+ dev-name);
+ret = 0;
+goto cleanup;
+}
+VIR_DEBUG(Resetting device %s, dev-name);
+
if ((fd = virPCIDeviceConfigOpen(dev, true)) 0)
-return -1;
+goto cleanup;
if (virPCIDeviceInit(dev, fd) 0)
goto cleanup;
@@ -922,10 +940,13 @@ virPCIDeviceReset(virPCIDevicePtr dev,
virReportError(VIR_ERR_INTERNAL_ERROR,
_(Unable to reset PCI device %s: %s),
dev-name,
- err ? err-message : _(no FLR, PM reset or bus reset
available));
+ err ? err-message :
+ _(no FLR, PM reset or bus reset available));
}
cleanup:
+VIR_FREE(drvPath);
+VIR_FREE(drvName);
virPCIDeviceConfigClose(dev, fd);
return ret;
}
--
1.7.11.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 1/2] pci: reorder static functions
virPCIDeviceGetDriverPathAndName is a static function that will need
to be called by another function that occurs above it in the
file. This patch reorders the static functions so that a forward
declaration isn't needed.
---
src/util/virpci.c | 177 +++---
1 file changed, 90 insertions(+), 87 deletions(-)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 54f7715..fc76952 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -188,6 +188,96 @@ static int virPCIOnceInit(void)
VIR_ONCE_GLOBAL_INIT(virPCI)
+
+static int
+virPCIDriverDir(char **buffer, const char *driver)
+{
+VIR_FREE(*buffer);
+
+if (virAsprintf(buffer, PCI_SYSFS drivers/%s, driver) 0) {
+virReportOOMError();
+return -1;
+}
+
+return 0;
+}
+
+
+static int
+virPCIDriverFile(char **buffer, const char *driver, const char *file)
+{
+VIR_FREE(*buffer);
+
+if (virAsprintf(buffer, PCI_SYSFS drivers/%s/%s, driver, file) 0) {
+virReportOOMError();
+return -1;
+}
+
+return 0;
+}
+
+
+static int
+virPCIFile(char **buffer, const char *device, const char *file)
+{
+VIR_FREE(*buffer);
+
+if (virAsprintf(buffer, PCI_SYSFS devices/%s/%s, device, file) 0) {
+virReportOOMError();
+return -1;
+}
+
+return 0;
+}
+
+
+/* virPCIDeviceGetDriverPathAndName - put the path to the driver
+ * directory of the driver in use for this device in @path and the
+ * name of the driver in @name. Both could be NULL if it's not bound
+ * to any driver.
+ *
+ * Return 0 for success, -1 for error.
+ */
+static int
+virPCIDeviceGetDriverPathAndName(virPCIDevicePtr dev, char **path, char **name)
+{
+int ret = -1;
+char *drvlink = NULL;
+
+*path = *name = NULL;
+/* drvlink = /sys/bus/pci/:bb:ss.ff/driver */
+if (virPCIFile(drvlink, dev-name, driver) 0)
+goto cleanup;
+
+if (virFileIsLink(drvlink) != 1) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(Invalid device %s driver file %s is not a symlink),
+ dev-name, drvlink);
+goto cleanup;
+}
+if (virFileResolveLink(drvlink, path) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(Unable to resolve device %s driver symlink %s),
+ dev-name, drvlink);
+goto cleanup;
+}
+/* path = /sys/bus/pci/drivers/${drivername} */
+
+if (VIR_STRDUP(*name, last_component(*path)) 0)
+goto cleanup;
+/* name = ${drivername} */
+
+ret = 0;
+cleanup:
+VIR_FREE(drvlink);
+if (ret 0) {
+VIR_FREE(*path);
+VIR_FREE(*name);
+}
+return ret;
+}
+
+
static int
virPCIDeviceConfigOpen(virPCIDevicePtr dev, bool fatal)
{
@@ -842,93 +932,6 @@ cleanup:
static int
-virPCIDriverDir(char **buffer, const char *driver)
-{
-VIR_FREE(*buffer);
-
-if (virAsprintf(buffer, PCI_SYSFS drivers/%s, driver) 0) {
-virReportOOMError();
-return -1;
-}
-
-return 0;
-}
-
-static int
-virPCIDriverFile(char **buffer, const char *driver, const char *file)
-{
-VIR_FREE(*buffer);
-
-if (virAsprintf(buffer, PCI_SYSFS drivers/%s/%s, driver, file) 0) {
-virReportOOMError();
-return -1;
-}
-
-return 0;
-}
-
-static int
-virPCIFile(char **buffer, const char *device, const char *file)
-{
-VIR_FREE(*buffer);
-
-if (virAsprintf(buffer, PCI_SYSFS devices/%s/%s, device, file) 0) {
-virReportOOMError();
-return -1;
-}
-
-return 0;
-}
-
-
-/* virPCIDeviceGetDriverPathAndName - put the path to the driver
- * directory of the driver in use for this device in @path and the
- * name of the driver in @name. Both could be NULL if it's not bound
- * to any driver.
- *
- * Return 0 for success, -1 for error.
- */
-static int
-virPCIDeviceGetDriverPathAndName(virPCIDevicePtr dev, char **path, char **name)
-{
-int ret = -1;
-char *drvlink = NULL;
-
-*path = *name = NULL;
-/* drvlink = /sys/bus/pci/:bb:ss.ff/driver */
-if (virPCIFile(drvlink, dev-name, driver) 0)
-goto cleanup;
-
-if (virFileIsLink(drvlink) != 1) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
- _(Invalid device %s driver file %s is not a symlink),
- dev-name, drvlink);
-goto cleanup;
-}
-if (virFileResolveLink(drvlink, path) 0) {
-virReportError(VIR_ERR_INTERNAL_ERROR,
- _(Unable to resolve device %s driver symlink %s),
- dev-name, drvlink);
-goto cleanup;
-}
-/* path = /sys/bus/pci/drivers/${drivername} */
-
-if (VIR_STRDUP(*name, last_component(*path)) 0)
-goto cleanup;
-/* name = ${drivername} */
-
-ret = 0;
-cleanup:
-VIR_FREE(drvlink);
-if (ret 0) {
-VIR_FREE(*path);
-VIR_FREE(*name);
-}
-return ret;
-}
-
-
-static int
Re: [libvirt] [PATCH] Drop iptablesContext
On 06/28/2013 12:52 AM, Roman Bogorodskiy wrote: iptablesContext holds only 4 pairs of iptables (table, chain) and there's no need to pass it around. This is a first step towards separating bridge_driver.c in platform-specific parts. --- src/libvirt_private.syms| 2 - src/network/bridge_driver.c | 253 +-- src/util/viriptables.c | 257 +++- src/util/viriptables.h | 65 --- 4 files changed, 183 insertions(+), 394 deletions(-) Now that 1.1.0 is released, I verified that this patch doesn't cause any change in behavior, modified networkShutdownNetworkVirtual() to retain the driver arg with an ATTRIBUTE_UNUSED (so that it's consistent with other similar functions), and pushed the result. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] blockjob: make PIVOT and ASYNC flags mutually exclusive
On 07/01/2013 09:28 AM, Peter Krempa wrote:
(CC'd Eric)
On 07/01/13 15:09, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=977678
---
src/qemu/qemu_driver.c | 7 +++
tools/virsh-domain.c | 9 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6a83fda..aa7affe 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14153,6 +14153,13 @@ qemuDomainBlockJobAbort(virDomainPtr dom,
const char *path, unsigned int flags)
virCheckFlags(VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC |
VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT, -1);
+if ((flags VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC)
+(flags VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)) {
+virReportError(VIR_ERR_INVALID_ARG, %s,
+ _(asynchronnous pivot not supported));
+return -1;
+}
+
I agree with this hunk.
I'm still not convinced, but agree that only this hunk is necessary if
we want the patch.
+VSH_EXCLUSIVE_OPTIONS_VAR(async, pivot);
.. but I don't think we should forbid this combination in virsh. I think
could happen that we might need this combination. I think that the
combination of _ABORT and _PIVOT is less usefull.
Eric, what do you think?
(Or if we do forbid it, we need to document it, and ban it at library
level instead of qemu driver)
I prefer letting virsh pass ALL combinations down to lower level
software, when possible. It lets us test that the lower-level software
is accepting or rejecting combinations, instead of silently
short-circuiting combinations that may later prove useful. I agree with
your desire to NACK this hunk.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] build: avoid build failure without gnutls
Found while trying to cross-compile to mingw: CC libvirt_driver_remote_la-remote_driver.lo ../../src/remote/remote_driver.c: In function 'doRemoteOpen': ../../src/remote/remote_driver.c:487:23: error: variable 'verify' set but not used [-Werror=unused-but-set-variable] * src/remote/remote_driver.c (doRemoteOpen): Also ignore 'verify'. Signed-off-by: Eric Blake ebl...@redhat.com --- Pushing under the build-breaker rule. I also had a report that libvirt fails to compile for mingw on Fedora 19; it looks like a gnulib submodule update will fix part of that issue, so I'm working on that now... https://lists.fedoraproject.org/pipermail/mingw/2013-June/007006.html http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=86725346 src/remote/remote_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 7a0c1f6..7f3e833 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -609,6 +609,7 @@ doRemoteOpen(virConnectPtr conn, priv-is_secure = 1; #else (void)sanity; +(void)verify; virReportError(VIR_ERR_INVALID_ARG, %s, _(GNUTLS support not available in this build)); goto failed; -- 1.8.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] build: avoid build failure without polkit
rpmbuild of mingw-libvirt.spec failed with: GEN libvirt.syms GEN libvirt_qemu.def cat: libvirt_access.syms: No such file or directory cat: libvirt_access_qemu.syms: No such file or directory cat: libvirt_access_lxc.syms: No such file or directory I traced this to unconditionally trying to use the ACL .syms files, even when polkit isn't in use. build: avoid build failure without polkit * src/Makefile.am (USED_SYM_FILES): Mark access driver symbols according to use. --- Even though this fixes a build-breaker (./autobuild.sh), I'm reluctant to push this without review. In particular, I'm worried that I may need a v2 that further conditionalizes whether libvirt_access_qemu.syms is sometimes omitted based on rpm arguments, even if libvirt_access.syms is present. src/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 4cf999d..042bcba 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1469,12 +1469,13 @@ $(ACCESS_DRIVER_POLKIT_POLICY): $(srcdir)/access/viraccessperm.h \ CLEANFILES += $(ACCESS_DRIVER_POLKIT_POLICY) BUILT_SOURCES += $(ACCESS_DRIVER_POLKIT_POLICY) +USED_SYM_FILES += $(ACCESS_DRIVER_SYMFILES) else EXTRA_DIST += $(ACCESS_DRIVER_POLKIT_SOURCES) +SYM_FILES += $(ACCESS_DRIVER_SYMFILES) endif -USED_SYM_FILES += $(ACCESS_DRIVER_SYMFILES) BUILT_SOURCES += $(ACCESS_DRIVER_GENERATED) $(ACCESS_DRIVER_SYMFILES) CLEANFILES += $(ACCESS_DRIVER_GENERATED) $(ACCESS_DRIVER_SYMFILES) -- 1.8.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On 06/28/2013 08:32 AM, Dario Faggioli wrote: Hi Jim, Everyone, First patch series, so maybe a small introduction is required: I'm Dario and I work for Citrix on improving the NUMA support of Xen. Welcome Dario! This patch series implements some of the missing bits and pieces, in the libxl driver, regarding obtaining per-host and per-domain NUMA related information. It's not the full libvirt NUMA interface, since we don't have all we would need for that in Xen yet (we will in the next version, 4.4), but it's certainly better than having nothing! :-) Yep, incremental improvements are fine. Basically, I'm enhancing capability reporting, to cover NUMA topology (patch 01), and I'm implementing nodeGetCellsFreeMemory (patch 02) and virDomainGetNumaParameters (patch 04) for the libxl driver. This last one requires at least Xen 4.3, so I put the implementation within the proper #ifdef-ery. Ok, I'll comment in the individual patches too. What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! I think we'll need another libvirt dev more familiar with this to verify, but afaict advertising that the driver supports VIR_TYPED_PARAM_STRING is required when returning a string in virTypedParam, for compatibility with older libvirt clients. Without it, strings wouldn't be returned to newer clients that support VIR_TYPED_PARAM_STRING. In particular, should I have added more of those flags = ~VIR_TYPED_PARAM_STRING_OKAY; statements, as it happens in the qemu driver? If yes, in which functions? Once the driver advertises VIR_TYPED_PARAM_STRING, I think the functions taking virTypedParamPtr as a parameter must accommodate that, at least the getters. E.g. qemuDomainGetSchedulerParametersFlags() in the qemu driver has virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | VIR_DOMAIN_AFFECT_CONFIG | VIR_TYPED_PARAM_STRING_OKAY, -1); /* We don't return strings, and thus trivially support this flag. */ flags = ~VIR_TYPED_PARAM_STRING_OKAY; I think the same applies for libxlDomainGetSchedulerParametersFlags(), which looks to be the only getter function in the libxl driver taking virTypedParam. Finally, allow me to say that it was a while that I wanted start hacking a bit on libvirt. I'm really glad I've eventually been able to do so, and I definitely plan to continue (with particular focus on NUMA related stuff). Great to hear and looking forward to your work! Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] libxl: implement some chuncks of the NUMA interface
On 07/01/2013 03:20 PM, Jim Fehlig wrote: What I'm really not sure about is patch 03, which is something I need if I want patch 04 to function properly. Basically it is about advertising that the libxl driver supports VIR_TYPED_PARAM_STRING. I looked at how that is done in the qemu driver, but I'm not entirely sure I completely understood the logic behind it, so, please, tell me if I missed or misinterpreted anything! I think we'll need another libvirt dev more familiar with this to verify, but afaict advertising that the driver supports VIR_TYPED_PARAM_STRING is required when returning a string in virTypedParam, for compatibility with older libvirt clients. Without it, strings wouldn't be returned to newer clients that support VIR_TYPED_PARAM_STRING. Any new API added after VIR_TYPED_PARAM_STRING was added can unconditionally assume that all callers are prepared to handle the string. But for APIs that were created before string support was added, even if your driver doesn't implement the API until now, you are correct that you must advertise support for strings before returning any strings. About the only API I know of off-hand that uses typed parameters but was added after string support is the latest incantation of migration via parameters. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: add macvlan delete to qemuDomainAttachNetDevice cleanup
On 07/01/2013 11:04 AM, Viktor Mihajlovski wrote:
From: Matthew Rosato mjros...@linux.vnet.ibm.com
If an error occurs during qemuDomainAttachNetDevice after the macvtap
was created in qemuPhysIfaceConnect, the macvtap device gets left behind.
This patch adds code to the cleanup routine to delete the macvtap.
Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com
Reviewed-by: Viktor Mihajlovski mihaj...@linux.vnet.ibm.com
---
src/qemu/qemu_hotplug.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 46875ad..c6045a0 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -965,6 +965,16 @@ cleanup:
if (iface_connected) {
virDomainConfNWFilterTeardown(net);
+if (virDomainNetGetActualType(net) ==
VIR_DOMAIN_NET_TYPE_DIRECT) {
+ignore_value(virNetDevMacVLanDeleteWithVPortProfile(
+ net-ifname, net-mac,
+ virDomainNetGetActualDirectDev(net),
+ virDomainNetGetActualDirectMode(net),
+ virDomainNetGetActualVirtPortProfile(net),
+ cfg-stateDir));
+VIR_FREE(net-ifname);
+}
+
This is a good catch, but incomplete. If you search for other
occurrences of virDomainConfNWFilterTeardown() and
qemuPhysIfaceConnect(), you will find the same problem exists in two
other places in the code:
qemuBuildInterfaceCommandLine (during error cleanup, needs to be called
for the one interface that was partially
created)
qemuBuildCommandLine (during error cleanup, needs to be called
for all interfaces that were completely
created (up to last_good_net))
We really should fix them all in one patch, since they are all the same
problem.
(Ideally, *all* guest interface setup for each interface should be
handled in a single function, and that function should be in the network
driver (networkReleaseActualDevice() seems properly situated). That way
it could be put behind an RPC, and the non-privileged libvirtd could
call it too (with proper credentials). That is a larger problem, though.)
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/4] libxl: implement NUMA capabilities reporting
On 06/28/2013 08:32 AM, Dario Faggioli wrote:
Starting from Xen 4.2, libxl has all the bits and pieces are in
s/are in/in/
place for retrieving an adequate amount of information about the
host NUMA topology. It is therefore possible, after a bit of
shuffling, to arrange those information in the way libvirt wants
to present them to the outside world.
Therefore, with this patch, the topology section of the host
capabilities is properly populated, when running on Xen, so that
we can figure out whether or not we're running on a NUMA host,
and what its characteristics are.
[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// capabilities
capabilities
host
cpu
topology
cells num='2'
cell id='0'
memory unit='KiB'6291456/memory
cpus num='8'
cpu id='0' socket_id='1' core_id='0' siblings='0-1'/
cpu id='1' socket_id='1' core_id='0' siblings='0-1'/
cpu id='2' socket_id='1' core_id='1' siblings='2-3'/
cpu id='3' socket_id='1' core_id='1' siblings='2-3'/
cpu id='4' socket_id='1' core_id='9' siblings='4-5'/
cpu id='5' socket_id='1' core_id='9' siblings='4-5'/
cpu id='6' socket_id='1' core_id='10' siblings='6-7'/
cpu id='7' socket_id='1' core_id='10' siblings='6-7'/
/cpus
/cell
cell id='1'
memory unit='KiB'6881280/memory
cpus num='8'
cpu id='8' socket_id='0' core_id='0' siblings='8-9'/
cpu id='9' socket_id='0' core_id='0' siblings='8-9'/
cpu id='10' socket_id='0' core_id='1' siblings='10-11'/
cpu id='11' socket_id='0' core_id='1' siblings='10-11'/
cpu id='12' socket_id='0' core_id='9' siblings='12-13'/
cpu id='13' socket_id='0' core_id='9' siblings='12-13'/
cpu id='14' socket_id='0' core_id='10' siblings='14-15'/
cpu id='15' socket_id='0' core_id='10' siblings='14-15'/
/cpus
/cell
/cells
/topology
/host
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
---
src/libxl/libxl_conf.c | 128
1 file changed, 127 insertions(+), 1 deletion(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index e170357..2a9bcf0 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -163,6 +163,8 @@ libxlBuildCapabilities(virArch hostarch,
static virCapsPtr
libxlMakeCapabilitiesInternal(virArch hostarch,
libxl_physinfo *phy_info,
+ libxl_numainfo *numa_info, int nr_nodes,
+ libxl_cputopology *cpu_topo, int nr_cpus,
The most prominent pattern in libvirt is one param per line after the first, if
they all don't fit in 80 columns. E.g.
libxlMakeCapabilitiesInternal(virArch hostarch,
libxl_physinfo *phy_info,
libxl_numainfo *numa_info,
int nr_nodes,
libxl_cputopology *cpu_topo,
int nr_cpus,
...)
char *capabilities)
{
char *str, *token;
@@ -173,6 +175,12 @@ libxlMakeCapabilitiesInternal(virArch hostarch,
int host_pae = 0;
struct guest_arch guest_archs[32];
int nr_guest_archs = 0;
+
+/* For building NUMA capabilities */
+virCapsHostNUMACellCPUPtr *cpus = NULL;
+int *nr_cpus_node = NULL;
+bool numa_failed = false;
+
No need for the extra whitespace between these local variables.
virCapsPtr caps = NULL;
memset(guest_archs, 0, sizeof(guest_archs));
@@ -280,6 +288,100 @@ libxlMakeCapabilitiesInternal(virArch hostarch,
nr_guest_archs)) == NULL)
goto no_memory;
+/* What about NUMA? */
What about it? I think the comment should just say Include NUMA information if
available or similar :).
+if (!numa_info || !cpu_topo)
+return caps;
+
+if (VIR_ALLOC_N(cpus, nr_nodes))
+goto no_memory;
+memset(cpus, 0, sizeof(cpus) * nr_nodes);
VIR_ALLOC_N will already zero-fill the memory. From its' documentation in
viralloc.h
* Allocate an array of 'count' elements, each sizeof(*ptr)
* bytes long and store the address of allocated memory in
* 'ptr'. Fill the newly allocated memory with zeros.
+
+if (VIR_ALLOC_N(nr_cpus_node, nr_nodes)) {
+VIR_FREE(cpus);
+goto no_memory;
+}
+memset(nr_cpus_node, 0, sizeof(nr_cpus_node) * nr_nodes);
Same here.
+
+/* For each node, prepare a list of CPUs belonging to that node */
+for (i = 0; i nr_cpus; i++) {
+int node = cpu_topo[i].node;
+
+if (cpu_topo[i].core ==
[libvirt] [PATCH] build: configure must not affect tarball contents
On mingw, configure sets the name of the lxc symfile to libvirt_lxc.defs rather than libvirt_lxc.syms. But tarballs must be arch-independent, regardless of the configure options used for the tree where we ran 'make dist'. This led to the following failure in autobuild.sh: CCLD libvirt-lxc.la CCLD libvirt-qemu.la /usr/lib64/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: cannot find libvirt_lxc.def: No such file or directory collect2: error: ld returned 1 exit status make[3]: *** [libvirt-lxc.la] Error 1 make[3]: *** Waiting for unfinished jobs We were already doing the right thing with libvirt_qemu.syms. * src/Makefile.am (EXTRA_DIST): Don't ship a built file which depends on configure for its final name. Signed-off-by: Eric Blake ebl...@redhat.com --- Pushing under the build-breaker rule. src/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 042bcba..1a64855 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1861,7 +1861,6 @@ libvirt_lxc_la_LDFLAGS = \ $(NULL) libvirt_lxc_la_CFLAGS = $(AM_CFLAGS) libvirt_lxc_la_LIBADD = libvirt.la $(CYGWIN_EXTRA_LIBADD) -EXTRA_DIST += $(LIBVIRT_LXC_SYMBOL_FILE) lockdriverdir = $(libdir)/libvirt/lock-driver lockdriver_LTLIBRARIES = -- 1.8.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/4] libxl: advertise the support for VIR_TYPED_PARAM_STRING
On 06/28/2013 08:32 AM, Dario Faggioli wrote:
domainGetNumaParameters has a string typed parameter, hence it
is necessary for the libxl driver to support this.
This change implements the connectSupportsFeature hook for the
libxl driver, advertising that VIR_DRV_FEATURE_TYPED_PARAM_STRING
is something good to go.
s/something good to go/supported/
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Eric Blake ebl...@redhat.com
---
src/libxl/libxl_driver.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index a3a9171..53af609 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4660,6 +4660,20 @@ libxlConnectListAllDomains(virConnectPtr conn,
return ret;
}
+/* Which features are supported by this driver? */
+static int
+libxlConnectSupportsFeature(virConnectPtr conn, int feature)
+{
+if (virConnectSupportsFeatureEnsureACL(conn) 0)
+return -1;
+
+switch (feature) {
+case VIR_DRV_FEATURE_TYPED_PARAM_STRING:
+return 1;
+default:
+return 0;
+}
+}
static virDriver libxlDriver = {
@@ -4740,6 +4754,7 @@ static virDriver libxlDriver = {
.connectDomainEventRegisterAny = libxlConnectDomainEventRegisterAny, /*
0.9.0 */
.connectDomainEventDeregisterAny = libxlConnectDomainEventDeregisterAny,
/* 0.9.0 */
.connectIsAlive = libxlConnectIsAlive, /* 0.9.8 */
+.connectSupportsFeature = libxlConnectSupportsFeature, /* 1.1.1 */
};
static virStateDriver libxlStateDriver = {
As was mentioned in the reply to 0/4, libxlDomainGetSchedulerParametersFlags()
will have to accommodate this change.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/4] libxl: implement per NUMA node free memory reporting
On 06/28/2013 08:32 AM, Dario Faggioli wrote:
By providing the implementation of nodeGetCellsFreeMemory for
the driver. This is all just a matter of properly formatting, in
a way that libvirt like, what Xen provides via libxl_get_numainfo().
[raistlin@Zhaman ~]$ sudo virsh --connect xen:/// freecell --all
0: 25004 KiB
1: 105848 KiB
Total: 130852 KiB
Yeah, rather straight forward patch, which looks good on my non-NUMA machine as
well
# virsh freecell --all
0:7287216 KiB
Total:7287216 KiB
# virsh freecell --cellno 0
0: 7287216 KiB
ACK and pushed.
Regards,
Jim
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
---
src/libxl/libxl_driver.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 9f52394..a3a9171 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -4098,6 +4098,51 @@ libxlNodeGetFreeMemory(virConnectPtr conn)
}
static int
+libxlNodeGetCellsFreeMemory(virConnectPtr conn,
+unsigned long long *freeMems,
+int startCell,
+int maxCells)
+{
+int n, lastCell, numCells;
+int ret = -1, nr_nodes = 0;
+libxl_numainfo *numa_info = NULL;
+libxlDriverPrivatePtr driver = conn-privateData;
+
+if (virNodeGetCellsFreeMemoryEnsureACL(conn) 0)
+return -1;
+
+/* Early failure is probably worth just a warning */
+numa_info = libxl_get_numainfo(driver-ctx, nr_nodes);
+if (numa_info == NULL || nr_nodes == 0) {
+VIR_WARN(libxl_get_numainfo failed to retrieve NUMA data);
+return 0;
+}
+
+/* Check/sanitize the cell range */
+if (startCell nr_nodes) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(start cell %d out of range (0-%d)),
+ startCell, nr_nodes);
+goto cleanup;
+}
+lastCell = startCell + maxCells - 1;
+if (lastCell nr_nodes)
+lastCell = nr_nodes;
+
+for (numCells = 0, n = startCell; n = lastCell; n++) {
+if (numa_info[n].size == LIBXL_NUMAINFO_INVALID_ENTRY)
+freeMems[numCells++] = 0;
+else
+freeMems[numCells++] = numa_info[n].free;
+}
+ret = numCells;
+
+cleanup:
+libxl_numainfo_list_free(numa_info, nr_nodes);
+return ret;
+}
+
+static int
libxlConnectDomainEventRegister(virConnectPtr conn,
virConnectDomainEventCallback callback, void
*opaque,
virFreeCallback freecb)
@@ -4683,6 +4728,7 @@ static virDriver libxlDriver = {
.domainSetSchedulerParameters = libxlDomainSetSchedulerParameters, /*
0.9.0 */
.domainSetSchedulerParametersFlags =
libxlDomainSetSchedulerParametersFlags, /* 0.9.2 */
.nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
+.nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory, /* 1.1.1 */
.connectDomainEventRegister = libxlConnectDomainEventRegister, /* 0.9.0 */
.connectDomainEventDeregister = libxlConnectDomainEventDeregister, /*
0.9.0 */
.domainManagedSave = libxlDomainManagedSave, /* 0.9.2 */
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Biweekly upstream qemu-kvm test report - July 1st, 2013
Adding Libvirt list. Thanks, Shastri Original Message Subject:Biweekly upstream qemu-kvm test report - July 1st, 2013 Date: Mon, 01 Jul 2013 19:45:32 +0530 From: chandrashekar shastri cshas...@linux.vnet.ibm.com To: qemu-de...@nongnu.org, ltc-...@lists.linux.ibm.com, virt-test-de...@redhat.com Hi, Please find the status of the upstream testing: Kernel : 3.10.0-rc5+ Qemu : 1.5.50 Libvirt : 1.0.6 Total number of bugs filed : 6 Bugs filed in this week : 5 Qemu Bugs in Launchpad : 1) 1192499 - virsh migration copy-storage-all fails with Unable to read from monitor: Connection reset by peer 2) 1192847 - NMI watchdog fails to increment the NMI counter in /proc/interrupts 3) 1195170 - cpu hot-add doesn't work with upstream qemu 1.5.50 Libvirt Bugs Redhat Bugzilla: 1) 979260 - cpu hot-add doesn't work with upstream libvirt 1.0.6 + qemu 1.5.50 2) 979360 - Libvirt fails to Bootstrap fails for local gnulib with 1.0. Features tested in this week: 1. NMI Watchdog 2. Live Migration (with and without shared Storage) 3. CPU hotplug 4. QMP with latest qemu Features that will be taken up in the next cycle: 1. Chardev hotplug 2. VirtIO-scsi 3. Virt Guest Suspend Hibernate Thanks, Shastri -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
