[Qemu-devel] VMWare player

[Qemu-devel] VMWare player

[John R. Hogerhuis]

Barely on-topic, but since VmWare interop crops up from time to time:

http://www.vmware.com/products/player/

I doubt this is targeted at QEMU, but rather at competing with Microsoft
and VirtualPC. That or they are leaving the low-end market for server
consolidation.

This may in fact be as much VmWare as most people would need. Countdown
has started for the first person to create a system image solely from
freeware "VmWare Player" ;-)

-- John.

Re: [Qemu-devel] VMWare player

[Mike Swanson]

Yeah, it barely on topic. But the .vmx files are extremely simple text
files, and qemu-img creates vmdk disk images. Yes, it's possible to
install operating systems solely withing VMware (this is the correct
spelling, btw) Player, but you cannot install VMware Tools, even with
the appropriate (windows|linux|freebsd|netware).iso file.

On 10/21/05, John R. Hogerhuis <jhoger@pobox.com> wrote:
> Barely on-topic, but since VmWare interop crops up from time to time:
>
> http://www.vmware.com/products/player/
>
> I doubt this is targeted at QEMU, but rather at competing with Microsoft
> and VirtualPC. That or they are leaving the low-end market for server
> consolidation.
>
> This may in fact be as much VmWare as most people would need. Countdown
> has started for the first person to create a system image solely from
> freeware "VmWare Player" ;-)
>
> -- John.
--
Mike

Re: [Qemu-devel] VMWare player

[John R. Hogerhuis]

On Fri, 2005-10-21 at 13:22 -0700, Mike Swanson wrote:
> Yeah, it barely on topic. But the .vmx files are extremely simple text
> files, and qemu-img creates vmdk disk images.

That was my first thought when I saw this as well.

>  Yes, it's possible to
> install operating systems solely withing VMware (this is the correct
> spelling, btw) Player, but you cannot install VMware Tools, even with
> the appropriate (windows|linux|freebsd|netware).iso file.
> 

I figured as much. I understand some of what VMware tools has in it. Is
it necessary? QEMU is quite usable without special guest-side utilities.

Or perhaps the issue is that VMWare player will not run anything that
does not have VMware tools installed?

-- John.

Re: [Qemu-devel] VMWare player

[Jim C. Brown]

On Fri, Oct 21, 2005 at 12:29:45PM -0700, John R. Hogerhuis wrote:
> I doubt this is targeted at QEMU,

I agree. It seems it can do 3 things that qemu currently can't: Use certain
types of host hardware (such as DVD or USB), copy & paste between host and
guest, and support drag & drop. None of these is a major issue (and copy and
paste over qemu machines which are networked is possible).

On the other hand, qemu supports using multiple snapshots, networking virtual
machines together, and its user-net/slirp network support is better than
the host only support that VMware Player has. (qemu also have a primitive
video capture ability via the monitor 'snapshot' command, which captures
video stills of the guest into png files.)

> but rather at competing with Microsoft
> and VirtualPC. That or they are leaving the low-end market for server
> consolidation.

Personally, I'd say that the latter is more likely. VMware gets most of the
big bucks from businesses which want to run hundreds of virtual machines.

> 
> This may in fact be as much VMware as most people would need. Countdown
> has started for the first person to create a system image solely from
> freeware "VMware Player" ;-)

Based on the comparison sheet they give, I doubt it is possible. VMware Player
isn't able to create virtual machines. Of course, if you can save changes to
the virtual disk and boot from something other than the hard disk, it might
be possible to use qemu-img to get around this.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[Qemu-devel] VMware Player

[Joe Lee]

I was wondering if there's the capability to have a "vmware player" type 
functionality to qemu. This is just to allow playing or running images 
with out needing to create virtual machines. May this could be a 
separate product. What's everyones thought to this?

Joe

Re: [Qemu-devel] VMware Player

[Paul Brook]

On Wednesday 14 June 2006 15:55, Joe Lee wrote:
> I was wondering if there's the capability to have a "vmware player" type
> functionality to qemu. This is just to allow playing or running images
> with out needing to create virtual machines. May this could be a
> separate product. What's everyones thought to this?

Why on earth would we want to make a crippled version of qemu?

AFAIK "Creating" a VMware virtual machine is just making a config file.
qemu doesn't have config files, so your question makes no sense.

Paul

Re: [Qemu-devel] VMware Player

[Joe Lee]

>
> Why on earth would we want to make a crippled version of qemu?
>
> AFAIK "Creating" a VMware virtual machine is just making a config file.
> qemu doesn't have config files, so your question makes no sense.
Well, I was not thinking or suggesting of a crippled qemu version. I 
asked the question because there are some software
appliances which are pre-built and pre-configured apps that are built on 
a LAMP stack and packaged as a single image
type file. This image file can be downloaded and run on a product 
similar to VMware Player. This is used for quick demo
purposes of an application with out the need to have a full virtual machine.

I am totally new to VM technologies but have played around with VMware 
and the player as well. So, my question was just
an inquiry to see if that capability would make sense on a qemu based 
product that is open source.

However, thanks and appreciated your comments/feedback!

joe







Paul Brook wrote:
> On Wednesday 14 June 2006 15:55, Joe Lee wrote:
>   
>> I was wondering if there's the capability to have a "vmware player" type
>> functionality to qemu. This is just to allow playing or running images
>> with out needing to create virtual machines. May this could be a
>> separate product. What's everyones thought to this?
>>     
>
> Why on earth would we want to make a crippled version of qemu?
>
> AFAIK "Creating" a VMware virtual machine is just making a config file.
> qemu doesn't have config files, so your question makes no sense.
>
> Paul
>
>   

Re: [Qemu-devel] VMware Player

[Paul Brook]

On Wednesday 14 June 2006 16:53, Joe Lee wrote:
> > Why on earth would we want to make a crippled version of qemu?
> >
> > AFAIK "Creating" a VMware virtual machine is just making a config file.
> > qemu doesn't have config files, so your question makes no sense.
>
> Well, I was not thinking or suggesting of a crippled qemu version. I
> asked the question because there are some software
> appliances which are pre-built and pre-configured apps that are built on
> a LAMP stack and packaged as a single image
> type file. This image file can be downloaded and run on a product
> similar to VMware Player. This is used for quick demo
> purposes of an application with out the need to have a full virtual
> machine.

My impression was that these "appliances" are full virtual machines. It's just 
an OS install that's been stripped down and configured to run a single 
application on startup.

Paul

Re: [Qemu-devel] VMware Player

[Oliver Gerlich]

Joe Lee wrote:
>>
>> Why on earth would we want to make a crippled version of qemu?
>>
>> AFAIK "Creating" a VMware virtual machine is just making a config file.
>> qemu doesn't have config files, so your question makes no sense.
> 
> Well, I was not thinking or suggesting of a crippled qemu version. I 
> asked the question because there are some software
> appliances which are pre-built and pre-configured apps that are built on 
> a LAMP stack and packaged as a single image
> type file. This image file can be downloaded and run on a product 
> similar to VMware Player. This is used for quick demo
> purposes of an application with out the need to have a full virtual 
> machine.

What exactly do you mean / what is the actual "use case" for your idea?

Maybe you mean something like this:
http://www.damnsmalllinux.org/usb-qemu.html


Btw. regarding your earlier question about a Qemu GUI similar to VMware: 
AFAIK at least two people have posted GUI patches for Qemu (look in the 
mailing list archive); so far there has been little response to that, 
and I suppose that these patches "just" need testing and some feedback 
(as they seem to be pretty intrusive, with changing the video output and 
the input handling stuff).

Regards,
Oliver

Re: [Qemu-devel] VMware Player

[Joe Lee]

You are right, and the idea is that the person have full interaction 
with the application environment including the underlying LAMP/WAMP 
stack  that has been packaged. Users that want to quickly run and 
test-drive the appliance may not really need a full VM type application. 
Just something that could quickly run the image (appliance).

Joe

Paul Brook wrote:
> On Wednesday 14 June 2006 16:53, Joe Lee wrote:
>   
>>> Why on earth would we want to make a crippled version of qemu?
>>>
>>> AFAIK "Creating" a VMware virtual machine is just making a config file.
>>> qemu doesn't have config files, so your question makes no sense.
>>>       
>> Well, I was not thinking or suggesting of a crippled qemu version. I
>> asked the question because there are some software
>> appliances which are pre-built and pre-configured apps that are built on
>> a LAMP stack and packaged as a single image
>> type file. This image file can be downloaded and run on a product
>> similar to VMware Player. This is used for quick demo
>> purposes of an application with out the need to have a full virtual
>> machine.
>>     
>
> My impression was that these "appliances" are full virtual machines. It's just 
> an OS install that's been stripped down and configured to run a single 
> application on startup.
>
> Paul
>
>   

Re: [Qemu-devel] VMware Player

[Daniel P. Berrange]

On Wed, Jun 14, 2006 at 12:12:43PM -0400, Joe Lee wrote:
> You are right, and the idea is that the person have full interaction 
> with the application environment including the underlying LAMP/WAMP 
> stack  that has been packaged. Users that want to quickly run and 
> test-drive the appliance may not really need a full VM type application. 
> Just something that could quickly run the image (appliance).

An VMWare player "appliance" is really just a disk image & config file.
Running a disk image in QEMU is just a matter of executing

   qemu -hda /path/to/image  

Perhaps adding "-m XXX" to set increased  RAM.

This is no harder to do than using VMWare player

  vmplayer  /path/to/appliance

Since QEMU already understands VMWare disk images, there's even a good
chance that QEMU can run a VMWare "appliance" image itself. So it looks
to me that QEMU is already on a par with VMWare player in terms of being
able to quickly & simply test 'appliance' images.

Dan.

> 
> Joe
> 
> Paul Brook wrote:
> >On Wednesday 14 June 2006 16:53, Joe Lee wrote:
> >  
> >>>Why on earth would we want to make a crippled version of qemu?
> >>>
> >>>AFAIK "Creating" a VMware virtual machine is just making a config file.
> >>>qemu doesn't have config files, so your question makes no sense.
> >>>      
> >>Well, I was not thinking or suggesting of a crippled qemu version. I
> >>asked the question because there are some software
> >>appliances which are pre-built and pre-configured apps that are built on
> >>a LAMP stack and packaged as a single image
> >>type file. This image file can be downloaded and run on a product
> >>similar to VMware Player. This is used for quick demo
> >>purposes of an application with out the need to have a full virtual
> >>machine.
> >>    
> >
> >My impression was that these "appliances" are full virtual machines. It's 
> >just an OS install that's been stripped down and configured to run a 
> >single application on startup.
> >
> >Paul
> >
> >  
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] VMware Player

[Jan Marten Simons]

Am Mittwoch, 14. Juni 2006 17:53 schrieb Joe Lee:
> Well, I was not thinking or suggesting of a crippled qemu version. I
> asked the question because there are some software
> appliances which are pre-built and pre-configured apps that are built on
> a LAMP stack and packaged as a single image
> type file. This image file can be downloaded and run on a product
> similar to VMware Player. 
Have a look at: http://www.oszoo.org/

> This is used for quick demo 
> purposes of an application with out the need to have a full virtual
> machine.
Well, VMware Palyer is the complete VM with some (GUI-)features removed.

Regards,
Jan

Re: [Qemu-devel] VMware Player

[Larry Brigman]

On 6/14/06, Joe Lee <joelee724@gmail.com> wrote:
> >
> > Why on earth would we want to make a crippled version of qemu?
> >
> > AFAIK "Creating" a VMware virtual machine is just making a config file.
> > qemu doesn't have config files, so your question makes no sense.
> Well, I was not thinking or suggesting of a crippled qemu version. I
> asked the question because there are some software
> appliances which are pre-built and pre-configured apps that are built on
> a LAMP stack and packaged as a single image
> type file. This image file can be downloaded and run on a product
> similar to VMware Player. This is used for quick demo
> purposes of an application with out the need to have a full virtual machine.
>
> I am totally new to VM technologies but have played around with VMware
> and the player as well. So, my question was just
> an inquiry to see if that capability would make sense on a qemu based
> product that is open source.
>
> However, thanks and appreciated your comments/feedback!
>
>...(removed additional quoted material)

If you are looking at something like rpath/rbuilder then qemu will run
those images that
are packaged as raw HDD.  If you set the options right the running
image has network access also.  I am trying to figure out how to get
the network access options working
for the windows version of Qemu.

Re: [Qemu-devel] VMware Player

[Jan Marten Simons]

Am Mittwoch, 14. Juni 2006 18:21 schrieb Daniel P. Berrange:
> An VMWare player "appliance" is really just a disk image & config file.
> Running a disk image in QEMU is just a matter of executing
>
>    qemu -hda /path/to/image
>
> Perhaps adding "-m XXX" to set increased  RAM.
>
> This is no harder to do than using VMWare player
>
>   vmplayer  /path/to/appliance
>
> Since QEMU already understands VMWare disk images, there's even a good
> chance that QEMU can run a VMWare "appliance" image itself. So it looks
> to me that QEMU is already on a par with VMWare player in terms of being
> able to quickly & simply test 'appliance' images.
>
> Dan.

To add to this and my previous mail, I'd like to point to ReactOS, which is 
distributed in various forms for simple testing, including a version bundled 
with qemu: http://www.reactos.org/xhtml/en/download.html

With regards,
Jan

PS: As qemu is really small compared to VMware Player, it poses only very 
little overhead to bundle it with the image (one could even hack some sort of 
selfextracting executable qemu+imagefile)

Re: [Qemu-devel] VMware Player

[Mattia Gentilini]

Jan Marten Simons wrote:
> Have a look at: http://www.oszoo.org/
I wanted to suggest this too.
Also check the Free Live OS Zoo, which I'm currently developing:
http://www.oszoo.org/wiki/index.php/Free_Live_OS_Zoo

-- 
|\/|55: Mattia Gentilini e 55 mila euri al mese
|/_| 3-Year Degree in Computer Science | www.getfirefox.com
|\/| University of Bologna, Italy      | www.getthunderbird.com
* Using Linux 2.6.16.16 powered by Galvatron (i686) *

Re: [Qemu-devel] VMware Player

[Joe Lee]

Thanks for the comments below, It seems that QEMU can easily be used to 
run images. I will start to look into the availabe GUI front-ends for QEMU.
- joe

Jan Marten Simons wrote:
> Am Mittwoch, 14. Juni 2006 18:21 schrieb Daniel P. Berrange:
>   
>> An VMWare player "appliance" is really just a disk image & config file.
>> Running a disk image in QEMU is just a matter of executing
>>
>>    qemu -hda /path/to/image
>>
>> Perhaps adding "-m XXX" to set increased  RAM.
>>
>> This is no harder to do than using VMWare player
>>
>>   vmplayer  /path/to/appliance
>>
>> Since QEMU already understands VMWare disk images, there's even a good
>> chance that QEMU can run a VMWare "appliance" image itself. So it looks
>> to me that QEMU is already on a par with VMWare player in terms of being
>> able to quickly & simply test 'appliance' images.
>>
>> Dan.
>>     
>
> To add to this and my previous mail, I'd like to point to ReactOS, which is 
> distributed in various forms for simple testing, including a version bundled 
> with qemu: http://www.reactos.org/xhtml/en/download.html
>
> With regards,
> Jan
>
> PS: As qemu is really small compared to VMware Player, it poses only very 
> little overhead to bundle it with the image (one could even hack some sort of 
> selfextracting executable qemu+imagefile)
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>   

Re: [Qemu-devel] VMware Player

[kadil]

On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:

> Btw. regarding your earlier question about a Qemu GUI similar to VMware: 
> AFAIK at least two people have posted GUI patches for Qemu (look in the 
> mailing list archive); so far there has been little response to that, 
> and I suppose that these patches "just" need testing and some feedback 
> (as they seem to be pretty intrusive, with changing the video output and 
> the input handling stuff).
> 
Real world, gui's are just so easy & desirable, especially if the gui is
consistent across os's, and part of the original distro.  I think
take-up would be huge (well huge-er, current takeup is huge)

Kim

Re: [Qemu-devel] VMware Player

[WaxDragon]

On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
> On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
> Real world, gui's are just so easy & desirable, especially if the gui is
> consistent across os's, and part of the original distro.  I think
> take-up would be huge (well huge-er, current takeup is huge)
>
> Kim
>

Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)

-- 
<GedMurphy> why does the size matter?

Re: [Qemu-devel] VMware Player

[Julian Seward]

On Thursday 15 June 2006 14:18, WaxDragon wrote:
> On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
> > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
> > Real world, gui's are just so easy & desirable, especially if the gui is
> > consistent across os's, and part of the original distro.  I think
> > take-up would be huge (well huge-er, current takeup is huge)
> >
> > Kim
>
> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)

Sure.  But to 'sell' the project to wider audience, which may be
helpful for its longer term development, a GUI is necessary.
Usability engineering isn't as much fun as hacking the JIT, or 
whatever, but in the end usability counts.  A lot.

J

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Julian Seward wrote:

> On Thursday 15 June 2006 14:18, WaxDragon wrote:
> > On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
> > > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
> > > Real world, gui's are just so easy & desirable, especially if the gui is
> > > consistent across os's, and part of the original distro.  I think
> > > take-up would be huge (well huge-er, current takeup is huge)
> > >
> > > Kim
> >
> > Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)
> 
> Sure.  But to 'sell' the project to wider audience, which may be
> helpful for its longer term development, a GUI is necessary.
> Usability engineering isn't as much fun as hacking the JIT,

... which is why most GUIs seem to be cobbled together, are badly designed 
and implemented: either the developer is bored to death, or it is a bad 
(or inexperienced) developer to begin with ...

> or whatever, but in the end usability counts.  A lot.

Which is exactly why I like to wrap up things in a really small Tcl/Tk 
wrapper. And usually after that, the discussions with the employer revolve 
around what color this and that button should have. Sigh.

Ciao,
Dscho

Re: [Qemu-devel] VMware Player

[Joe Lee]

> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0) 
Your right! the keyword is "some" but not all. I think if QEMU is to be 
adopted by the masses it will need to come up with a quality 
GUI-Frontend. However the CLI can always be in place for those who want 
and prefer to use it. Otherwise, I think most users will prefer to stay 
with VMware and especially that there VMware player AND VMware server 
edition is now FREE.

I appreciate the effort that some are making to develop a GUI for QEMU - 
There's a few project I see that trying to achieve this. But, I wish 
they all could come together and work together to develop a nice GUI. I 
would like to see a sub-project exist in the QEMU site so all can come 
and contribute to that effort.

joe



WaxDragon wrote:
> On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
>> On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
>> Real world, gui's are just so easy & desirable, especially if the gui is
>> consistent across os's, and part of the original distro.  I think
>> take-up would be huge (well huge-er, current takeup is huge)
>>
>> Kim
>>
>
> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)
>

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Joe Lee wrote:

> > Some of us appriciate the fact that qemu has no "GUI" per se.  ;0) 
> Your right! the keyword is "some" but not all. I think if QEMU is to be
> adopted by the masses it will need to come up with a quality GUI-Frontend.

You're right! However, as Julian pointed out: it is less than fascinating 
to work on a GUI, _especially_ if it is for the masses who tend to 
criticize without contributing*Footnote 1*.

So, unless the people who want a GUI so badly do it themselves, I think 
they will have to hire somebody to do it for them. Remember: since it is 
free, there is customer, and therefore no customer can be lost!

Ciao,
Dscho

[1] I remember we had a great discussion on this list, where somebody 
thought it would be such a good idea to _demand_ features. And since it is 
Open Source, the good developers should work for free.

Re: [Qemu-devel] VMware Player

[Oliver Gerlich]

Joe Lee wrote:
>> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0) 
> 
> Your right! the keyword is "some" but not all. I think if QEMU is to be 
> adopted by the masses it will need to come up with a quality 
> GUI-Frontend. However the CLI can always be in place for those who want 
> and prefer to use it.  Otherwise, I think most users will prefer to stay
> with VMware and especially that there VMware player AND VMware server 
> edition is now FREE.
> 
> I appreciate the effort that some are making to develop a GUI for QEMU - 
> There's a few project I see that trying to achieve this. But, I wish 
> they all could come together and work together to develop a nice GUI. I 
> would like to see a sub-project exist in the QEMU site so all can come 
> and contribute to that effort.

IIRC Fabrice has (quite some time ago) stated that he'd like to see a 
Qemu GUI that is integrated into the app (ie. not an external 
application that only captures the Qemu window), and also that the GUI 
should be done in GTK (though I'm not sure about the exact wording, so I 
might be spreading false rumours here ;)

This would mean that the next steps for a GUI would be to "migrate" 
input event handling and graphics output from SDL to a GUI toolkit like 
GTK. Incidentally, that is more or less what the patches do which are 
floating around on the mailing list. I guess the reason why they were 
not integrated in CVS is that they are quite big and intrusive, and that 
Fabrice waits for some more feedback and testing of the patches.

So, in the end, testing is probably something that anyone can do who has 
enough spare time and wants to put that time into developing a GUI for 
Qemu :)

Regards,
Oliver

[Qemu-devel] Re: VMware Player

[Ben Pfaff]

Julian Seward <jseward@acm.org> writes:

> On Thursday 15 June 2006 14:18, WaxDragon wrote:
>> On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
>> > On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
>> > Real world, gui's are just so easy & desirable, especially if the gui is
>> > consistent across os's, and part of the original distro.  I think
>> > take-up would be huge (well huge-er, current takeup is huge)
>>
>> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)
>
> Sure.  But to 'sell' the project to wider audience, which may be
> helpful for its longer term development, a GUI is necessary.

For what it's worth, VMware Player doesn't have much of a GUI.
It has about five menu items, a couple of buttons, and maybe one
dialog box.
-- 
"While the Melissa license is a bit unclear, Melissa aggressively
 encourages free distribution of its source code."
--Kevin Dalley <kevin@seti.org>

Re: [Qemu-devel] Re: VMware Player

[Joe Lee]

Good point on that, BUT it's not just about the GUI. It's about an 
"easy" way to install the product and run a given app without the need 
to create/setup a VM - To me that is the benefit of the VMware player. 
However, not much of a big benefit IF QEMU is made easy to install and 
has a nice GUI along with it - IMO.

Joe

Ben Pfaff wrote:
> Julian Seward <jseward@acm.org> writes:
>
>   
>> On Thursday 15 June 2006 14:18, WaxDragon wrote:
>>     
>>> On 6/15/06, kadil <ksadil@bigpond.net.au> wrote:
>>>       
>>>> On Wed, 2006-06-14 at 18:10 +0200, Oliver Gerlich wrote:
>>>> Real world, gui's are just so easy & desirable, especially if the gui is
>>>> consistent across os's, and part of the original distro.  I think
>>>> take-up would be huge (well huge-er, current takeup is huge)
>>>>         
>>> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0)
>>>       
>> Sure.  But to 'sell' the project to wider audience, which may be
>> helpful for its longer term development, a GUI is necessary.
>>     
>
> For what it's worth, VMware Player doesn't have much of a GUI.
> It has about five menu items, a couple of buttons, and maybe one
> dialog box.
>   

Re: [Qemu-devel] Re: VMware Player

[WaxDragon]

On 6/15/06, Joe Lee <joelee724@gmail.com> wrote:
> Good point on that, BUT it's not just about the GUI. It's about an
> "easy" way to install the product and run a given app without the need
> to create/setup a VM - To me that is the benefit of the VMware player.
> However, not much of a big benefit IF QEMU is made easy to install and
> has a nice GUI along with it - IMO.
>
> Joe
>

I've seen several projects ship preinstalled images with prebuilt qemu
binaries, and a script to start it.  It doesn't get much easier than
that.

WD
-- 
<GedMurphy> why does the size matter?

Re: [Qemu-devel] VMware Player

[Joe Lee]

>
> You're right! However, as Julian pointed out: it is less than fascinating 
> to work on a GUI, _especially_ if it is for the masses who tend to 
> criticize without contributing*Footnote 1*.
I am not sure I agree if that thought. It really depends on the mission 
or goal of the project. In the case for QEMU, I am not sure what its 
goal/mission is. Is the project just to scratch an itch to server a few 
people who needs it? Is it to fill a void over what exist in commercial 
software? Or, is the intent to develop something FREE and then offer 
some support service around the product?

As far as users criticizing, that always going to be the case in Open 
Source - Show me a project where users don't criticize. As far as 
contribution goes, not everyone has the talent and ability to contribute 
- Like me. The way I see it, criticizing (when done in a constructive 
way) is not a bad thing. It is what drives the project when others share 
there views on features/functionality good or bad!

-joe


Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Jun 2006, Joe Lee wrote:
>
>   
>>> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0) 
>>>       
>> Your right! the keyword is "some" but not all. I think if QEMU is to be
>> adopted by the masses it will need to come up with a quality GUI-Frontend.
>>     
>
> You're right! However, as Julian pointed out: it is less than fascinating 
> to work on a GUI, _especially_ if it is for the masses who tend to 
> criticize without contributing*Footnote 1*.
>
> So, unless the people who want a GUI so badly do it themselves, I think 
> they will have to hire somebody to do it for them. Remember: since it is 
> free, there is customer, and therefore no customer can be lost!
>
> Ciao,
> Dscho
>
> [1] I remember we had a great discussion on this list, where somebody 
> thought it would be such a good idea to _demand_ features. And since it is 
> Open Source, the good developers should work for free.
>
>
>   

Re: [Qemu-devel] Re: VMware Player

[Joe Lee]

WaxDragon wrote:
> On 6/15/06, Joe Lee <joelee724@gmail.com> wrote:
>> Good point on that, BUT it's not just about the GUI. It's about an
>> "easy" way to install the product and run a given app without the need
>> to create/setup a VM - To me that is the benefit of the VMware player.
>> However, not much of a big benefit IF QEMU is made easy to install and
>> has a nice GUI along with it - IMO.
>>
>> Joe
>>
>
> I've seen several projects ship preinstalled images with prebuilt qemu
> binaries, and a script to start it.  It doesn't get much easier than
> that.
>
> WD

Can you point me to the one you know about?

Joe

Re: [Qemu-devel] VMware Player

[Joe Lee]

Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Jun 2006, Joe Lee wrote:
>
>   
>>> Some of us appriciate the fact that qemu has no "GUI" per se.  ;0) 
>>>       
>> Your right! the keyword is "some" but not all. I think if QEMU is to be
>> adopted by the masses it will need to come up with a quality GUI-Frontend.
>>     
>
> You're right! However, as Julian pointed out: it is less than fascinating 
> to work on a GUI, _especially_ if it is for the masses who tend to 
> criticize without contributing*Footnote 1*.
>
> So, unless the people who want a GUI so badly do it themselves, I think 
> they will have to hire somebody to do it for them. Remember: since it is 
> free, there is customer, and therefore no customer can be lost!
>
> Ciao,
> Dscho
>
> [1] I remember we had a great discussion on this list, where somebody 
> thought it would be such a good idea to _demand_ features. And since it is 
> Open Source, the good developers should work for free.
>
>
>   
BTW, I am curious to know how much would it cost to develop a good 
GUI-Frontend for QEMU that would be comparable to VMware. How much man 
hours would this likely take?

Joe

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Joe Lee wrote:

> > 
> > You're right! However, as Julian pointed out: it is less than fascinating to
> > work on a GUI, _especially_ if it is for the masses who tend to criticize
> > without contributing*Footnote 1*.
>
> I am not sure I agree if that thought. It really depends on the mission or
> goal of the project. In the case for QEMU, I am not sure what its goal/mission
> is. Is the project just to scratch an itch to server a few people who needs
> it? Is it to fill a void over what exist in commercial software? Or, is the
> intent to develop something FREE and then offer some support service around
> the product?

As far as I know: Fabrice started the project because he had this idea 
that translation should be faster than interpreting, and not much more 
difficult.

He proved his point. And many people actually use QEmu, which is all the 
better.

> As far as users criticizing, that always going to be the case in Open 
> Source - Show me a project where users don't criticize.

Yes. And developers will always complain about those who profit and don't 
contribute.

> As far as contribution goes, not everyone has the talent and ability to 
> contribute - Like me.

I doubt that. You _can_ contribute. You actually do it right now.

> The way I see it, criticizing (when done in a constructive way) is not a 
> bad thing. It is what drives the project when others share there views 
> on features/functionality good or bad!

This is a contribution! By telling what is important to you, you 
contribute to the future value of the project (note that I say "project", 
not "product"...)

There is a subtle point-of-no-return though. The story I was referring to, 
was where a person did not contribute, but instead called people names if 
they did not do what she wanted, which was effectively to work hard and 
for free. Which is just not fair.

Ciao,
Dscho

P.S.: Actually, it was a "he", but I say "she" here, because he was a real 
pussy, and I am very happy he left the list.

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Thu, 15 Jun 2006, Joe Lee wrote:

> BTW, I am curious to know how much would it cost to develop a good 
> GUI-Frontend for QEMU that would be comparable to VMware. How much man 
> hours would this likely take?

I do not know VMware. Anybody? I would be interested, too, to know how 
complicated that frontend is... Should not be too difficult to reproduce 
it in Tcl/Tk (with a proper Tcl script as config format).

Ciao,
Dscho

Re: [Qemu-devel] VMware Player

[Joe Lee]

Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Jun 2006, Joe Lee wrote:
>
>   
>> BTW, I am curious to know how much would it cost to develop a good 
>> GUI-Frontend for QEMU that would be comparable to VMware. How much man 
>> hours would this likely take?
>>     
>
> I do not know VMware. Anybody? I would be interested, too, to know how 
> complicated that frontend is... Should not be too difficult to reproduce 
> it in Tcl/Tk (with a proper Tcl script as config format).
>
> Ciao,
> Dscho
>   
I am hoping some experience developers would comment on this!
Joe

Re: [Qemu-devel] VMware Player

[Joe Lee]

Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Jun 2006, Joe Lee wrote:
>
>   
>>> You're right! However, as Julian pointed out: it is less than fascinating to
>>> work on a GUI, _especially_ if it is for the masses who tend to criticize
>>> without contributing*Footnote 1*.
>>>       
>> I am not sure I agree if that thought. It really depends on the mission or
>> goal of the project. In the case for QEMU, I am not sure what its goal/mission
>> is. Is the project just to scratch an itch to server a few people who needs
>> it? Is it to fill a void over what exist in commercial software? Or, is the
>> intent to develop something FREE and then offer some support service around
>> the product?
>>     
>
> As far as I know: Fabrice started the project because he had this idea 
> that translation should be faster than interpreting, and not much more 
> difficult.
>
> He proved his point. And many people actually use QEmu, which is all the 
> better.
>
>   
>> As far as users criticizing, that always going to be the case in Open 
>> Source - Show me a project where users don't criticize.
>>     
>
> Yes. And developers will always complain about those who profit and don't 
> contribute.
>
>   
>> As far as contribution goes, not everyone has the talent and ability to 
>> contribute - Like me.
>>     
>
> I doubt that. You _can_ contribute. You actually do it right now.
>
>   
>> The way I see it, criticizing (when done in a constructive way) is not a 
>> bad thing. It is what drives the project when others share there views 
>> on features/functionality good or bad!
>>     
>
> This is a contribution! By telling what is important to you, you 
> contribute to the future value of the project (note that I say "project", 
> not "product"...)
>
> There is a subtle point-of-no-return though. The story I was referring to, 
> was where a person did not contribute, but instead called people names if 
> they did not do what she wanted, which was effectively to work hard and 
> for free. Which is just not fair.
>
> Ciao,
> Dscho
>
> P.S.: Actually, it was a "he", but I say "she" here, because he was a real 
> pussy, and I am very happy he left the list.
>   
I share your view. Complaining and bitching in the wrong way is not a 
good thing.

Re: [Qemu-devel] VMware Player

[John Morris]

On Thu, 2006-06-15 at 09:18, Joe Lee wrote:

> I appreciate the effort that some are making to develop a GUI for QEMU - 
> There's a few project I see that trying to achieve this. But, I wish 
> they all could come together and work together to develop a nice GUI. I 
> would like to see a sub-project exist in the QEMU site so all can come 
> and contribute to that effort.

Geez, why not ask for world peace while you are at it.  One GUI?  So
which toolkit?  Pick Gtk and watch the K folk whine.  Ok, so KDE it is. 
Oops, now the Gnomes are all over ya.  And of course since I suspect a
non-trivial percentage of QEMU users are on Windows, Solaris, etc. they
ain't gonna like either of those choices much.

Face it, putting a GUI on something like QEMU is going to require at
least a one per desktop/platform effort.  And that can best be kept with
the GNOME/KDE/etc software repositories because they require constant
updating on the schedule of the rest of the desktop environment to stay
current.

Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of
graphical front ends that all make use of them.  Nobody has to totally
reinvent the wheel because those solid CLI only parts can be reused by
each project and each graphical environment gets a totally native (ok,
several) GUI CD/DVD authoring/burning program instead of one crappy
ported program.

-- 
John M.      http://www.beau.org/~jmorris     This post is 100% M$Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r

Re: [Qemu-devel] VMware Player

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Schindelin schrieb:
> Hi,
> 
> On Thu, 15 Jun 2006, Joe Lee wrote:
> 
> 
>>BTW, I am curious to know how much would it cost to develop a good 
>>GUI-Frontend for QEMU that would be comparable to VMware. How much man 
>>hours would this likely take?
> 
> 
> I do not know VMware. Anybody? I would be interested, too, to know how 
> complicated that frontend is...

There are some screenshots of "VMware Workstation" at
http://www.vmware.com (see Products menu). Didn't find screenshots of
"VMware Player" there, but Google image search shows a few for "VMplayer".

> Should not be too difficult to reproduce
> it in Tcl/Tk (with a proper Tcl script as config format).

If you are familiar with Tcl/Tk, maybe you could give some hints on how
to embed the Qemu window into such an app?

I think there are only two ways for making a GUI:
- - embed the Qemu SDL window into another application (there seem to be
various hacks that do this under X11; not sure about Win32)
- - replace Qemu's SDL part with some GUI toolkit (GTK, Tcl/Tk...)

I guess the second way is quite a lot of work.
The first way is a bit "hackish", as eg. events have to propagated from
the GUI app to the Qemu window... how would this work with Tcl/Tk?

Probably with the second way it would also be difficult to display
real-time status info in the GUI (eg. guest CPU load, guest HDD
accesses, network accesses).

Regards,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEkd9lTFOM6DcNJ6cRArqJAKC5wiG3lsVMA5TmNp7EdqRa1cDbrQCeNGI2
8oVTKgDXpLo2QJN0NxQQP/U=
=IACV
-----END PGP SIGNATURE-----

[Qemu-devel] Doing a Tcl/Tk based frontend

[John Morris]

On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote:

> If you are familiar with Tcl/Tk, maybe you could give some hints on how
> to embed the Qemu window into such an app?

Embedding the emulator's window might not be the best way to attack the
problem.  Especially since you would need to be able to detach it to be
able to go full screen.  I have pondered the Tk frontend idea before so
lemme dump my random thoughts on the subject and see how many holes get
punched in em.

How about one Tk window as a 'master controller' for all VMs and each
running VM opens a new window.  The master window gets a tab for each
running VM and a seperate interpreter spawned to monitor the console
(running on stdin/stdout piped back to Tcl) for events and update the
widgets and send commands in response to user input.  That gets you
media insert/remove, serial port attachment, etc.

Doing it that way means QEMU itself requires no modifications, but might
in reality need some small adjustment to make the console interface more
rigid, otherwise I suspect expect would need to get involved to deal
with communications with with the existing console.

-- 
John M.      http://www.beau.org/~jmorris     This post is 100% M$Free!
Geekcode 3.1:GCS C+++ UL++++$ P++ L+++ W++ w--- Y++ b++ 5+++ R tv- e* r

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Fri, 16 Jun 2006, Oliver Gerlich wrote:

> Johannes Schindelin schrieb:
> >
> > On Thu, 15 Jun 2006, Joe Lee wrote:
> >
> >>BTW, I am curious to know how much would it cost to develop a good
> >>GUI-Frontend for QEMU that would be comparable to VMware. How much man
> >>hours would this likely take?
> >
> > I do not know VMware. Anybody? I would be interested, too, to know how
> > complicated that frontend is...
> 
> There are some screenshots of "VMware Workstation" at
> http://www.vmware.com (see Products menu). Didn't find screenshots of
> "VMware Player" there, but Google image search shows a few for "VMplayer".

Thanks. But I would like to know if there is a developer who has 
experience with the GUI. It is one thing to see the GUI, another to work 
with it.

> > Should not be too difficult to reproduce
> > it in Tcl/Tk (with a proper Tcl script as config format).
> 
> If you are familiar with Tcl/Tk, maybe you could give some hints on how
> to embed the Qemu window into such an app?

I would go the easy way: just before starting QEmu, hide the Tk window... 
no need for embedding.

Yes, I know this is a lame answer. But I am quite certain that most users 
would be happy about it. They do not *need* to do something fancy. They 
run the virtual machine, shut it down, and that's it.

Ciao,
Dscho

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Daniel P. Berrange]

On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote:
> On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote:
> 
> > If you are familiar with Tcl/Tk, maybe you could give some hints on how
> > to embed the Qemu window into such an app?
> 
> Embedding the emulator's window might not be the best way to attack the
> problem.  Especially since you would need to be able to detach it to be
> able to go full screen.  I have pondered the Tk frontend idea before so
> lemme dump my random thoughts on the subject and see how many holes get
> punched in em.

With the new VNC server capability there is no need to embed the emulator's
existing window. You can just have a GTK/QT widget which acts as a VNC client
taking the video feed & displaying directly within the GUI management app. 
Similarly you can redirect the QEMU monitor console to a UNIX pipe when 
lauching QEMU, so the management app can fully control the QEMU engine
to do suspend/resume, snapshots, media changesi.

I wrote an GUI app in Python which did the latter already:

http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html

At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't
hook up the display, but with the 0.8.1 release it wouldn't be much effort
to embed the display directly in the app via VNC. So I don't think there 
are any changes required in QEMU itself to be able to create a fully
featured QEMU frontend easily on a par with VMWare Desktop, if not better.

Regards.
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel P. Berrange schrieb:
> On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote:
> 
>>On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote:
>>
>>
>>>If you are familiar with Tcl/Tk, maybe you could give some hints on how
>>>to embed the Qemu window into such an app?
>>
>>Embedding the emulator's window might not be the best way to attack the
>>problem.  Especially since you would need to be able to detach it to be
>>able to go full screen.  I have pondered the Tk frontend idea before so
>>lemme dump my random thoughts on the subject and see how many holes get
>>punched in em.
> 
> 
> With the new VNC server capability there is no need to embed the emulator's
> existing window. You can just have a GTK/QT widget which acts as a VNC client
> taking the video feed & displaying directly within the GUI management app. 
> Similarly you can redirect the QEMU monitor console to a UNIX pipe when 
> lauching QEMU, so the management app can fully control the QEMU engine
> to do suspend/resume, snapshots, media changesi.
> 
> I wrote an GUI app in Python which did the latter already:
> 
> http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html
> 
> At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't
> hook up the display, but with the 0.8.1 release it wouldn't be much effort
> to embed the display directly in the app via VNC. So I don't think there 
> are any changes required in QEMU itself to be able to create a fully
> featured QEMU frontend easily on a par with VMWare Desktop, if not better.
> 
> Regards.
> Dan.

VNC is a good idea... But isn't it a bit "laggy" for this purpose? I
think people accept a laggy mouse cursor in a VNC window that comes over
the network, but won't really accept that in virtual machine that's
running directly on their desktop. OTOH, I'm no VNC expert :) and maybe
there are tricks to speed this up?!

Regards,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEke5ATFOM6DcNJ6cRAoRrAKCh1pM+Ig5WTv4ZeoGSvkjtT7M/mACeM1XL
iH7ztKK9+HwNsnO5EA0XqBA=
=gGkF
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Anthony Liguori]

Daniel P. Berrange wrote:
> On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote:
>   
>> On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote:
>>
>>     
>>> If you are familiar with Tcl/Tk, maybe you could give some hints on how
>>> to embed the Qemu window into such an app?
>>>       
>> Embedding the emulator's window might not be the best way to attack the
>> problem.  Especially since you would need to be able to detach it to be
>> able to go full screen.  I have pondered the Tk frontend idea before so
>> lemme dump my random thoughts on the subject and see how many holes get
>> punched in em.
>>     
>
> With the new VNC server capability there is no need to embed the emulator's
> existing window. You can just have a GTK/QT widget which acts as a VNC client
> taking the video feed & displaying directly within the GUI management app. 
>   

I definitely think this is the write approach too.    I'm still at the 
proof-of-concept phase those.  The VNC client code seems to work well 
(it's asynchronous and uses glib) but I haven't integrated it into a 
widget just yet.

This is coming straight off my hard drive so YMMV.

http://hg.codemonkey.ws/gvnc/

> Similarly you can redirect the QEMU monitor console to a UNIX pipe when 
> lauching QEMU, so the management app can fully control the QEMU engine
> to do suspend/resume, snapshots, media changesi.
>
> I wrote an GUI app in Python which did the latter already:
>
> http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html
>
> At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't
> hook up the display, but with the 0.8.1 release it wouldn't be much effort
> to embed the display directly in the app via VNC. So I don't think there 
>   

The tricky part is the VNC widget.  Reusing any of the existing vnc 
clients isn't really an option.  The client end of the protocol has way 
too many states making a state machine really nasty.

I ended up settling on a coroutine based approach which I'm sure will 
raise some eyes.  Of course, one could easily replace the coroutines 
with threads though (I just have an aversion to threading.

I've also got code laying around for basic software scaling which I also 
think is important for proper fullscreen support.  Just need a little 
more free time :-)

Regards,

Anthony Liguori

> are any changes required in QEMU itself to be able to create a fully
> featured QEMU frontend easily on a par with VMWare Desktop, if not better.
>
> Regards.
> Dan.
>   

Re: [Qemu-devel] VMware Player

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johannes Schindelin schrieb:
> Hi,
> 
> On Fri, 16 Jun 2006, Oliver Gerlich wrote:
> 
> 
>>Johannes Schindelin schrieb:
>>
>>>On Thu, 15 Jun 2006, Joe Lee wrote:
>>>
>>>
>>>>BTW, I am curious to know how much would it cost to develop a good
>>>>GUI-Frontend for QEMU that would be comparable to VMware. How much man
>>>>hours would this likely take?
>>>
>>>I do not know VMware. Anybody? I would be interested, too, to know how
>>>complicated that frontend is...
>>
>>There are some screenshots of "VMware Workstation" at
>>http://www.vmware.com (see Products menu). Didn't find screenshots of
>>"VMware Player" there, but Google image search shows a few for "VMplayer".
> 
> 
> Thanks. But I would like to know if there is a developer who has 
> experience with the GUI. It is one thing to see the GUI, another to work 
> with it.
> 
> 
>>>Should not be too difficult to reproduce
>>>it in Tcl/Tk (with a proper Tcl script as config format).
>>
>>If you are familiar with Tcl/Tk, maybe you could give some hints on how
>>to embed the Qemu window into such an app?
> 
> 
> I would go the easy way: just before starting QEmu, hide the Tk window... 
> no need for embedding.
> 
> Yes, I know this is a lame answer. But I am quite certain that most users 
> would be happy about it. They do not *need* to do something fancy. They 
> run the virtual machine, shut it down, and that's it.

Heh :) that's what the current Qemu GUIs do already (many of which are
mainly configuration GUIs). Thinking about it, at this point maybe an
"official" configuration file format would be useful for all frontends
and would really help unifying the GUIs (there has been a lot of talk
about this already anyway).

Regards,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEke9mTFOM6DcNJ6cRAkLIAKDkkPPgGVR6OHyQ6sD5h71OYO5zYgCgkb6I
KzNbrMmbEBuYzPgQ5fck5BA=
=e/PC
-----END PGP SIGNATURE-----

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Anthony Liguori]

Oliver Gerlich wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>   
> VNC is a good idea... But isn't it a bit "laggy" for this purpose? I
> think people accept a laggy mouse cursor in a VNC window that comes over
> the network, but won't really accept that in virtual machine that's
> running directly on their desktop. OTOH, I'm no VNC expert :) and maybe
> there are tricks to speed this up?!
>   

The right way to solve this is emulation of hardware cursor offloading.  
The problem is that modern desktops like to use colored cursors and the 
current Cirrus emulation only supports monochromatic cursors :-(

Really no way around this without a special guest driver or new VGA 
emulation.

On the other hand, I had toyed with a shared memory based display 
driver.  That would give you more or less equivalent performance.  
However, I really don't think localhost VNC is that bad.

Regards,

Anthony Liguori

> Regards,
> Oliver
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
>
> iD8DBQFEke5ATFOM6DcNJ6cRAoRrAKCh1pM+Ig5WTv4ZeoGSvkjtT7M/mACeM1XL
> iH7ztKK9+HwNsnO5EA0XqBA=
> =gGkF
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Daniel P. Berrange]

On Fri, Jun 16, 2006 at 01:33:26AM +0200, Oliver Gerlich wrote:
> Daniel P. Berrange schrieb:
> > On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote:
> > With the new VNC server capability there is no need to embed the emulator's
> > existing window. You can just have a GTK/QT widget which acts as a VNC client
> > taking the video feed & displaying directly within the GUI management app. 
> > Similarly you can redirect the QEMU monitor console to a UNIX pipe when 
> > lauching QEMU, so the management app can fully control the QEMU engine
> > to do suspend/resume, snapshots, media changesi.
> > 
> > I wrote an GUI app in Python which did the latter already:
> > 
> > http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html
> > 
> > At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't
> > hook up the display, but with the 0.8.1 release it wouldn't be much effort
> > to embed the display directly in the app via VNC. So I don't think there 
> > are any changes required in QEMU itself to be able to create a fully
> > featured QEMU frontend easily on a par with VMWare Desktop, if not better.
> > 
> > Regards.
> > Dan.
> 
> VNC is a good idea... But isn't it a bit "laggy" for this purpose? I
> think people accept a laggy mouse cursor in a VNC window that comes over
> the network, but won't really accept that in virtual machine that's
> running directly on their desktop. OTOH, I'm no VNC expert :) and maybe
> there are tricks to speed this up?!

There is no performance issue with native VNC on either localhost or
a LAN. I know of places where people use a VNC session to a remote
Linux desktop for day-to-day software development with no serious
performance issues. Basically if your network is reasonably fast then
there should be no issues. NB, I'm talking LAN - not WAN / Internet
here, so assuming 100mb ethernet.

That said its possible that a combination of VNC, and slow emulation
of the display adapter within the guest OS could lower performance a
bit more, but I'm still fairly optimistic that its usable. In any
case slow display adapter emulation would affect the native SDL display
mode too.

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: [Qemu-devel] Doing a Tcl/Tk based frontend

[Anthony Liguori]

Daniel P. Berrange wrote:
>> VNC is a good idea... But isn't it a bit "laggy" for this purpose? I
>> think people accept a laggy mouse cursor in a VNC window that comes over
>> the network, but won't really accept that in virtual machine that's
>> running directly on their desktop. OTOH, I'm no VNC expert :) and maybe
>> there are tricks to speed this up?!
>>     
>
> There is no performance issue with native VNC on either localhost or
> a LAN.

That's not quite true.  I did quite a bit of benchmarking with VNC 
localhost.  I figure the best case scenario is raw encoding.  Even with 
my very optimized client, there is a slight latency and more 
importantly, a non trivial CPU overhead (~5%)

Basically, if you can't see the host cursor, you can't notice the cursor 
latency.  The CPU overhead only adds a trivial amount of time when qemu 
is CPU bound.  Certainly acceptable IMHO.

I'm 100% it's the right approach to take.

Regards,

Anthony Liguori

>  I know of places where people use a VNC session to a remote
> Linux desktop for day-to-day software development with no serious
> performance issues. Basically if your network is reasonably fast then
> there should be no issues. NB, I'm talking LAN - not WAN / Internet
> here, so assuming 100mb ethernet.
>
> That said its possible that a combination of VNC, and slow emulation
> of the display adapter within the guest OS could lower performance a
> bit more, but I'm still fairly optimistic that its usable. In any
> case slow display adapter emulation would affect the native SDL display
> mode too.
>
> Dan
>   

Re: [Qemu-devel] VMware Player

[Rick Vernam]

QEMU leaves me with very few 'itches to be scratched' ...

The basic tasks that a QUI should confine itself to, IMO, are already pretty 
darn easy - define/manage a VM (via a shell script for me), start it, stop 
it, pause it...etc..

Even so, I've been thinking about this for some time - months probably...
What I'd develop, if I were to undertake such a task, is a very simple app 
that can start qemu according to some configuration, and simply hook into the 
monitor to issue such commands as sendkey, stop, cont ...etc ...

I do not imagine a need to have this app embed the qemu VM in itself, only 
start it & hook into the monitor.  Besides, I don't want to loose precious 
real estate - I like the window that a running VM is in just how it is - no 
changes.
I've used VMWare in the past a lot.  I found the toolbars & menus to be 
nothing more than clutter & annoyance.  The majority of the work I do with a 
VM has everything to do with the VM, and nothing to do with things that can 
be done with an additional GUI, however it would be nice to have one for 
simplifying those extra tasks...

Specifically, I imagine something sitting in my Sys. Tray.  This Sys. Tray 
icon menu thing would have options to invoke qemu's monitor commands for easy 
access ...or a list of all VMs, each with a sub-menu (I'm thinking stop, 
cont, loadvm, savevm, commit, usb stuff, change device x).
Also, I can use the Sys. Tray Icon to bring up it's window with all the 
niceties to create a new VM, manage existing VMs...etc.

Right now, I have a shell script that has the 'configuration' of my VM - 
changing of that 'configuration' would need to go in the GUI.

I also use the monitor thing for stop, cont, loadvm, startvm, commit, usb 
stuff & change device x - that would need to go in the GUI.

Beyond that, what does more bling really bring to the table?

On Thursday 15 June 2006 16:03, Joe Lee wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Thu, 15 Jun 2006, Joe Lee wrote:
> >> BTW, I am curious to know how much would it cost to develop a good
> >> GUI-Frontend for QEMU that would be comparable to VMware. How much man
> >> hours would this likely take?
> >
> > I do not know VMware. Anybody? I would be interested, too, to know how
> > complicated that frontend is... Should not be too difficult to reproduce
> > it in Tcl/Tk (with a proper Tcl script as config format).
> >
> > Ciao,
> > Dscho
>
> I am hoping some experience developers would comment on this!
> Joe
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] VMware Player

[Joe Lee]

Rick Vernam wrote:
> QEMU leaves me with very few 'itches to be scratched' ...
>
> The basic tasks that a QUI should confine itself to, IMO, are already pretty 
> darn easy - define/manage a VM (via a shell script for me), start it, stop 
> it, pause it...etc..
>
> Even so, I've been thinking about this for some time - months probably...
> What I'd develop, if I were to undertake such a task, is a very simple app 
> that can start qemu according to some configuration, and simply hook into the 
> monitor to issue such commands as sendkey, stop, cont ...etc ...
>
> I do not imagine a need to have this app embed the qemu VM in itself, only 
> start it & hook into the monitor.  Besides, I don't want to loose precious 
> real estate - I like the window that a running VM is in just how it is - no 
> changes.
> I've used VMWare in the past a lot.  I found the toolbars & menus to be 
> nothing more than clutter & annoyance.  The majority of the work I do with a 
> VM has everything to do with the VM, and nothing to do with things that can 
> be done with an additional GUI, however it would be nice to have one for 
> simplifying those extra tasks...
>
> Specifically, I imagine something sitting in my Sys. Tray.  This Sys. Tray 
> icon menu thing would have options to invoke qemu's monitor commands for easy 
> access ...or a list of all VMs, each with a sub-menu (I'm thinking stop, 
> cont, loadvm, savevm, commit, usb stuff, change device x).
> Also, I can use the Sys. Tray Icon to bring up it's window with all the 
> niceties to create a new VM, manage existing VMs...etc.
>
> Right now, I have a shell script that has the 'configuration' of my VM - 
> changing of that 'configuration' would need to go in the GUI.
>
> I also use the monitor thing for stop, cont, loadvm, startvm, commit, usb 
> stuff & change device x - that would need to go in the GUI.
>
> Beyond that, what does more bling really bring to the table?
>
> On Thursday 15 June 2006 16:03, Joe Lee wrote:
>   
>> Johannes Schindelin wrote:
>>     
>>> Hi,
>>>
>>> On Thu, 15 Jun 2006, Joe Lee wrote:
>>>       
>>>> BTW, I am curious to know how much would it cost to develop a good
>>>> GUI-Frontend for QEMU that would be comparable to VMware. How much man
>>>> hours would this likely take?
>>>>         
>>> I do not know VMware. Anybody? I would be interested, too, to know how
>>> complicated that frontend is... Should not be too difficult to reproduce
>>> it in Tcl/Tk (with a proper Tcl script as config format).
>>>
>>> Ciao,
>>> Dscho
>>>       
>> I am hoping some experience developers would comment on this!
>> Joe
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>     
>
>   
I glad to see many people sharing comments and making suggestions since 
this thread topic started. I seems there enough interest to have a 
GUI-Frontend for QEMU. I am hopeful this can lead to getting something 
started.

I'd like to see a poll from people who would be willing to participate 
and contribute to getting something started.

-joe

Re: [Qemu-devel] VMware Player

[Rick Vernam]

On Thursday 15 June 2006 23:31, Joe Lee wrote:
> I glad to see many people sharing comments and making suggestions since
> this thread topic started. I seems there enough interest to have a
> GUI-Frontend for QEMU. I am hopeful this can lead to getting something
> started.
>
> I'd like to see a poll from people who would be willing to participate
> and contribute to getting something started.
>
> -joe

I'd absolutely love to.
Although I have no experience with Qt, GTk, Tcl/Tk ...etc (only win32 GUI 
stuff, which I haven't done in years).
Nor do I know anything about qemu internals...

:-)

Re: [Qemu-devel] VMware Player

[Tim Walker]

[-- Attachment #1: Type: text/html, Size: 1973 bytes --]

Re: [Qemu-devel] VMware Player

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Thu, 15 Jun 2006 16:17:09 -0500
John Morris <jmorris@beau.org> wrote:

> On Thu, 2006-06-15 at 09:18, Joe Lee wrote:
> 
> > I appreciate the effort that some are making to develop a GUI for
> > QEMU - There's a few project I see that trying to achieve this.
> > But, I wish they all could come together and work together to
> > develop a nice GUI. I would like to see a sub-project exist in the
> > QEMU site so all can come and contribute to that effort.
> 
> Geez, why not ask for world peace while you are at it.  One GUI?  So
> which toolkit?  Pick Gtk and watch the K folk whine.  Ok, so KDE it
> is. Oops, now the Gnomes are all over ya.  And of course since I
> suspect a non-trivial percentage of QEMU users are on Windows,
> Solaris, etc. they ain't gonna like either of those choices much.

WxWidgets (www.wxwidgets.org) provides a nice way out of this - provides
a uniform API for the application developer, and local look-and-feel for
each platform.  WxWidgets can sit on gtk, motif, x11, win32, mac, cocoa
(doesn't appear to be a qt backend yet, but no reason there couldn't
be).

> Face it, putting a GUI on something like QEMU is going to require at
> least a one per desktop/platform effort.  And that can best be kept
> with the GNOME/KDE/etc software repositories because they require
> constant updating on the schedule of the rest of the desktop
> environment to stay current.
> 
> Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of
> graphical front ends that all make use of them.  Nobody has to totally
> reinvent the wheel because those solid CLI only parts can be reused by
> each project and each graphical environment gets a totally native (ok,
> several) GUI CD/DVD authoring/burning program instead of one crappy
> ported program.
> 


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Qemu-devel] VMware Player

[kadil]

On Thu, 2006-06-15 at 16:34 -0400, Joe Lee wrote:
>  
> BTW, I am curious to know how much would it cost to develop a good 
> GUI-Frontend for QEMU that would be comparable to VMware. How much man 
> hours would this likely take?
> 
> Joe

Firstly, we do not have to start from scratch. There are some excellent
examples of gui's as separate projects. We just need a benevolent
dictator to "select" one as a concept, so the project will focus on a
main branch.

I will put forward my vote in advance for gtk. Cross platform, always
free, no strings attached. 

I am not a very good programmer. I could do a simple gui is one day, a
comprehensive one may be a solid month. But the quality of my code would
not be as good as the existing options.

I tried qemu-launcher. Loved it, then upgraded qemu and it no longer
works. Hence I would like the gui to be in the main project, so they
stay synchronised.

Fortunately a lot of the work has already been started in the separate
projects. It would be better to select one and build on it, than
starting over.

I would never advocate taking away the text based interface. That in the
MS domain. But an installer + default gui will go far.

Kim

Re: [Qemu-devel] Re: VMware Player

[Jan Marten Simons]

Am Donnerstag, 15. Juni 2006 21:44 schrieb Joe Lee:
> Can you point me to the one you know about?
>
> Joe

As I already did in one of my last replies, I point you to
http://www.reactos.org/xhtml/en/download.html
and especially to this file:
http://prdownloads.sourceforge.net/reactos/reactos0.2.9-REL-qemu.zip?download

After Downloading and unpacking that zip-file you will find a .bat-file for 
windows and a .sh for linux to simply start the supplied image. No need to 
setup anything on the computer in question and another pro of using qemu for 
this is that you will not need to have admin/root priviledges (in contrast to 
VMware Player iirc).

Jan

Re: [Qemu-devel] Re: VMware Player

[Jan Marten Simons]

Am Donnerstag, 15. Juni 2006 21:21 schrieb Joe Lee:
>Good point on that, BUT it's not just about the GUI. It's about an
> "easy" way to install the product and run a given app without the need
> to create/setup a VM - To me that is the benefit of the VMware player.
...
>
> Joe

Well, qemu does not even need to be installed, it can run from any location, 
if it is distributed in an intelligent manner. The steps required to setup a 
new VM are ridiculus easy as qemu ships a handy tool for creating and 
converting different disk images and a quite good documentation as well.

Regards,
Jan

Re: [Qemu-devel] VMware Player

[Stuart Brady]

On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote:

> WxWidgets (www.wxwidgets.org) provides a nice way out of this - provides
> a uniform API for the application developer, and local look-and-feel for
> each platform.  WxWidgets can sit on gtk, motif, x11, win32, mac, cocoa
> (doesn't appear to be a qt backend yet, but no reason there couldn't
> be).

Yes, there should be abstraction between the UI and the VM, but I think
that the approach taken by xine, gstreamer, cdrecord, cdparanoia, etc.
is much cleaner.  You could still write a frontend with WxWidgets...

I think it would be best if QEMU didn't depend on any particular
toolkit, and that includes WxWidgets.
-- 
Stuart Brady

Re: [Qemu-devel] VMware Player

[Joe Lee]

I thought I share this with you all. I have been looking into XEN lately 
and someone has developed a GUI-Frontend for it. Here's the link below 
showing images for the GUI interface to manage xen. A similar type GUI 
interface could be done for QEMU.
I wonder want programming tool used for it.

http://sourceforge.net/projects/xenman/
http://sourceforge.net/project/screenshots.php?group_id=168929
http://sourceforge.net/project/screenshots.php?group_id=168929&ssid=35194
http://sourceforge.net/project/screenshots.php?group_id=168929&ssid=35193
http://sourceforge.net/project/screenshots.php?group_id=168929&ssid=35191
http://sourceforge.net/project/screenshots.php?group_id=168929&ssid=35190




Kevin F. Quinn wrote:
> On Thu, 15 Jun 2006 16:17:09 -0500
> John Morris <jmorris@beau.org> wrote:
>
>   
>> On Thu, 2006-06-15 at 09:18, Joe Lee wrote:
>>
>>     
>>> I appreciate the effort that some are making to develop a GUI for
>>> QEMU - There's a few project I see that trying to achieve this.
>>> But, I wish they all could come together and work together to
>>> develop a nice GUI. I would like to see a sub-project exist in the
>>> QEMU site so all can come and contribute to that effort.
>>>       
>> Geez, why not ask for world peace while you are at it.  One GUI?  So
>> which toolkit?  Pick Gtk and watch the K folk whine.  Ok, so KDE it
>> is. Oops, now the Gnomes are all over ya.  And of course since I
>> suspect a non-trivial percentage of QEMU users are on Windows,
>> Solaris, etc. they ain't gonna like either of those choices much.
>>     
>
> WxWidgets (www.wxwidgets.org) provides a nice way out of this - provides
> a uniform API for the application developer, and local look-and-feel for
> each platform.  WxWidgets can sit on gtk, motif, x11, win32, mac, cocoa
> (doesn't appear to be a qt backend yet, but no reason there couldn't
> be).
>
>   
>> Face it, putting a GUI on something like QEMU is going to require at
>> least a one per desktop/platform effort.  And that can best be kept
>> with the GNOME/KDE/etc software repositories because they require
>> constant updating on the schedule of the rest of the desktop
>> environment to stay current.
>>
>> Think of it like mkisofs/cdrecord/growisofs/cdrdao vs the abundance of
>> graphical front ends that all make use of them.  Nobody has to totally
>> reinvent the wheel because those solid CLI only parts can be reused by
>> each project and each graphical environment gets a totally native (ok,
>> several) GUI CD/DVD authoring/burning program instead of one crappy
>> ported program.
>>
>>     
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

Re: [Qemu-devel] VMware Player

[Johannes Schindelin]

Hi,

On Fri, 16 Jun 2006, Joe Lee wrote:

> I thought I share this with you all. I have been looking into XEN lately and
> someone has developed a GUI-Frontend for it. Here's the link below showing
> images for the GUI interface to manage xen. A similar type GUI interface could
> be done for QEMU.
> I wonder want programming tool used for it.

GTK. Since XEN is already limited in scope to a Linux host, it makes (sort 
of) sense.

Hth,
Dscho

Re: [Qemu-devel] VMware Player

[Kevin F. Quinn]

On Fri, 16 Jun 2006 13:45:24 +0100
Stuart Brady <sdbrady@ntlworld.com> wrote:

> On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote:
> 
> > WxWidgets (www.wxwidgets.org) provides a nice way out of this -
> > provides a uniform API for the application developer, and local
> > look-and-feel for each platform.  WxWidgets can sit on gtk, motif,
> > x11, win32, mac, cocoa (doesn't appear to be a qt backend yet, but
> > no reason there couldn't be).
> 
> Yes, there should be abstraction between the UI and the VM, but I
> think that the approach taken by xine, gstreamer, cdrecord,
> cdparanoia, etc. is much cleaner.  You could still write a frontend
> with WxWidgets...
> 
> I think it would be best if QEMU didn't depend on any particular
> toolkit, and that includes WxWidgets.

I was suggesting WxWidgets as a way to avoid writing separate gui
frontends for each platform (that's what WxWidgets is for). I wasn't
suggesting WxWidgets be embedded into Qemu (or the other way around for
that matter).  If you want a pretty controller app and you want to
avoid cross-platform issues WxWidgets does a lot of the work for you
(much more than just gtk for example).  In particular I was responding
to the statement

> Face it, putting a GUI on something like QEMU is going to require at
> least a one per desktop/platform effort.

I don't see any reason to hack up qemu just to put a pretty face on
it.  VNC support already provides an easy way to place the guest screen
wherever you want if you don't like the SDL window (although I think
SDL remains the best choice for the guest screen).
http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets and
SDL, although I don't know if that's useful.

-- 
Kevin F. Quinn

Re: [Qemu-devel] VMware Player

[Christian MICHON]

you're putting c++ inside the qemu source tree when it is not
needed (yet).

if SDL is common to most guest screens: I agree with you
that the gui/toolkit should overlay the SDL.

Yet Fabrice mentionned months ago this was not his
intention, so we should respect it and (hopefully) close
this long thread.

On 6/16/06, Kevin F. Quinn <ml@kevquinn.com> wrote:
> On Fri, 16 Jun 2006 13:45:24 +0100
> Stuart Brady <sdbrady@ntlworld.com> wrote:
>
> > On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote:
> >
> > > WxWidgets (www.wxwidgets.org) provides a nice way out of this -
> > > provides a uniform API for the application developer, and local
> > > look-and-feel for each platform.  WxWidgets can sit on gtk, motif,
> > > x11, win32, mac, cocoa (doesn't appear to be a qt backend yet, but
> > > no reason there couldn't be).
> >
> > Yes, there should be abstraction between the UI and the VM, but I
> > think that the approach taken by xine, gstreamer, cdrecord,
> > cdparanoia, etc. is much cleaner.  You could still write a frontend
> > with WxWidgets...
> >
> > I think it would be best if QEMU didn't depend on any particular
> > toolkit, and that includes WxWidgets.
>
> I was suggesting WxWidgets as a way to avoid writing separate gui
> frontends for each platform (that's what WxWidgets is for). I wasn't
> suggesting WxWidgets be embedded into Qemu (or the other way around for
> that matter).  If you want a pretty controller app and you want to
> avoid cross-platform issues WxWidgets does a lot of the work for you
> (much more than just gtk for example).  In particular I was responding
> to the statement
>
> > Face it, putting a GUI on something like QEMU is going to require at
> > least a one per desktop/platform effort.
>
> I don't see any reason to hack up qemu just to put a pretty face on
> it.  VNC support already provides an easy way to place the guest screen
> wherever you want if you don't like the SDL window (although I think
> SDL remains the best choice for the guest screen).
> http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets and
> SDL, although I don't know if that's useful.
>
> --
> Kevin F. Quinn
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


-- 
Christian

Re: [Qemu-devel] VMware Player

[Oliver Gerlich]

Christian MICHON wrote:
> you're putting c++ inside the qemu source tree when it is not
> needed (yet).
> 
> if SDL is common to most guest screens: I agree with you
> that the gui/toolkit should overlay the SDL.
> 
> Yet Fabrice mentionned months ago this was not his
> intention, so we should respect it and (hopefully) close
> this long thread.

Close the thread? Please not - I think it's good that many people posted 
their ideas about a GUI, and maybe there will finally come some 
agreement about the techniques and libraries that should be used.

And if Fabrice doesn't want C++ in the tree (seems a bit reasonable), 
then there's still GTK. And if it is too difficult to install and run a 
GTK GUI under Windows, then a native Windows GUI is still possible 
(after all, the Mac OS X version uses a native GUI toolkit as well, so 
why not do the same under Windows, and use the GTK frontend under all 
other platforms).

Btw. it would be interesting to know what features would be required to 
get a GUI into the Qemu tree, and what would be a total showstopper... 
Maybe the people with commit permission could comment on this :)

Regards,
Oliver

Re: [Qemu-devel] VMware Player

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 3187 bytes --]

On Fri, 16 Jun 2006 17:07:32 +0200
"Christian MICHON" <christian.michon@gmail.com> wrote:

> you're putting c++ inside the qemu source tree when it is not
> needed (yet).

Perhaps I'm still not making myself clear.  I did _not_ suggest that
a WxWidgets GUI be integrated into QEMU.  I assumed we were all talking
about an independent controller app to provide a pretty clicky-button
way to start/stop qemu instances, provide console and serial i/o
terminals, that sort of thing.

The only thing that may be worth thinking about is a way to redirect
the SDL output from QEMU, if VNC proves too slow.  Even that would only
be if you want the QEMU screen to be embedded in the frontend, and to
be honest I see no need for that.

> if SDL is common to most guest screens: I agree with you
> that the gui/toolkit should overlay the SDL.
> 
> Yet Fabrice mentionned months ago this was not his
> intention, so we should respect it and (hopefully) close
> this long thread.
> 
> On 6/16/06, Kevin F. Quinn <ml@kevquinn.com> wrote:
> > On Fri, 16 Jun 2006 13:45:24 +0100
> > Stuart Brady <sdbrady@ntlworld.com> wrote:
> >
> > > On Fri, Jun 16, 2006 at 09:21:46AM +0200, Kevin F. Quinn wrote:
> > >
> > > > WxWidgets (www.wxwidgets.org) provides a nice way out of this -
> > > > provides a uniform API for the application developer, and local
> > > > look-and-feel for each platform.  WxWidgets can sit on gtk,
> > > > motif, x11, win32, mac, cocoa (doesn't appear to be a qt
> > > > backend yet, but no reason there couldn't be).
> > >
> > > Yes, there should be abstraction between the UI and the VM, but I
> > > think that the approach taken by xine, gstreamer, cdrecord,
> > > cdparanoia, etc. is much cleaner.  You could still write a
> > > frontend with WxWidgets...
> > >
> > > I think it would be best if QEMU didn't depend on any particular
> > > toolkit, and that includes WxWidgets.
> >
> > I was suggesting WxWidgets as a way to avoid writing separate gui
> > frontends for each platform (that's what WxWidgets is for). I wasn't
> > suggesting WxWidgets be embedded into Qemu (or the other way around
> > for that matter).  If you want a pretty controller app and you want
> > to avoid cross-platform issues WxWidgets does a lot of the work for
> > you (much more than just gtk for example).  In particular I was
> > responding to the statement
> >
> > > Face it, putting a GUI on something like QEMU is going to require
> > > at least a one per desktop/platform effort.
> >
> > I don't see any reason to hack up qemu just to put a pretty face on
> > it.  VNC support already provides an easy way to place the guest
> > screen wherever you want if you don't like the SDL window (although
> > I think SDL remains the best choice for the guest screen).
> > http://code.technoplaza.net/wx-sdl/ talks about combining WxWidgets
> > and SDL, although I don't know if that's useful.
> >
> > --
> > Kevin F. Quinn
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> 
> 


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [Qemu-devel] VMware Player

[Mattia Gentilini (QD)]

Tim Walker wrote:
> That may not be true - I'm not sure but I think something reasonable
> could be done in Java. There is certainly a Java VNC client available
> which could play a part.
The FLOZ project
http://www.oszoo.org/wiki/index.php/Free_Live_OS_Zoo

Uses the tightVNC Java applet to connect to QEMU instance.
QEMU on the server is CVS, but lacks the last vnc.c patch (I'll put it
on when I have some time).

-- 
MG55: Mattia Gentilini & 55 Virtual Machines

Re: [Qemu-devel] VMware Player

[Tim Walker]

Mattia Gentilini (QD) wrote:
> Tim Walker wrote:
>   
>> That may not be true - I'm not sure but I think something reasonable
>> could be done in Java. There is certainly a Java VNC client available
>> which could play a part.
>>     
> The FLOZ project
> http://www.oszoo.org/wiki/index.php/Free_Live_OS_Zoo
>
> Uses the tightVNC Java applet to connect to QEMU instance.
> QEMU on the server is CVS, but lacks the last vnc.c patch (I'll put it
> on when I have some time).
>
>   
This really is too cool ;)

What hardware is it running on?

Re: [Qemu-devel] VMware Player

[Mattia Gentilini (QD)]

Tim Walker wrote:
>> The FLOZ project
>> http://www.oszoo.org/wiki/index.php/Free_Live_OS_Zoo
> This really is too cool ;)
Thanks ;-)

> What hardware is it running on?
Currently we use a dual xeon 2.8 GHz with hyperthreading and 2 GB
physical RAM.

-- 
MG55: Mattia Gentilini & 55 Virtual Machines

Re: [Qemu-devel] GUI for QEmu (ex "VMware Player" topic)

[NyOS]

Hi!

(note: Subject changed since it has noting to do with VMPlayer.)

> if SDL is common to most guest screens: I agree with you
> that the gui/toolkit should overlay the SDL.

In my opinion, introducing new dependencies should be avoided due to  
portability reasons. QEmu already uses SDL, so it's an obvious way to use  
it for the gui also. There are gui-s based on SDL, so the wheel is already  
invented. :) (However, reimplementing a button or an editbox needs few  
work I think.)

I was wondering about a new approach. People can reach the VM screen at  
alt-ctrl-1, the monitor at -2 and so on.. A graphical monitor (a kind of  
GUI) could be introduced e.g. at alt-ctrl-5 or alt-ctrl-0. It could offer  
changing the cd/dvd/floppy image, cont, stop, commit, and so on.
When people run qemu with --help parameter, it could do what it does now  
(print command line options). But executing it without parameters, it  
could open that graphical monitor, where images, memory, hardware would be  
set.

That way no new dependencies would be introduced, the VM could be set full  
screen, and it would be completely be backward compatible. So noone is  
forced to use GUI who doesn't really need it.

Another approach is GTK. I think people sould not fear it. Gimp and Gaim  
also use GTK, and runs on Win32. They ship a gtk installer with the  
windows binary (there's also a version without gtk), so people can install  
it on windows with the well known next-next-finish way. If you don't  
believe me, try it.

Best regards,

Miklos GYOZO

-------------------------------------------------------------
"Software is like sex: it's better with a penguin." - unknown