- Devel - libvirt List Archives

Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
by Anthony Liguori 09 Apr '09

09 Apr '09

Paul Brook wrote: >> It has to be some finite amount. You're right, it's arbitrary, but so >> is every other memory limitation we have in QEMU. You could make it >> user configurable but that's just punting the problem. >> >> You have to do some level of buffering. It's unavoidable. If you >> aren't buffering at the event level, you buffer at the socket level, etc. >> > > No you don't. If you use event flags rather than discrete events then you > don't need to buffer at all. You just need to be able to store the state of > each type of event you're going to raise, which should be a bounded set. > > This has its own set of issues - typically race conditions or "lost" events if > the client (libvirt) code isn't written carefully, and means you can't attach > information with an event, only indicate that something happened. > However if the correct model is used (event driven polling rather than purely > event driven) this shouldn't be problem. > It's just deferring the problem. Consider the case of VNC user authentication. You want to have events associated with whenever a user connects and disconnects so you can keep track of who's been on a virtual machine for security purposes. In my model, you record the last 10 minutes worth of events. If a user aggressively connects/reconnects, you could consume a huge amount of memory. You could further limit it by recording only a finite number of events to combat that problem. In your model, the VNC server triggers a user-connected event and a user-disconnected event. This bits are constantly reset which is fine. When libvirt gets around to seeing the events, it know wants to know who's been connecting/disconnecting. Either you show only the current user, which is not terribly useful, or you have the VNC server queue a list of the most recent user connects/disconnects. The problem with this model is that by pushing the queuing to the event generators, you end open up the possibility that someone is going to get something wrong. It's just more places to do it poorly. Regards, Anthony Liguori > Paul >

2 1

Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
by Avi Kivity 09 Apr '09

09 Apr '09

Paul Brook wrote: > No you don't. If you use event flags rather than discrete events then you > don't need to buffer at all. You just need to be able to store the state of > each type of event you're going to raise, which should be a bounded set. > > This has its own set of issues - typically race conditions or "lost" events if > the client (libvirt) code isn't written carefully, and means you can't attach > information with an event, only indicate that something happened. > However if the correct model is used (event driven polling rather than purely > event driven) this shouldn't be problem. > I agree. Every event notification should be readable with an info command. The best way to enforce it is to have the event just say 'something changed' and force the management app to issue an info command to find out what exactly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.

1 0

[libvirt] Problems using unix_sock_group
by Niraj Tolia 09 Apr '09

09 Apr '09

Hi, I am sure I am missing something simple but I can't seem to figure it out. I am trying to allow a non-root user rw access to libvirt 0.6.2. The user is a member of the libvirtd group, unix_sock_group="libvirtd", and unix_sock_rw_perms=0770. However, 'virsh list' doesn't seem to work. The permissions seem correct srwxrwx--- 1 root libvirtd 0 2009-04-08 17:32 libvirt-sock srwxrwxrwx 1 root libvirtd 0 2009-04-08 17:32 libvirt-sock-ro When I strace 'virsh list', it doesn't attempt to connect to /usr/local/var/run/libvirt/libvirt-sock but when I strace 'virsh --readonly list', it successfully connects to the "-ro" socket. configure reported that polkit wasn't configured. This is on a system with Xen. Any ideas on what I might be doing wrong? Thanks, Niraj

1 0

[libvirt] 0.6.2: git mirror tagged, too
by Jim Meyering 08 Apr '09

08 Apr '09

Mark McLoughlin mentioned that the LIBVIRT_0_6_2 tag was not automatically mirrored into the git tree, so I've added it. I also added a signed tag on the same change set. Among other things, that makes it so that "git describe" now generates sensible output for recent changes. But adding all the rest would be nice, too, so I did it with this for tag in $(git tag -l 'LIBVIRT_0_[0-5]*'); do v=$(echo $tag|sed 's/LIBVIRT_/v/;s/_/./g') git tag -s -m $v $v $tag done and pushed those tags.

1 0

[libvirt] migration by libvirt
by Zvi Dubitzky 08 Apr '09

08 Apr '09

Using libvirt virDomainMigrate () do I have to set the target VM with same XML config as the source VM machine before the migrate starts or the source machine Host libvirt takes care of this preparation before it starts the live migration. I am talking about the equivalent of a tcp migration as defined per the qemu/kvm migrate command done via the qemu monitor thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

2 1

[libvirt] Re: [PATCH] Hardware watchdog patch, version 6 (was: Re: [Qemu-devel] [PATCH] Hardware watchdog patch, version 5)
by Hollis Blanchard 08 Apr '09

08 Apr '09

Hi Rich, your watchdog qemu patch is working fine for me (i6300esb, default reset behavior), but I was wondering... how should libvirt find out about the watchdog firing? At that point, I think the next step from libvirt is to send a VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct? -- Hollis Blanchard IBM Linux Technology Center

4 4

[libvirt] Changing the QEMU svn VERSION string
by Anthony Liguori 08 Apr '09

08 Apr '09

Hi, I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing. I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that. Being the nice guy I am, I thought I would check that this didn't make libvirt go bonkers :-) This is the relevant detection code in libvirt: if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", &major, &minor, &micro, &kvm_version) != 4) kvm_version = 0; if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u", &major, &minor, &micro) != 3) goto cleanup2; If I change SVN to 0.11.0-devel, that's going to break the KVM string although the QEMU string will continue to work. Avi could potentially carry a patch to keep it 0.10.x and since kvm-%u will be used to identify features, that should keep things working. Anyone have any objections/suggestions? Regards, Anthony Liguori

7 10

[libvirt] Thoughts on svirt configuration files.
by Daniel J Walsh 08 Apr '09

08 Apr '09

Currently we do not want to hard code virtual image names into libvirt, so libvirt and virtual-manager can use libselinux to get the default image label and process label. svirt_t and svirt_image_t. The idea was one policy writer might want his virtual images labeled differently than another. One problem with this is I added to interfaces one for the domain, and one for the image label. Now we realize we have other images. We have process Label - svirt_t:MCS Exclusive RW Image - svirt_image_t:MCS Shared RW Image - svirt_image_t:s0 Read Only Image - virt_content_t:s0 So I am suggesting that we remove the virtual_image_context file and allowing policy writers to define context in the virtual_domain_context files but have multiple records and multiple fields. Something like a space separated list where each field corresponds to above. system_u:system_r:svirt_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0 Then you could add optional types with similar fields system_u:system_r:svirt_nonet_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0 Since SELinux just returns a path, the virt team could choose the format of the file if a space separated list is not addequate. (xml?) Name Value Pairs? Policy writers would have to enter the format that is chosen. Thoughts? I am thinking we might eventually want to allow an admin to select dynamic labels but specify alternative types. So svirt_t would be default but if someone wanted svirt_nonet_t, they could choose that also and get separation with a different type.

2 2

[libvirt] [PATCH 1/2] VirtualBox support
by Pritesh Kothari 08 Apr '09

08 Apr '09

Hi All, I have attached a patch which when applied on the HEAD as of today would allow virtualbox support in libvirt. It takes cares of all the stuff mentioned on the list earlier. Still if I have missed anything, please do tell me. The patch works very well with the VirtualBox OSE version and the 2.2 release. [PATCH 1/2] contains diff of files already in libvirt. [PATCH 2/2] contains new files needed for VirtualBox support. Regards, Pritesh

1 0

[libvirt] [PATCH] lxc: fix veth off by 1 error
by Serge E. Hallyn 08 Apr '09

08 Apr '09

When not specifying a target for veth device, veth.c:getFreeVethName() is supposed to scan for unused veth devices in /sys/class/net. However, when it finds one, it bumps the index by one before returning it. So, if you have one container running, veth0 is passed into the container, veth1 is taken and still sitting in /sys/class/net. When you now start a second container, getFreeVethName() finds veth0 is unused, but returns 1. Now container creation dies becuase /sys/class/net/veth1 exists. Signed-off-by: Serge Hallyn <serue(a)us.ibm.com> --- src/veth.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/veth.c b/src/veth.c index 93173e4..90c1dcb 100644 --- a/src/veth.c +++ b/src/veth.c @@ -35,12 +35,12 @@ static int getFreeVethName(char *veth, int maxLen, int startDev) { int rc = -1; - int devNum = startDev; + int devNum = startDev-1; char path[PATH_MAX]; do { - snprintf(path, PATH_MAX, "/sys/class/net/veth%d/", devNum); ++devNum; + snprintf(path, PATH_MAX, "/sys/class/net/veth%d/", devNum); } while (virFileExists(path)); snprintf(veth, maxLen, "veth%d", devNum); @@ -97,6 +97,7 @@ int vethCreate(char* veth1, int veth1MaxLen, while ((1 > strlen(veth2)) || STREQ(veth1, veth2)) { vethDev = getFreeVethName(veth2, veth2MaxLen, vethDev); + ++vethDev; DEBUG("assigned veth2: %s", veth2); } -- 1.6.2

2 1