Re: [Qemu-devel] Mount image file feature

[MagicCat Software]

On Aug 29, 2015, at 2:01 PM, Max Reitz wrote:

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

These people have the mentality of terminator robots. 

> User-friendliness is always expensive,
> difficult to maintain, and a neverending source of complaints.

Really? It has been months since Peter Maydell implemented my GUI patches
for the cocoa interface, and I haven't seen a complaint about it yet.

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

If programmers follow good programming practices, the code should be
pretty much maintenance free. But I do understand that public API's do
change over time. 

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

Linux exclusive probably.

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

Linux has a few advantages.

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

Point.

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

It is just a few patches away from working well.

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

Probably true. 

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

Part of making QEMU easier for the user is not having to install more software.
If everything came with in one package, that would be a blessing. 

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

Maybe someone might port Virt-manager to other platforms. Shouldn't be too
difficult. It probably uses multi-platform libraries like GTK.

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