Il 06/03/2012 14:33, Michael S. Tsirkin ha scritto: >> > virtio_load checks features that are enabled by the guest and >> > blocks migration if they are not available in the destination >> > host. However, in some cases we can let features through because >> > we know that guests will be able to proceed even without it. >> > >> > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > > So why do we need these hacks? You are saying things > work fine without this information. Then, > why not just have the bit set in supported features always?
Not sure what you mean. virtio-balloon works fine only because our implementation does not set the bit. I found it just by inspection, but it's wrong. If QEMU started setting VIRTIO_F_BALLOON_MUST_TELL_HOST, migration would fail to a version that does not set it. virtio-blk is what prompted the patch and it is a real bug. Updating libvirt on the destination causes the source's scsi=on to become scsi=off on the destination. Then migration fails (it used to crash, Orit fixed the crash, I'm fixing the rest). However, a kernel update can cause the same behavioral change can happen even if VIRTIO_BLK_F_SCSI remains on, so it is not a good reason to fail migration. Paolo
