[Top][All Lists]
[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?