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

于 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