于 2011年08月09日 11:02, Dave Allan 写道:
On Tue, Aug 09, 2011 at 10:07:57AM +0800, Osier Yang wrote:
于 2011年08月09日 02:09, Dave Allan 写道:
On Mon, Aug 08, 2011 at 11:53:26AM -0600, Eric Blake wrote:
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.
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.
Yeah, that was my concern about having the media appear back in the
drive following migration that I mentioned in my first response. I
think we're in agreement--I only think we need to poll for the tray
state for on migration so that we can correctly decide whether to
allow the migration if the media backing storage isn't present. I.e.,
if the guest has ejected the media from the drive we can permit
migration if the media isn't present on the dst.
Dave
I'm not sure if we're in agreement, following is my thought
1) trying to solve the problem that ejects the media inside guest
while migration in process (with or without the media source
is removed, if don't remove the media source, we starts guest
on dest with the media inserted incorrectly,
This is the problem addressed by Marcus' tray state migration patches
to qemu that I mentioned in my earlier email, so as long as that work
is accepted by qemu, I don't think we have to worry about this
situation.
if removing it, we fail early before trying executing the qemu
command line while do cgroup setting) doesn't work.
If libvirt queries for whether the guest has ejected the media before
we begin the migration, then we can remove the check for the backing
storage on the dst host. If the guest has ejected the media, we don't
care whether it's present on the dst, which I think is your point 2).
Yes
I'm not 100% convinced that it's a problem even if the user removes
the storage during migration, and if it is, this is the problem that
can be addressed with documenting the restriction that a user cannot
remove the backing storage for media while a migration is in progress.
Since the current restriction is that storage must be identical on src
and dst, this represents something of a relaxation.
Yes, agreed on this in previous mail.
2) But we can do simple checking just before (not during) migration
takes place, (if the media is ejected, we starts the guest on dest
without the media present).
Yes.
3) for the report tray status, we need to wait for the qemu patches
are done. The coming patches of "info block" can't provide enough
info for us.
Right, libvirt can report the media status, but not the tray status.
When qemu provides the tray status libvirt can report that, too.
Dave
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list