Open Stack

On Tue, Feb 18, 2014 at 03:08:59AM -0700, Michael Still wrote:
> On Tue, Feb 18, 2014 at 2:43 AM, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > So I'd saying changing it to 'disk' is out of the question unless
> > we unconditionally use vfat as the filesystem instead of iso9660.
> 
> So, at the moment we conflate a flag about format (iso9660 or vfat)
> with a flag about device type. We could have both as separate flags
> with reasonable defaults. However, at the moment we're pretty much
> presented with a choice of either having a working Windows instance,
> or working block migration. I suspect that's a trade off we don't want
> to have to make.

Why do we need to support both iso9660 and vfat ?  If we only cared
to support vfat, then we could have working Windows and working block
migration.

Incidentally since you say other virt drivers don't use cdrom, does
this mean they only use vfat, or are they using iso9660 + disk and
thus broken for windows too ?

> Do you have any visibility into why cdrom devices don't get migrated
> by libvirt correctly? Is there perhaps a flag to the migrate call we
> could twiddle to make it magically work right?

It seems to be done on the assumption that we only care about
migrating data for writable disks. I think that was just copied
from QEMU's original built-in block migration so that we had
consistent behaviour. So there's no quick fix in libvirt we can
do - we'd probably have to figure out a way to pass in a list of
disks to be mirrored.

        /* skip shared, RO and source-less disks */
        if (disk->shared || disk->readonly || !disk->src)
            continue;

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