Re: [Qemu-devel] Mount image file feature

[Max Reitz]

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.

signature.asc
Description: OpenPGP digital signature