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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



于 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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]