Re: [Qemu-devel] Mount image file feature

[Max Reitz]

On 29.08.2015 19:36, 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).
> 
> If making QEMU more user-friendly is a crime, I plead guilty!

Yes, in some people's eyes it is a crime because they say qemu should
rather be machine-friendly. User-friendliness is always expensive,
difficult to maintain, and a neverending source of complaints.

So while it is always a nice thing to have, it comes at a hefty price.

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

Erm, well, I think I won't reply to that other than *cough* virt-manager
*cough*.

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

Working qemu/KVM with a nice management layer on top of it?

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

As far as I know, someone even managed to create a proof-of-concept
implementation of KVM for Windows. Of course it's possible, but it isn't
there yet, and I was just explaining a possible reason why there aren't
(which I'm assuming from what you told me) any nice user-friendly and
feature-rich qemu management tools for OS X.

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

Then you know it's not free.

Also, here I meant "free" as in "freedom", not "free" as in "beer". I
don't know how much of OS X is free software. I know the kernel is, but
most of the things above it aren't, as far as I remember. So that's why
I don't know whether it would actually be reasonably possible for anyone
outside Apple to develop a supported KVM host module.

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

Yep, since this is a well-tested flamewar topic, of course it is.

My point wasn't to make OS X look bad. My point was to explain why OS X
is a second-class citizen in the qemu world, and I feel like there is a
very good reason for it, and that simply is missing KVM support.

Another reason is probably that most of the active qemu developers are
paid to focus on Linux-related things.

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

Might be trivially possible with the things I described, since there is
HMP's savevm/loadvm.

On the other hand, I don't think you'll find (m)any friends for making
qemu's GUI as feature-rich as VBox's. There have long been
"non-invasive" GUIs for managing qemu VMs (such as qtemu), so this isn't
some recent development.

Maybe I can get you interested in writing a management application for
OS X? I do not think that would be more difficult than plugging these
features directly into qemu, and I think everyone would like that idea.
As an OS X user, there shouldn't be any visible difference; and all
non-OS-X users would not have any reason to complain.

Because, as much as you may think this is worthless to hear, what you
are describing is exactly what virt-manager offers.

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

Again, that is not necessarily true. For VMs where I want to get stuff
done, I use libvirt and virt-manager.

Max

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

signature.asc
Description: OpenPGP digital signature