qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: RFC: QMP event notification for disk media eject


From: Markus Armbruster
Subject: Re: [Qemu-devel] Re: RFC: QMP event notification for disk media eject
Date: Tue, 11 Jan 2011 15:29:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 01/11/2011 07:11 AM, Luiz Capitulino wrote:
>> Hi there,
>>
>> I need feedback on a new QMP event.
>>
>> Problem
>> =======
>>
>> There's no way for a management tool to detect that a guest OS has ejected 
>> the
>> media in a CDROM or Floppy disk drive (I'm discarding polling, because it's
>> undesirable at best).
>>
>> The end result is that the management tool can get confused, this is 
>> happening
>> with libvirt when migration is involved: if the guest is saved/restored or
>> migrated, then libvirt will start the guest again with media still present.
>>
>> NOTE: Most of the analysis here was done by Daniel Berrange.
>>
>> Solution
>> ========
>>
>> We need a new QMP event to solve that. There are two possible events, a
>> general one and a very specific one.
>>
>> There are 3 scenarios in which both events should be emitted:
>>
>>   1. When guest OS ejects media
>>   2. When 'eject' monitor command is run
>>   3. When 'change' monitor command is run
>>
>> BLOCK_MEDIA_CHANGE
>> ------------------
>>
>> This is the general event, it's emitted when any removable block device
>> is changed.
>>
>> Ideally, the event should contain two pieces of info:
>>
>>   - qdev device name
>>   - new file path (to allow distinguishing eject from change)
>>
>> Example:
>>
>>    { "event": "BLOCK_MEDIA_CHANGE", "data": { "qdev-id": "myid",
>>                                               "new-path": 
>> "/foo/bar/dir/distro.iso" },
>>                                               ... }
>>    
>
> I think this is short sighted as block devices are not simply
> expressed in terms of new-path.  You would need to do something like:
>
> { 'blockdev': {'file': '/foo/bar/dir/distro.iso', 'cache', 'off', ...}}
>
> And that adds a lot of complexity that I'm not sure is really
> justified.  Tray status is really what you're interested in.

I figure the important bit is the notification that tray status changed.
If management software wants to know more, it can query when it gets the
event.

>                                                               The user
> cannot directly change the media, only the management tools can so why
> would the management tools need to be notified about something that
> they did?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]