Re: [Qemu-devel] Mount image file feature

[Programmingkid]

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).

If making QEMU more user-friendly is a crime, I plead guilty!

I'm not a Linux user. I am a proud Macintosh user. We Mac users
like our software easy to use. I know this goes against the Linux
way of life. That is why this patch would only work on Mac OS X. 
This will keep QEMU on Linux hard to use... just the way you guys
like it.

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

....lolz

But on the other hand, you get what you pay for.

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

Fact, Apple has made an hypervisor API available as of Mac OS 10.10, so who
knows. Maybe in the future someone will implement KVM support on Mac OS X.

Fact, Apple now gives away Mac OS X for free. Yes I know, it is only for 
Apple-only
hardware still. 

> 
> (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.))

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.

We can have both. Command-line options are there that can turn on or off the 
GUI. 
Example: --disable-gtk.

Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
freezing and restoring a session would be awesome and a real time saver.

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

That is totally fine for the Linux users. If they want to use the command-line 
only, 
let them. They are only hurting themselves :)

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

Public API's are what I will try to use. 

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

Probably wouldn't work, but who knows. If the emulated network card did work on
Mac OS X, then maybe ftp sharing would be possible. Then again QEMU does
have that USB network card. That might work. 

> 
> ===
> 
> 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 will have to examine this information more, but thank you very much for 
helping.
Who knows, maybe someone might port this feature to GTK.