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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list