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 Regards, Daniel -- |: 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 :|