于 2011年08月08日 23:22, Dave Allan 写道:
On Mon, Aug 08, 2011 at 10:45:19PM +0800, Osier Yang wrote:
于 2011年08月08日 22:04, Dave Allan 写道:
On Mon, Aug 08, 2011 at 05:47:24PM +0800, Osier Yang wrote:
Hello list,
There is problem of migration if the changedable medium is ejected
inside guest, this is caused by qemu closes the block driver backend
once the medium is ejected, but it doesn't gives a way to let
libvirt known the fact. So, libvirt will try to migrate the guest
with the media still exists. This will cause the failure, as qemu
already closes the block driver backend.
Actually this could also break domain restoring and starting (if the domain
has a managed saving image, supposing the media is ejected before saving
or managed saving).
It's ideal if qemu could provide some event so that libvirt could known the
media is changed immediately, but it's bad news qemu upstream won't make
a patch for this in a short time.
As a alternative solution, they proposed patch to expose the status of
changeable medium via monitor command "info block":
http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00408.html
The output of the improved "info block" looks like below:
(qemu) info block
disk0: removable=0 file=/home/armbru/work/images/test.qcow2
backing_file=test.img ro=0 drv=qcow2 encrypted=0
cd: removable=1 locked=0 ejected file=x.iso ro=1 drv=raw encrypted=0
What libvirt can do with the qemu improvement is checking the meduim status
at the time of migration, but it doesn't kill all the bugs, such as for a
live migration, one can eject the media inside guest just during the migration
process. This probally makes a race and cause the failure just the same.
After thinking about this a bit, I believe it's not a problem. If the
guest has the media in the drive at the start of migration, libvirt
will require the media to be present on the destination.
I guess you mean the migration qemu command line will contains
the media path present. If so, yes, it's true.
If the guest ejects the media subsequent to that check, the
operation of the guest on the dst host will be unaffected. The
guest will have the media available to it, but the guest is not
required to use it. The only question I have is whether the guest
might start on the dst with the media back in the drive, which
would be incorrect.
Sorry, I don't explain the problem clearly enough.
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.
Agree, though changing the doc is not ideal fix, but that's what we can
only do
currently.
Dave
And moreover, this won't solve the problem on restoring and starting
with managed saving image, can't get the medium status as the guest
is not active.
True, but I'm not sure I see an easy solution to that, and I don't
think the lack of solution there should hold up a solution to the
migration problem.
So, I 'm hesitating to use "info block" to resolve the problems, it
can't resolve the root problem thoroughly.
Or I missed some good ideas? Any thought is welcomed, thanks.
By the way, it might be deserving to report the cdrom tray status
using the improved "info block" though, though qemu might keep
improving the command to output more infomation, such as the media
is inserted, but the tray is still open (which means different if we
report the tray status as "close" if "info block" outputs
"inserted", need to change the codes then)?
IMO, qemu should expose, and we should report to the user 4 states:
1) tray closed, media inserted
2) tray open, media inserted
3) tray closed, media removed
4) tray open, media removed
The API for inserting and removing media should be different from
opening and closing the drive.
Agee on this, we need to wait the qemu side tray about patches in
first.
Dave
Patches of qemu side to improve the tray handling:
http://lists.nongnu.org/archive/html/qemu-devel/2011-06/msg00381.html
Regards
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list