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

[Osier Yang]

于 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 at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/libvir-list