Re: [Qemu-devel] Mount image file feature

[Programmingkid]

On Aug 29, 2015, at 3:34 PM, Max Reitz wrote:

> On 29.08.2015 20:34, MagicCat Software wrote:
>> 
>> 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:
> 
> [snip]
> 
>>>> 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.
> 
> Just want to add that by "machine-friendly" I meant "friendly to an
> upper management layer who will be really, really nice to the user".
> 
>>> 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.
> 
> By definition, a user interface is something the user interacts with.
> People are prone to complain about things they interact with which
> aren't to their exact liking.

But that doesn't mean we just give up. I think this means we should challenge
ourselves to be better.

> 
> What I mean to say is that humans are more complex than machines. It's
> much more difficult to please a human than to please libvirt. I guess.
> 
>> 
>>> 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.
> 
> [citation needed]
> 
>> 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.
> 
> Your point?
> 
> You said applications on Linux are generally more difficult to use than
> comparable applications on OS X, by design. I said "Well, there's
> virt-manager." You say it's available only on Linux. So how does that
> make qemu on Linux more difficult to use than on OS X?

It doesn't make QEMU more difficult to use on Linux. I was just saying this
virt-manager sounds like a good program to have, but isn't available to
Mac OS X users. 

> 
>>>>>> 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.
> 
> Which don't really matter here, because this thread should really not be
> about which OS is better (which is a rather pointless question and even
> more so on the qemu mailing list).
> 
> The point why I brought up libvirt and virt-manager is simply that those
> tools do exactly what you want qemu to do. The ratio of how much GUI
> work we do and how much work we do to have qemu interact nicely with
> libvirt shows to me very clearly that our current direction is to
> separate the frontend (libvirt + GUI) from the backend (qemu).

This philosophy doesn't have to be universal. There might be Linux
users who don't want to use virt-manager but who still want a
nice GUI to use. Lets give the user the power to decide what
GUI to use.

> 
> It's a pity that libvirt is not available for OS X, but in my humble
> opinion that's libvirt's fault and not qemu's. Putting features into
> qemu we apparently decided to leave to libvirt and any management
> application on top of it doesn't seem quite right.

It doesn't seem quite right to the GTK-Linux people, but it perfectly ok with 
the
cocoa-Macintosh people. Who wouldn't like the idea of making QEMU more
user-friendly. Right now in order to move files between guest and host, the user
has to depend on using an image file as a hard drive. That means shutting down
and restarting the guest a lot. Not fun. The feature I propose would make 
rebooting
the guest a thing of the past. QEMU would be a lot more robust.

> 
> [snip]
> 
>>>> 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.
> 
> I don't know how installing software works under OS X, but as far as I
> can recall, it was pretty similar to most Linux distributions in that
> there are package managers. So you'd install the frontend your heart
> desires and it'd pull in qemu as a dependency. Sometimes package
> managers support optional dependencies, too. So one of qemu's optional
> dependencies might be your frontend. Alternatively, your frontend could
> just be part of the qemu package.

Installing software on Mac OS X is done by simply using a .dmg file and
the default installer application. The user just pushes the install button and
that's it.

> 
> Other than that, the difficulty of having to install two packages
> instead of one doesn't quite strike me as a good argument.

Less stuff to have to install means less of a headache for the user.

> 
>>> 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.
> 
> The thing is that it works on top of libvirt.

Oh. Then it would be harder to port Virt-manager.