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

[Osier Yang]

于 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.

> 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