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

[Dave Allan]

On Tue, Aug 09, 2011 at 09:58:10AM +0800, Osier Yang wrote:
> 于 2011年08月09日 01:53, Eric Blake 写道:
> >On 08/08/2011 09:22 AM, Dave Allan wrote:
> >>>If the medium is ejected inside guest, and the source of the medium
> >>>is removed or renamed. libvirt will still tries to do cgroup setting
> >>>before starting the guest on dest side, that's the real problem. As
> >>>one will think it's reasonable to remove the source if it's
> >>>ejected. And we can't prevent one remove the source during the
> >>>migration (supposing the removing is before libvirt tries to do
> >>>cgroup setting on dest host.)
> >>
> >>Agreed, but that's a problem that I don't think we can solve except by
> >>documenting the behavior.  The libvirt documentation has always
> >>clearly stated that the storage configuration must be the same on the
> >>src and dst hosts.  We are discussing altering that constraint here in
> >>the case of medium that has been ejected, but I think we can be clear
> >>that the constraint is not being removed and that a guest's storage
> >>configuration must not be changed while a migration is in progress.
> >
> >I thought the qemu folks were working on a series of patches to
> >make cd tray state part of the migration information.  That is, if
> >you start a migration, then a guest ejects the cd, then the
> >destination will correctly see the ejected cd, even though the
> >destination was started with the tray closed.  That is, libvirt
> >should not have to poll on cd tray state in order to correctly
> >migrate, but should be able to poll on cd tray state in order to
> >report tray state to the curious user.
> >
> 
> Agree. I don't known they are working out such patches yet. Only known they
> are trying to work out some event for the tray state.

Markus has submitted patches to qemu to migrate the tray state.  See,
e.g,:

http://lists.gnu.org/archive/html/qemu-devel/2011-07/msg01947.html

so, assuming that work is accepted, eject post-migration-start will
not be a problem.

> >The migration aspect of cd tray state generally has to be solved
> >by qemu - there's nothing libvirt can do if the guest changes cd
> >tray state after migration has started but before it has
> >completed, unless libvirt can poll the source after it has paused
> >but before the destination has been unpaused and issue appropriate
> >monitor commands on the destination to resync state; but that
> >should only be necessary if qemu doesn't migrate cd tray state in
> >the first place, and requires that qemu support tray state monitor
> >commands for libvirt to use.
> >
> 
> As far as I known, qemu still can only report the medium is ejected or
> inserted soon via "info block", and without minitor commands to change
> the tray state, or I missed something?
> 
> Osier
>