Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM

[Avi Kivity <avi@redhat.com>]

On 10/27/2009 11:11 AM, Gerd Hoffmann wrote:
> On 10/26/09 17:08, Avi Kivity wrote:
>>> A user starts a VM at a physical box. Everythings fine but he wants to
>>> return to his workstation so he closes the window. He goes back to his
>>> workstation and connects to a VNC server (on a different X server). He
>>> wants to now bring up the guest's display.
>>
>> Users don't have boxes. They have computers. They don't want to open VNC
>> clients and type in meaningless numerical addresses.
>
> A qemu gui can easily hide that it actually uses vnc.  The only thing 
> needed is a connection to the monitor (you'll need that anyway to have 
> your fancy buttons do anything useful).  The GUI can do 'info vnc' to 
> figure how to connect to the vnc server then.

It can't hide the inefficiency introduced by vnc.  It doesn't matter for 
cirrus, but it will matter with more powerful vgpus.

Even if you tunnel gpu commands on vnc, you still have to be able to 
reconstruct your state on client disconnect.  With a native client, a 
disconnect is not posssible, so we can rely on client rendering.

>> They do want GUIs
>> which fit with the OSes theme, cut'n'paste, printing, and shared
>> storage, all easily configurable.
>
> You mean something like virt-manager?

Like virt-manager, but with all the things I mentioned.

> BTW: you can quit and restart virt-manager while your VMs keep running.

Sure, since we don't much care about graphics performance.

>>> This cannot be achieved with a gui in the same process as qemu. Is it
>>> necessary to support? I don't know.
>>
>> In the priority list this is about 3000 places below having nice buttons
>> to eject and insert a CDROM. A user with a "box" would probably want to
>> run the guest on a server (and use vnc, etc.).
>
> Focusing on the users needs *only* doesn't fly.  You want have users 
> and hackers use the same thing, otherwise you'll have a hard time 
> finding developers for the GUI. 

If that's so, we're doomed.  If the only itches scratched are 
deveopers', real users will be left out in the cold (or rather, in the 
evil clutches of those who will scratch their itches).

> Which in turn means placing the GUI into a separate process (which may 
> even run on another machine) is a must-have.

I don't see how this follows.  How does catering to 
developers/power-users imply that can't we have an in-process GUI?

We'll still have vnc for server deployments.

-- 
error compiling committee.c: too many arguments to function