On Tue, Sep 20, 2016 at 05:49:17PM +0200, Peter Krempa wrote:
> On Tue, Sep 20, 2016 at 15:21:16 +0100, Daniel Berrange wrote:
> > On Tue, Sep 20, 2016 at 03:53:16PM +0200, Peter Krempa wrote:
> > > On Tue, Sep 20, 2016 at 09:40:22 -0400, Corey S. McQuay wrote:
> > > > Currently Libvirt allows attempts to migrate read only disks. Qemu
> > > > cannot handle this as read only
> > > > disks cannot be written to on the destination system. The end result is
> > > > a cryptic error message
> > > > and a failed migration.
> > >
> > > This is not necessarily true. Read only disks can sometimes be in fact
> > > backed by storage that is writable and it's desired to be migrated.
> > If 'def->readonly' is true, then the security drivers won't allow
> > QEMU to write to the image, regardless of whether the underlying
> > storage is writable.
> That definitely would be just a bug in the implementation rather than a
> reason to do this.
That's not a bug - that's a feature - if the disk is marked readonly,
SELinux is right to prevent QEMU writing to the disk.
> In fact the problem is that qemu itself forbids to write the data to a
> readonly marked block backend, which indeed makes this impossible
> although I'm pretty certain that it worked for me in some configuration.
That's a further layer of protection/complication, but I'm concerned
primarily about fact that libvirt is intentionally blocking writes
> At any rate, checking this on the source of migration is incorrect. The
> destination should do such check if there's currently no way to persuade
> qemu do do it. We still may later find a way and all hosts running older
> versions would be hosed.
So the check would belong in qemuMigrationStartNBDServer, rather than
in the DriveMirror method
|: 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