Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <address@hidden> writes:

> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>
>> On 31.08.2015 22:33, Programmingkid wrote:
>>> 
>>> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
>> 
>> [snip]
>> 
>>>> The following works for me:
>>>> 
>>>> $ echo foo > bar
>>>> $ x86_64-softmmu/qemu-system-x86_64 -qmp stdio -usb -cdrom
>>>> ~/tmp/archlinux-2015.07.01-dual.iso -enable-kvm -m 512
>>>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
>>>> "package": ""}, "capabilities": []}}
>>>> {'execute': 'qmp_capabilities'}
>>>> {"return": {}}
>>>> {'execute': 'blockdev-add', 'arguments': {'options': {'id': 'usb-image',
>>>> 'driver': 'raw', 'file': {'driver': 'file', 'filename': 'bar'}}}}
>>>> 
>>>> {"return": {}}
>>>> {'execute': 'device_add', 'arguments': {'driver': 'usb-storage', 'id':
>>>> 'usb-disk', 'drive': 'usb-image'}}
>>>> {"return": {}}
>>>> 
>>>> In the VM, before device_add:
>>>> # cat /dev/sda
>>>> cat: /dev/sda: No such file or directory
>>>> 
>>>> After device_add:
>>>> # cat /dev/sda
>>>> foo
>>> 
>>> Is there a function that the GUI could call to send all of the JSON
>>> code as the
>>> argument to execute.
>> 
>> If you put the GUI outside of qemu, it's very simple, obviously, since
>> you then just need to send it to whichever interface you chose to be
>> used for QMP.
>> 
>> (Yes, I'm still strongly encouraging you to write a separate GUI. The
>> only part that I suppose to be more difficult than when putting
>> everything into qemu itself is integrating the guest output into your
>> GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
>> for the start I personally would just use SDL (it does work on OS X,
>> too, doesn't it?)
>
> Yes it does.
>
>> so you get a bare window which is only the guest
>> output, and then put the VM controls into a separate window.)
>> 
>> The nice thing about a GUI outside of qemu, besides looking preferable
>> design-wise to me, is that you can configure the VM offline, too.
>> 
>> 
>> For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
>> doesn't look like it's intended to be used directly. Judging from
>> monitor.c, you'd want to set up a JSON parser, call
>> json_message_parser_init(parser, handle_hmp_command); and then use
>> json_message_parser_feed() to send commands.
>
> Wow, that is a bit overwhelming. I really like what my patch does. It
> just sends a
> command to the monitor as if the user typed it up. Very simple, easy,
> and effective.
> I will never have to look for some poorly documented function again!

On the flip side, you'll never get a patch abusing handle_hmp_command()
or handle_qmp_command() as internal interface committed.

>> So the GUI inside of qemu would probably want to continue to call qmp_*
>> directly, i.e. qmp_blockdev_add() and qmp_device_add().
>> 
>>>> Unplugging the device can be done with device_del; but there is no
>>>> blockdev-del yet, so the image file will remain lingering.
>>> 
>>> If the user decided to use the same image file again, would that be 
>>> possible?
>> 
>> Yes, but you'd have to keep track of the ID you gave it. If you call
>> blockdev-add again, qemu will happily open it anew and then it'll be
>> open twice.
>
> I just call drive_del then device_del. So far so good. I have mounted
> and unmounted the same image file several times without problem.

Wrong order, trap for the unwary.  Let me paste my standard advice:

    drive_del is nasty.  Its purpose is to revoke access to an image
    even when the guest refuses to cooperate.  To the guest, this looks
    like hardware failure.

    If you drive_del before device_del, even a perfectly well-behaved
    guest guest is exposed to a terminally broken device between
    drive_del and completion of unplug.

    Always try a device_del first, and only if that does not complete
    within reasonable time, and you absolutely must revoke access to the
    image, then whack it over the head with drive_del.

Copied from
http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html

I hope we can eventually replace and deprecate drive_del with something
that where the obvious use is the correct one.

[...]