Re: [Qemu-devel] Mount image file feature

[Programmingkid <programmingkidx@gmail.com>]

On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:

> On 31.08.2015 22:13, Programmingkid wrote:
>> 
>> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote:
>> 
>>> On 29.08.2015 17:57, Programmingkid wrote:
>>>> 
>>>> On Aug 29, 2015, at 11:40 AM, Max Reitz wrote:
>>>> 
>>>>> On 27.08.2015 03:05, G 3 wrote:
>>>>>> I want to share files between my host and guest computer. A feature I
>>>>>> want to add would be a new menu item in the Machine menu called "Mount
>>>>>> Image File...". When the user selects it, a file open dialog box
>>>>>> displays. The user can then select the image file with the file he wants
>>>>>> to use. After pushing the OK button, the image file would be mounted
>>>>>> like a USB flash drive. This menu item would only show up if there is
>>>>>> usb support in the guest machine.
>>>>>> 
>>>>>> Would you be open to accepting such a feature?
>>>>> 
>>>>> Generally I'd expect this to be functionality exposed by the management
>>>>> layer. For instance using virt-manager, this can be achived as follows:
>>>>> Switch to "Details", then click "Add Hardware", choose "Storage" and
>>>>> "USB" as the "Bus type". Choose the image, click "Finish", done.
>>>> 
>>>> Isn't Libvirt only available on Linux? This mount image file feature would
>>>> only be on Mac OS X.
>>> 
>>> I'm not sure whether that sounds like a good idea, because then people
>>> using bare qemu on Linux would complain that it isn't available with
>>> Gtk. So if this was to be implemented, it would have to implemented
>>> cross-platform (or at least in a way so it can be used cross-platform
>>> later on).
>>> 
>>>> Mac OS X users don't have all the fancy GUI wrappers
>>>> for QEMU :(
>>> 
>>> Good thing most GNU/Linux distributions are free. ;-)
>>> 
>>> (sorry, could not resist)
>>> 
>>>> Mac OS X is a second-class citizen in the QEMU world...
>>> 
>>> Might have to do something with most (?) of it being non-free and Apple
>>> not caring enough about KVM.
>>> 
>>> (And without KVM, people in turn don't care enough about OS X as a qemu
>>> host.)
>>> 
>>> ((But all of that is pretty biased speculation, of course.))
>>> 
>>>>> The main problem I see with adding this functionality to qemu itself
>>>>> would be having to get even further into the GUI business, which hasn't
>>>>> worked out too well so far…
>>>> 
>>>> That is because of several reasons. One being maintainers not wanting to
>>>> advance the GUI because they feel another program should be QEMU's 
>>>> GUI. I'm sure there are plenty of good ideas that would advance QEMU's
>>>> GUI. These ideas just need to be accepted into QEMU rather than put off.
>>> 
>>> Another is that some people simply feel that qemu should focus on being
>>> a backend than having to mess with frontend work, too. See the recent
>>> discussion on the Gtk code setting the locale and thus breaking QMP for
>>> an example why they have a point.
>>> 
>>> I guess you'll better talk to Markus about this. :-)
>>> 
>>> Quote: "We should've stayed out of the GUI business."
>>> 
>>> (http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03049.html)
>>> 
>>>>> If we didn't care about that, than we'd have to think about the
>>>>> implementation. Internally, we'd probably call QMP's blockdev-add to
>>>>> open the image file, and then QMP's device_add to add the USB device. So
>>>>> then qemu would use its own management interfaces to execute the
>>>>> operation, which seems a bit strange to me, further hinting at the fact
>>>>> that we probably should leave this to the management layer.
>>>> 
>>>> What works does, and it isn't always as nice looking
>>>> as we want it. I am sure we will use some kind of API to implement this feature.
>>> 
>>> Having to deal with ugly legacy cruft from time to time, I don't know
>>> whether "What works, works" is always appropriate.
>>> 
>>>> I just wish there were an easy way to share files between the host and the guest.
>>> 
>>> I don't think using emulated USB storage is the right way to do this,
>>> though. Stefan is working on file sharing using NFS over virtio-vsock,
>>> which seems more appropriate. But then again I don't whether
>>> virtio-vsock will work with an OS X host…
>>> 
>>> ===
>>> 
>>> OK, if you really want to implement it, I'm certainly not the right one
>>> to stop you, so here is how I'd do it:
>>> 
>>> My "BlockBackend and media" series rewrites the "change" HMP/QMP command
>>> to be a macro, basically, that actually executes four lower-level QMP
>>> commands. So this means we have a precedent of "macro" QMP commands, and
>>> this could be extended. So you could add a "macro" QMP command
>>> "usb-storage-insert-file" or something which executes blockdev-add +
>>> device_add (if that works).*
>>> 
>>> Then, if I felt really fancy, I'd add some layer which allows
>>> generically executing QMP commands through the GUI, based on a whitelist
>>> of commands. Each parameter would have to be requested through some GUI
>>> interface, for instance, filenames would be queried through an
>>> appropriate dialog. Ideally, this would be GUI-agnostic, but this may
>>> not be reasonably possible.
>>> 
>>> Then you'd whitelist usb-storage-insert-file (or however it is named),
>>> give it some nice alias and you'd be done.
>>> 
>>> While this would be much work I feel like this would actually be the
>>> nicest solution.
>>> 
>>> This is just a very rough outline, though, and since it somehow goes
>>> against everything qemu's GUI was used for so far (just the most basic
>>> things, basically nothing about controlling the VM except for
>>> Pause/Shutdown/Reboot) I have no idea how it would be received.
>>> 
>>> Max
>>> 
>>> 
>>> *Actually you'd probably want a generic insert-storage-file which takes
>>> the kind of storage device to add as a parameter.
>> 
>> I thought about using add_init_drive() found in device-hotplug.c, 
>> but it is private. Too bad. It looked perfect.  
>> 
>> https://wiki.ubuntu.com/QemuDiskHotplug#Hotplug_USB_Disk
>> This page say talks about how to do it. This is what it said to do:
>> 
>> drive_add 0 if=none,id=usbdisk1,file=/tmp/test.img
>> 
>> Then
>> 
>> device_add usb-storage,id=usbdisk1,drive=usbdisk1
>> 
>> I wasn't able to follow what you said. Do you think you could send me
>> an example of how you think I should do the mounting of the image
>> file?
> 
> That was the "if that works" part. ;-)
> 
> 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. 

> 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?

What about handle_hmp_command() in monitor.c. Would it be ok to
send commands to execute?