[libvirt] How to avoid failure of migration/restoring/starting if cdrom is ejected inside guest?

[Dave Allan]

On Mon, Aug 08, 2011 at 05:47:24PM +0800, Osier Yang wrote:
> Hello list,
> 
> There is problem of migration if the changedable medium is ejected
> inside guest, this is caused by qemu closes the block driver backend
> once the medium is ejected, but it doesn't gives a way to let
> libvirt known the fact.  So, libvirt will try to migrate the guest
> with the media still exists.  This will cause the failure, as qemu
> already closes the block driver backend.
> 
> Actually this could also break domain restoring and starting (if the domain
> has a managed saving image, supposing the media is ejected before saving
> or managed saving).
> 
> It's ideal if qemu could provide some event so that libvirt could known the
> media is changed immediately, but it's bad news qemu upstream won't make
> a patch for this in a short time.
> 
> As a alternative solution, they proposed patch to expose the status of
> changeable medium via monitor command "info block":
> 
> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00408.html
> 
> The output of the improved "info block" looks like below:
> 
> (qemu) info block
> disk0: removable=0 file=/home/armbru/work/images/test.qcow2
> backing_file=test.img ro=0 drv=qcow2 encrypted=0
> cd: removable=1 locked=0 ejected file=x.iso ro=1 drv=raw encrypted=0
> 
> What libvirt can do with the qemu improvement is checking the meduim status
> at the time of migration, but it doesn't kill all the bugs, such as for a
> live migration, one can eject the media inside guest just during the migration
> process. This probally makes a race and cause the failure just the same.

After thinking about this a bit, I believe it's not a problem.  If the
guest has the media in the drive at the start of migration, libvirt
will require the media to be present on the destination.  If the guest
ejects the media subsequent to that check, the operation of the guest
on the dst host will be unaffected.  The guest will have the media
available to it, but the guest is not required to use it.  The only
question I have is whether the guest might start on the dst with the
media back in the drive, which would be incorrect.

> And moreover, this won't solve the problem on restoring and starting
> with managed saving image, can't get the medium status as the guest
> is not active.

True, but I'm not sure I see an easy solution to that, and I don't
think the lack of solution there should hold up a solution to the
migration problem.

> So, I 'm hesitating to use "info block" to resolve the problems, it
> can't resolve the root problem thoroughly.
> 
> Or I missed some good ideas? Any thought is welcomed, thanks.
> 
> By the way, it might be deserving to report the cdrom tray status
> using the improved "info block" though, though qemu might keep
> improving the command to output more infomation, such as the media
> is inserted, but the tray is still open (which means different if we
> report the tray status as "close" if "info block" outputs
> "inserted", need to change the codes then)?

IMO, qemu should expose, and we should report to the user 4 states:

1) tray closed, media inserted
2) tray open, media inserted
3) tray closed, media removed
4) tray open, media removed

The API for inserting and removing media should be different from
opening and closing the drive.

Dave

> Patches of qemu side to improve the tray handling:
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg00381.html
> 
> Regards
> Osier
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list