[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] qemu and <transient/> disks

On Sat, Jul 21, 2012 at 07:29:00PM +0100, Richard W.M. Jones wrote:
> Partly following up this message:
> https://www.redhat.com/archives/libvirt-users/2011-October/msg00142.html
> > > And what about qemu's option "snapshot=on" ?
> >
> > Unreliable. It won't work with SELinux (since qemu tries to create the
> > snapshot on /tmp), and it makes your guest unmigratable.  I think that
> > it is easier to have libvirt use qemu-img to create a qcow2 wrapper
> > prior to booting the guest, at which point the solution is easier to
> > control from an sVirt perspective, and is more likely to allow us to
> > figure out a way to make things work with migration (at least, I'm
> > hoping I can figure out how to migrate a guest with a transient disk).
> Lack of this feature is pretty annoying, particularly since
> (a) libguestfs needs it and (b) it's a trivial patch to add
> snapshot=on to the qemu driver.  So to concentrate on the two
> objections above:
>  - Why is SELinux concerned about qemu creating and using a file in
>    /tmp?  Obviously it should stop qemu opening and reading random
>    files from /tmp but that would be a different rule surely?

Default labelling of files that are created is done based on the
directory label. Since /tmp is a shared directory, this is suboptimal.
We want snapshot files to go in a directory which is private to

More critically in Fedora 18, /tmp is tmpfs so you don't want
to be using that for arbitrarily large guest disk files.

I agree with the quoted text that libvirt should define a
directory to use for the transient disks under /var/lib/libvirt/images
perhaps, and just use 'qemu-img create' to create that, and the
unlink it once QEMU has started up, so we can auto-cleanup
on QEMU shutdown.

>  - The documentation actually states that using <transient/> may make
>    your guest unable to migrate, and in any case we don't care.

I don't see what's wrong with the docs warning you about this.

> > But if you want to use qemu's snapshot=on in the meantime, you can
> > use the <qemu:commandline> namespace XML to add it.
> Is there an example how to do this?  It seems like it might be
> possible using a global qemu '-set device.<id>.snapshot=on' parameter,
> but how can I know what <id> libvirt will give to a '-drive'
> parameter?  (I found from experimentation that it's something like
> "drive-virtio-disk0", but I can't track down the bit of code that
> produces this string yet ...)

Yes, you can use the -set option as you describe. The ID values
are produced by produced by qemuAssignDeviceAliases in qemu_command.c

|: 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 :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]