Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 31, 2015, at 12:26 PM, Markus Armbruster wrote:

> Programmingkid <address@hidden> writes:
> 
>> On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid <address@hidden> writes:
>>> 
>>>> 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.
>>> 
>>> I think you've used up your "speculation on what Linux users like" quota
>>> on this list for 2015.  Now let's get back on topic.
>>> 
>>> [More snipped...]
>>> 
>>>>>>> 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 :)
>>> 
>>> You're attacking a strawman.
>> 
>> I think the word attack is a little strong. We were just having a
>> little informal
>> conversation.
> 
> We're having a technical argument.  Such arguments can occasionally get
> a little heated, but that's fine, we don't mean each other harm :)
> 
>>              Sorry if the Linux jokes weren't so funny.
> 
> No offense taken.
> 
>>> Nobody is arguing against having a nice
>>> GUI.  My argument is that one application trying to do everything tends
>>> to result in the application doing most of it badly.
>> 
>> That's what you believe? Are you saying if we do add a few features to the 
>> GUI
>> it automatically becomes bad? Isn't that kind of pessimistic? Is all hope 
>> gone?
> 
> I think we QEMU developers have our hands full with our core mission,
> and saddling ourselves with GUI development on top risks failure.
> 
> You're welcome to prove me wrong.
> 
>> Running Virt-manager on Mac OS X isn't currently possible. So my only
>> choice is to advance
>> the GUI.
> 
> Very rarely something is your only choice.
> 
> You could work on libvirt and virt-manager under Mac OS X.  A quick grep
> shows #ifdef __APPLE__ in libvirt sources, which suggests it already
> runs there.
> 
> You could write your own GUI layered on top of QEMU.

I honestly don't know very much about this libvirt, but it will take a lot
of work and effort to make it run on Mac OS X. 


> 
>>         This feature would making transferring files from and to the
>> guest actually easy
>> to do. That sounds like a good idea.
> 
> Plumbing for easy file sharing is part of our core job.  I think Max
> pointed you to the work being done by Stefan (NFS over AF_VSOCK).  A
> less capable, but more portable alternative could be USB MTP.

I was told about this feature. Someone said it wouldn't work on Mac OS X.

> 
>>                                     This patch would only affect Mac
>> OS X users, so Linux
>> users won't notice a difference. No harm done to them.
> 
> There's always the opportunity cost.