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
--
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 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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
23 matches
Mail list logo
