Re: [libvirt] LPC2011 Virtualization Micro Conf
Hi, For those who are interested, I have posted the notes from the 2011 Linux Plumbers Virtualization micro conference here: http://wiki.linuxplumbersconf.org/2011:virtualization Slides can be found by clicking on the presentation and going onto the Plumbers abstracts. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 15:46, Eric Blake wrote: On 07/20/2011 07:25 AM, Jes Sorensen wrote: I think if libvirt wants qemu to use an fd instead of a file name, it shouldn't pass a file name but an fd in the first place. Which means that the two that we need are support for an fd: protocol (patches on the list, need review), and a way for libvirt to override the backing file of an image. The problem is that QEMU will find backing file file names inside the images which it will be unable to open. How do you suggest we get around that? We've already told you - qemu must have a way to be passed fds which are associated with names, and when a file refers to another backing file by name, then qemu falls back on its fd/name mapping to use the already-passed fd instead. Which implies that someone else, either libvirt or a qemu-maintained libblockformat.so, needs to have a stable interface for parsing the backing file name out of an arbitrary qcow2 file, and that this interface must work no matter how many other extensions are added to qcow2. As I replied to you earlier, libvirt is *not* allowed to be messing with internals of image files! Passing in backing file fds as a result of libvirt messing around in internals of the image headers is utterly broken and is not going to happen! Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 19:47, Eric Blake wrote: On 07/20/2011 11:27 AM, Blue Swirl wrote: I'd avoid any name based access in this case. If QEMU has write access to main file, it could forge the backing file name in main file to point to for example /etc/shadow and then request libvirt to perform the opening. Won't work. Well, it might work within the context of a single qemu process. But when that process ends, then libvirt would have to touch up the qcow2 headers of that file to replace the /etc/shadow name with the real backing file name, otherwise, the next time you restart qemu-img or a new qemu guest using the same image, the information has been lost, since the fd has been closed in the meantime. We really _do_ need a way to give qemu both an fd and the name of the file that the fd is tied to. On Linux, qemu could use /proc/self/fd to reconstruct the name from fd, but that's not portable to other OS. And we've already discussed how in the libvirt model, that libvirt is deemed more secure than qemu. I am sorry, but this is where your assertion fails completely. QEMU cannot trust libvirt being able to parse it's image files correctly, so this is a total no-go. Therefore, I think it is reasonable for qemu to make the assumptions that if it exposes a monitor command where the supervisor (libvirt or otherwise) can pass in both an fd and a file name, that either the supervisor is passing in correct information, or that the bug is in the supervisor and not in qemu if the supervisor passes in wrong information and things blow up. Sorry but this is not a reasonable situation given how you want to abuse it. And the snapshot_blkdev monitor command is a case where qemu needs to create a new qcow2 image on the fly, while referencing the name of an existing file. What backing name do you put in the new qcow2 file unless you already have a name association for all fds already open for the existing backing file? It is more than that, the problem is also there when you try to open an image that has a backing file in an selinux environment where qemu isn't allowed to open the backing file. This problem needs a proper solution which does not involve libvirt messing about in binary files where it has no business of being. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 21:51, Blue Swirl wrote: And the snapshot_blkdev monitor command is a case where qemu needs to create a new qcow2 image on the fly, while referencing the name of an existing file. What backing name do you put in the new qcow2 file unless you already have a name association for all fds already open for the existing backing file? For backing file with original name of /path/in/storage, QEMU could present the fd and the backin path by requesting something like fd:12,/path/in/storage. The next file in chain /path2/file would be fd:12,fd:34,/path2/file. Or if possible, -fd 12 -backing /path/in/storage with spaces and funny characters escaped etc. Rather than trying to do this by mangling files on the disk, I would suggest we allow registering a call-back open function, which calls back into libvirt and requests it to open a given file. It can then do all it's security foo to decide whether or not to allow the file to be open. This is relatively clean and avoids the mess of relying on outside processes messing about in the images. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 11:38, Daniel P. Berrange wrote: On Wed, Jul 20, 2011 at 10:26:49AM +0200, Jes Sorensen wrote: On 07/19/11 18:47, Daniel P. Berrange wrote: On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote: On 07/19/11 16:24, Eric Blake wrote: Besides, I feel that having a well-documented file format, so that independent applications can both parse the same file with the same semantics by obeying the file format specification, is a good design goal. We all know that documentation is rarely uptodate, new features may not get added and libvirt will never be able to keep up. The driver for a file format belongs in QEMU and nowhere else. This would be possible if QEMU to provide a libblockformat.so library which allowed apps to extract metadata from file formats using a stable API. There is no reason for libvirt or any external process to mess about with the internals of image files. You have the same problem if the image file is encrypted. Just repeating libvirt doesn't need todo this many times doesn't make it true. I have described why we need to read the disk image to determine its backing files ahead of QEMU being launched quite clearly. I have pointed out repeatedly why you do not need to do this. It is horrendous that libvirt didn't seek a proper solution to this problem before going on and implementing this current mess. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 11:36, Daniel P. Berrange wrote: On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote: Pardon, but I fail to see the issue here. If QEMU passes a filename back to libvirt, libvirt still gets to make the decision whether or not it is legitimate for QEMU to get that file descriptor or not. It doesn't change anything wrt who actually opens the file, hence the 'trust' is unchanged. To make the decision whether the filename from QEMU is valid, we have to parse the master image header data to see if the filename actually matches the backing file required by the image assigned to the guest. Sorry but that doesn't make any sense. In other words, if someone hacks an image and makes it point to a different file, you are going to allow the backing file to be opened just because it is listed in the image? If this is really the approach you are suggesting, it seems to me the whole 'do not allow random opens on NFS' security thing has gone out the window. To the best of my understanding, the whole idea with selinux attributes was to be able to specify which files are allowed to be opened by a given process. Mapping this to the libvirt model, it should mean libvirt ought to carry a positive list of files that are allowed to be opened, rather than relying on what might be written to an image file. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 12:28, Daniel P. Berrange wrote: On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote: Actually, libvirt should not have to worry if the filename provided by QEMU is valid. I think it should trust QEMU. If QEMU doesn't provide information others can trust; it should be fixed at QEMU side. The security goal of libvirt is to protect the host from a compromised QEMU, therefore QEMU is, by definition, untrusted. Well that part goes both ways. By applying this model you are going to make it a hard requirement for libvirt to be upgraded with QEMU even for smaller updates. We're not fighting over the internals of metadata. We just need to know ahead of launching QEMU, what backing files an image has what format they are in. We do that by reading at the metadata headers of the disk images. We never attempt to write to the disk images. Either someone provides a library todo that, or we write the probing code for each file format in libvirt. Currently we have the latter. This is what I would call fighting with QEMU internals. How do you prevent from concurrency access and modifications? Ideally speacking libvirt should be able to co-exist with foreign implementations, all requesting QEMU. QEMU is *not* yet running at the time libvirt reads the file metadata. Of course it is: hotplug Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 10:36, Kevin Wolf wrote: Am 21.07.2011 10:07, schrieb Jes Sorensen: Rather than trying to do this by mangling files on the disk, I would suggest we allow registering a call-back open function, which calls back into libvirt and requests it to open a given file. It can then do all it's security foo to decide whether or not to allow the file to be open. This is relatively clean and avoids the mess of relying on outside processes messing about in the images. You forget that libvirt parses images exactly to decide whether to allow accesses or not, so they would still do it. Which shouldn't be a big problem anyway as long as the libvirt implementation is compliant to the image format specification (even though it's not nice, of course). As I just responded to Daniel, this doesn't make sense. If libvirt wants to guard against a compromised QEMU, it cannot rely on things written into image files headers by QEMU. If we trust contents of image files, there is no reason not to grant QEMU full access to files on NFS either, as we have effectively already granted that by trusting the image file content. In other words, if the goal is to make this secure, lets make it secure, otherwise, lets stop pretending. I just wonder why libvirt doesn't trust qemu enough that it can open() what it wants, but at the same time relies for this check on information in image files which this very same qemu can modify. Probably for the same reason few QEMU developers trust libvirt Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 10:18, Kevin Wolf wrote: Am 20.07.2011 19:47, schrieb Eric Blake: We really _do_ need a way to give qemu both an fd and the name of the file that the fd is tied to. On Linux, qemu could use /proc/self/fd to reconstruct the name from fd, but that's not portable to other OS. Is there any reason for qemu to know the file name if libvirt wants it to use only pre-opened fds anyway? I don't think it should even know the file name. In this case we shouldn't write backing file filenames into image files, but some sort of libvirt token.. then again that will be a lot of fun if you want to run things on the command line afterwards. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 11:34, Daniel P. Berrange wrote: QEMU is *not* yet running at the time libvirt reads the file metadata. Of course it is: hotplug In the case of hotplug, the hotplug monitor commands have not yet been invoked when libvirt access the file metadata, or the drive has already been unplugged, so there is still no concurrent access to the file by QEMU and libvirt. Unless someone tries to hotplug an image that relies on a backing file already used by another image. While unlikely, it is possible. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 15:07, Markus Armbruster wrote: Jes Sorensen jes.soren...@redhat.com writes: Right, we're stuck with the two horros of NFS and selinux, so we need something that gets around the problem. In a sane world we would simply say 'no NFS, no selinux', but as you say that will never happen. My suggestion of a callback mechanism where libvirt registers the callback with QEMU for open() calls, allowing libvirt to perform the open and return the open file descriptor would get around this problem. No go, I'm afraid. The problem at hand is how to confine the untrusted QEMU process so it can access exactly the resources the guest configuration specifies, no more, no less. When guest configuration says use image A, it really means file A plus certain other resources that are required to use it. For obvious usability reasons, we don't require spelling out certain other if we can safely get the information from A. Example: file foo.qcow2 requires its backing file file foo.img. Obviously, the code to get information from A must be trusted. Therefore, it can't run in the untrusted QEMU process. Example: the proposed callback mechanism. Guest configuration says use image foo.qcow2. Libvirt (or whatever management layer) arranges that the QEMU process can use file foo.qcow2. The QEMU process then uses the callback to gain access to the backing file. Nothing stops it to ask for whatever file it wants. How can libvirt decide whether the file is one of the resources the guest configuration specifies? The only way I can see around having libvirt read resource information from images (preferably via a suitable library provided by QEMU) is to require the administrator to spell out the resouce information. Administrators generally don't fancy spelling out things the computer already knows. As I pointed out in other parts of the discussion, libvirt must carry a complete list of authorized files/devices that a guest is allowed to access. There is no way around this anyway, and since this is the case, it's not a showstopper for using the callback mechanism. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 15:47, Eric Blake wrote: On 07/21/2011 02:40 AM, Jes Sorensen wrote: The security goal of libvirt is to protect the host from a compromised QEMU, therefore QEMU is, by definition, untrusted. Well that part goes both ways. By applying this model you are going to make it a hard requirement for libvirt to be upgraded with QEMU even for smaller updates. Right now, libvirt only needs the name of the backing file and type. How often has the qcow2 file format changed in such a way that that particular information has been incompatibly moved around, so that clients have to learn a new file format in order to parse the information in its new location? The set of information that libvirt needs out of a qcow2 image is relatively small and stable, compared to any other changes being made in the rest of the file format, and the libvirt folks are more than welcome to help review any qcow2 format changes for stability impacts. QED, QCOW3 either way, libvirt should be able to boot a guest with an upgraded QEMU, even if it doesn't support all the features. In this case you are going to provide a hard requirement on libvirt being upgraded in sync. Furthermore, you are forgetting that libvirt already ends up upgrading to pick up new qemu features all the time, not just for qcow2 layout changes. If you are okay with the feature set supported by an older qemu, then you are also okay using an older libvirt that targets just that feature set - you only have to upgrade libvirt when talking to a newer qemu that requires the use of a newer feature set. Older libvirt can generally talk to newer qemu if qemu made backwards-compatible changes. There is a difference between upgrading to pick up additional features and forced upgrade. It is not just a question of libvirt possibly reviewing a file format, it is also having two codebases that needs to be implemented and maintained. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/21/11 16:02, Eric Blake wrote: On 07/21/2011 02:38 AM, Jes Sorensen wrote: On 07/20/11 11:36, Daniel P. Berrange wrote: On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote: Pardon, but I fail to see the issue here. If QEMU passes a filename back to libvirt, libvirt still gets to make the decision whether or not it is legitimate for QEMU to get that file descriptor or not. It doesn't change anything wrt who actually opens the file, hence the 'trust' is unchanged. To make the decision whether the filename from QEMU is valid, we have to parse the master image header data to see if the filename actually matches the backing file required by the image assigned to the guest. Sorry but that doesn't make any sense. In other words, if someone hacks an image and makes it point to a different file, you are going to allow the backing file to be opened just because it is listed in the image? Yes, because the only way someone could hack that image is if they have rights to that file in the first place. And if they have rights to that file in the first place, then they also can call qemu-img to modify that file, or any other number of modifications - but that's not an escalation in privilege, so it is not a security hole. Ehm, we're talking about the case where a guest is able to compromise the QEMU process controlling it. This is what libvirt / selinux is trying to prevent. Now if the guest is able to break out of it's shell, it can modify the disk image headers. Crash the QEMU process and wait for the guest to be rebooted by the admin. Voila we now have access to random files on the NFS store we couldn't reach before. So back to the drawing board, we do have a security problem here To the best of my understanding, the whole idea with selinux attributes was to be able to specify which files are allowed to be opened by a given process. Mapping this to the libvirt model, it should mean libvirt ought to carry a positive list of files that are allowed to be opened, Which it does, by reading the metadata of those files prior to the point of ever handing those files over to an untrusted process - except in one case: right now, libvirt is not validating that a qcow2 file is still in a sane state after a qemu process ends. You have previously explained that anything written to the QEMU header is trusted by libvirt in the first place. rather than relying on what might be written to an image file. Thank you for persisting - you've found another hole that needs to be plugged. It sounds like you are proposing that after a qemu process dies, that libvirt re-reads the qcow2 metadata headers, and validates that the backing file information has not changed in a manner unexpected by libvirt. If it has, then the qemu process that just died was compromised to the point that restarting a new qemu process from the old image is now a security risk. So this is _yet another_ security aspect that needs to be coded into libvirt as part of hardening sVirt. But it is an independent issue of the need for fd passing. No it is not independent, we're back to the point where we started. The issue at hand is still that libvirt has no business messing about in metadata headers of guest images. libvirt has the 'right' to validate file names, but that is not justification in messing about in metadata. Allowing that is an endless cat and mouse hunt of keeping up, which is guaranteed to get out of sync. If this problem is to be fixed, lets fix it correctly. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/19/11 18:46, Daniel P. Berrange wrote: On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote: For fd-passing perhaps we have an opportunity to use a callback mechanism (QEMU request: filename - libvirt response: fd) and do all the image format parsing in QEMU. The reason why libvirt does the parsing of file headers to determine backing files is to maintain the trust boundary. Everything run from the exec() of QEMU onwards is considered untrusted code. So having QEMU parsing the file headers passing back open() requests to libvirt is breaking the trust boundary. Pardon, but I fail to see the issue here. If QEMU passes a filename back to libvirt, libvirt still gets to make the decision whether or not it is legitimate for QEMU to get that file descriptor or not. It doesn't change anything wrt who actually opens the file, hence the 'trust' is unchanged. NB, i'm not happy about libvirt having to have knowledge of file format headers, but we needed something more efficient reliable than invoking qemu-img info parsing the output. Ideally QEMU (or something else) would provide a library libblockformat.so with stable APIs for at least reading metadata about image formats. If it had APIs for image creation, etc too that would be a bonus, but we're more or less ok spawning qemu-img for those cases currently. Even having a library for libvirt to link against is suboptimal here. Two processes shouldn't be fighting over the internals of metadata, the ownership of the metadata belongs solely with QEMU. In addition you have the constant issue of dependencies there, hence if QEMU is updated and it provides a newer block format library, it may prevent libvirt from running forcing an update of libvirt as well. That is not acceptable for development. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/19/11 18:14, Anthony Liguori wrote: As nice as that sentiment is, it will never fly, because it would be a regression in current behavior. The whole reason that the virt_use_nfs SELinux bool exists is that some people are willing to make the partial security tradeoff. Besides, the use of sVirt via SELinux is more than just open() protection - while the current virt_use_nfs bool makes NFS less secure than otherwise possible, it still gives some nice guarantees to the rest of the qemu process such as passthrough accesses to local pci devices. Well leaving things at status quo is not making it worse, it just leaves an evil in place. NFS and SELinux is a fundamental problem with SELinux and NFS. We can piss and moan as much as we want about it but it's reality. SELinux fundamentally requires extended attributes. By the time NFS adds extended attribute support, we'll all be flying around in hover cars. As terrible as NFS is, people use it all of the time. It would be nice if libvirt had the ability to make better use of DAC to support isolation. The fact that MAC is the only way you can do isolation between guests is pretty unfortunate. If I could assign specific UIDs to a guest and use that to enforce isolation, it would go a long ways to solving this problem. Right, we're stuck with the two horros of NFS and selinux, so we need something that gets around the problem. In a sane world we would simply say 'no NFS, no selinux', but as you say that will never happen. My suggestion of a callback mechanism where libvirt registers the callback with QEMU for open() calls, allowing libvirt to perform the open and return the open file descriptor would get around this problem. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/19/11 18:47, Daniel P. Berrange wrote: On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote: On 07/19/11 16:24, Eric Blake wrote: Besides, I feel that having a well-documented file format, so that independent applications can both parse the same file with the same semantics by obeying the file format specification, is a good design goal. We all know that documentation is rarely uptodate, new features may not get added and libvirt will never be able to keep up. The driver for a file format belongs in QEMU and nowhere else. This would be possible if QEMU to provide a libblockformat.so library which allowed apps to extract metadata from file formats using a stable API. There is no reason for libvirt or any external process to mess about with the internals of image files. You have the same problem if the image file is encrypted. Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/20/11 12:01, Kevin Wolf wrote: Right, we're stuck with the two horros of NFS and selinux, so we need something that gets around the problem. In a sane world we would simply say 'no NFS, no selinux', but as you say that will never happen. My suggestion of a callback mechanism where libvirt registers the callback with QEMU for open() calls, allowing libvirt to perform the open and return the open file descriptor would get around this problem. To me this sounds more like a problem than a solution. It basically means that during an open (which may even be initiated by a monitor command), you need monitor interaction. It basically means that open becomes asynchronous, and requires clients to deal with that, which sounds at least interesting... Also you have to add some magic to all places opening something. I think if libvirt wants qemu to use an fd instead of a file name, it shouldn't pass a file name but an fd in the first place. Which means that the two that we need are support for an fd: protocol (patches on the list, need review), and a way for libvirt to override the backing file of an image. The problem is that QEMU will find backing file file names inside the images which it will be unable to open. How do you suggest we get around that? Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
On 07/19/11 16:24, Eric Blake wrote: [adding the libvir-list] On 07/19/2011 08:09 AM, Jes Sorensen wrote: Urgh, libvirt parsing image files is really unfortunate, it really doesn't give me warm fuzzy feelings :( libvirt really should not know about internals of image formats. But even if you add new features to qemu to avoid needing this in the future, it doesn't change the past - libvirt will always have to know how to parse image files understood by older qemu, and so as long as libvirt already knows how to do that parsing, we might as well take advantage of it. What has been done here in the past is plain wrong. Continuing to do it isn't the right thing to do here. Besides, I feel that having a well-documented file format, so that independent applications can both parse the same file with the same semantics by obeying the file format specification, is a good design goal. We all know that documentation is rarely uptodate, new features may not get added and libvirt will never be able to keep up. The driver for a file format belongs in QEMU and nowhere else. It would be nice if libvirt had a way to pass fds for every disk and backing file up front; then, SELinux can work around the lack of NFS per-file labelling by blocking open() in qemu. In fact, this has already been proposed: A cleaner solution seems to have libvirt provide a call-back allowing QEMU to call out and have libvirt open a file descriptor instead. This way libvirt can validate it and open it for QEMU and pass it back. Yes, that could probably be made to work with libvirt. I am a little frustrated this approach wasn't taken up front instead of the evil hack of having libvirt attempt to parse image files. If we cannot do something like this, I would prefer to have backing files on NFS should simply not be supported when running in an selinux setup. As nice as that sentiment is, it will never fly, because it would be a regression in current behavior. The whole reason that the virt_use_nfs SELinux bool exists is that some people are willing to make the partial security tradeoff. Besides, the use of sVirt via SELinux is more than just open() protection - while the current virt_use_nfs bool makes NFS less secure than otherwise possible, it still gives some nice guarantees to the rest of the qemu process such as passthrough accesses to local pci devices. Well leaving things at status quo is not making it worse, it just leaves an evil in place. Just because it is currently not as secure to mix NFS shared storage with backing files doesn't stop some people from wanting to do it [in fact, that's my current development setup - I use qcow2 images on NFS shared storage, keep SELinux enabled, and enable the virt_use_nfs bool]. This discussion is about adding enhancements that make SELinux even more powerful when using NFS shared storage, by adding fd passing (whether libvirt parses in advance, or whether qemu raises an event and requires feedback from libvirt), and not about crippling the existing capability to use the virt_use_nfs selinux bool. I do not believe we should try and add extra interfaces to support something which is inherently broken. This really boils down to whether we should support fd passing for snapshots in the first place. If it is to support the broken setup of libvirt parsing image files, then I am totally against it, if we work on a proper solution that involves this in some way, then we can discuss it. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: API additions for enhanced snapshot support
On 07/08/11 10:58, Stefan Hajnoczi wrote: On Thu, Jul 7, 2011 at 8:34 PM, Eric Blake ebl...@redhat.com wrote: Well, the best thing (from libvirt's point of view) would be if snapshot_blkdev took a single string argument, which is either a /path/to/filename (and qemu does open()) or fd:name notation (to refer to a previously-named fd passed via the getfd monitor command, so that libvirt does open()). This would make SELinux integration easier, as one of the sVirt goals is to get to the point where we can use SELinux to forbid qemu from open()ing files on NFS shares, while still permitting all other operations on already-open fds passed in from libvirt. Today QEMU supports /path/to/filename. An fd argument to snapshot_blkdev requires a little bit of work since the QEMU block layer .bdrv_create() interface takes a filename and tries to create it. Jes: Is the fd argument to snapshot_blkdev in your plans? I only ever heard suggestions for taking fd arguments yesterday, so I cannot say it really is in my plans. If I get a good justification I might be convinced :) Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] LPC2011 Virtualization Micro Conf
Hi, With the success of last year's Virtualization micro-conference track at Linux Plumbers 2010, I have accepted to organize a similar track for Linux Plumbers 2011 in Santa Rosa. Please see the official Linux Plumbers 2011 website for full details about the conference: http://www.linuxplumbersconf.org/2011/ The Linux Plumbers 2011 Virtualization track is focusing on general free software Linux Virtualization. It is not reserved for a specific hypervisor, but will focus on general virtualization issues and in particular collaboration amongst projects. This would include KVM, Xen, QEMU, containers etc. Deadline: - The deadline for submissions is April 30th. Please visit the following link to submit your proposal: http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals Example topics: --- - Kernel and Hypervisor KVM/QEMU/Xen interaction - QEMU integration, sharing of code between the different projects - IO Performance and scalability - Live Migration - Managing and supporting enterprise storage - Support for new hardware features, and/or provide guest access to these features. - Guest agents - Virtualization management tools, libvirt, etc. - Desktop integration - Consumer Electronics device emulation - Custom platform configuration and coordination with the kernel Audience: - Virtualization hypervisor developers, developers of virtualization management tools and applications, embedded virtualization developers, vendors and others. Best regards, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On 04/22/10 20:47, Anthony Liguori wrote: On 04/12/2010 07:23 AM, Jamie Lokier wrote: Some simple but versatile hook ideas: -emulator-append-option (no space splitting, one option, appended) -emulator-append-options (space splitting multiple options) -emulator-prepend-option -emulator-prepend-options -emulator-setenv name=NAMEVALUE/emulator-setenv I'd strongly suggest not focusing on manipulating command line arguments. I think in the not too distant future, few people will pass command line arguments as opposed to just using configuration files. We are very close to being able to cover 90% of current users via the config file. There will always be a place for adding command line parameters for debugging purposes. When you try to debug a problem, the first port of call is to look at the command line arguments libvirt uses to launch qemu and replicate those with addons. It's a nightmare today and you end up losing networking and other things. Having an optional debug options thing that one can set quickly from virt-manager would make it so much easier to retry different settings fast while replicating the setup that is normally run. Having to manually edit xml files for making changes is just not a viable solution. Speaking of which, one problem with the current XML format is that it relies on hard-coding the path to QEMU. Instead if should rely on the system default and provide an optional tag for debugging purposes. That would make it easier to migrate specifications from one OS to another, without manually having to edit the QEMU tag. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/22/10 22:53, Anthony Liguori wrote: On 03/22/2010 04:33 PM, Gerd Hoffmann wrote: libvirt is very unfriendly to qemu hackers. There is no easy way to add command line switches. There is no easy way to get access to the monitor. I can get it done by pointing emulator to a wrapper script and mangle the qemu command line there. But this sucks big time. And it doesn't integrate with libvirt at all. It's not just developers. As we're doing deployments of qemu/kvm, we keep running into the same problem. We realize that we need to use a feature of qemu/kvm that isn't modelled by libvirt today. I've gone as far as to temporarily pausing libvirtd, finding the pty fd from /proc/pid, and hijacking the monitor session temporarily. One problem I have found, and I am not sure how to fix this in this context. Sometimes when hacking on qemu, I want to try out a new qemu binary on an existing image, without replacing the system wide one and may want to pass new command line flags for testing those, plus have access to the monitor. What I do now is to look at the command line arguments of a guest using ps and try and mimic it, but due to the random magic ptys and other stuff, it's practically impossible to replicate a libvirt spawned qemu on the command line. I end up having a somewhat similar command line with everything removed that I cannot replicate. I find it a real problem that libvirt tries to wrap things to the point that an ordinary human cannot read, modify it's configuration or do a simple command line spawn to replicate it, but as I said, I am not sure how to solve the problem. Regards, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/10 11:25, Gerd Hoffmann wrote: On 03/23/10 09:54, Jes Sorensen wrote: One problem I have found, and I am not sure how to fix this in this context. Sometimes when hacking on qemu, I want to try out a new qemu binary on an existing image, without replacing the system wide one and may want to pass new command line flags for testing those, plus have access to the monitor. Works with the wrapper script trick mentioned above. virsh edit $domain grep for emulator make it point to a wrapper script. My setup: [r...@xenb ~]# virsh dumpxml fedora | grep emulator emulator/root/bin/qemu-wrapper/emulator [r...@xenb ~]# cat /root/bin/qemu-wrapper Ah right thanks! However, it's a hack to get around the real problem with libvirt. Not to mention that the output from virsh dumpxml is where you have to cover your eyes and try not getting sick while editing :( Having a normal config file in readable format where you could add regular command line options manually would make life so much easier. Cheers, Jes -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
