Re: [Qemu-devel] VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
John Morris 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. 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. 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. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Thu, 15 Jun 2006 16:17:09 -0500 John Morris [EMAIL PROTECTED] 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 signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: VMware Player
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. In the development version of my Java frontend for QEMU (JQEMU) I've already integrated the Java VNC client from TightVNC and it works like a charm without any speed overhead! And it feels just like VMWare... Since Java is already available for a large variety of platforms this wouldn't require a big porting effort... Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: VMware Player
Christian Bourque wrote: 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. In the development version of my Java frontend for QEMU (JQEMU) I've already integrated the Java VNC client from TightVNC and it works like a charm without any speed overhead! And it feels just like VMWare... Since Java is already available for a large variety of platforms this wouldn't require a big porting effort... Christian This gets my vote. Have you tried a compile to native with gcj for those who don't have/want to have the Java VM installed? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Fri, 16 Jun 2006 13:45:24 +0100 Stuart Brady [EMAIL PROTECTED] 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
Re: [Qemu-devel] VMware Player
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 [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006 13:45:24 +0100 Stuart Brady [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
On Fri, 16 Jun 2006 17:07:32 +0200 Christian MICHON [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Fri, 16 Jun 2006 13:45:24 +0100 Stuart Brady [EMAIL PROTECTED] 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 signature.asc Description: PGP signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] linux-test-0.5.1.tar.gz seems outdated
Hello QEMU world, The subject line said allready that linux-test-0.5.1.tar.gz is outdated. But as this being my first post to this list, I can't rush in and say there needs something changed at your side, so below a IRC log that provides the details. (at the end of the message more text) 19:00 stappers hi, the FAQ reports: Debian has a qemu-0.7.0 package in unstable, which works. Ubuntu also has a working 0.7.0 package. 0.7.0 and all future versions _should_ work. 19:01 stappers are any succes reported on qemu 0.8.1 on Debian? 19:01 blight_ i dont see any reason why it shouldnt work on debian 19:02 allix linux is linux 19:02 stappers mmm, seems I help with it. mmm, seems I need help with it. 19:04 stappers the error message I get is: 19:04 stappers SIOCSIFADDR: No such device 19:04 stappers eth0: unknown interface: No such device 19:04 stappers I do see tap0 created on the host system 19:05 dignome look in /etc/qemu-ifup 19:06 stappers AFAICS is /etc/qemu-ifup doing it's job 19:06 dignome ifconfig shows an eth0 interface? 19:06 stappers AFAICS is /etc/qemu-ifup, on the host, doing it's job 19:07 stappers ifconfig shows only lo 19:07 dignome perhaps i meant ifconfig -a ;p 19:08 stappers the image used is from the QEMU homepage 19:08 stappers ifconfig -a reveals dummy0 19:10 dignome hm. how is the host connected? 19:14 dignome stappers: people usually either bridge tap0 to an ethernet interface or set up some iptable rules and enable forwarding. 19:14 stappers dignome: host is a headless PIII, with a `ssh -X headlesshost` connection, i.o.w.: a X-terminal 19:14 dignome stappers: i mean how is it connected on the network 19:15 stappers I call the connection vlan0 on TUN/TAP 19:16 stappers but there is not yet a connection, there isn't even a network device in the guestVM 19:17 stappers my commandline is ` qemu linux.img -net nic -net tap` 19:19 dignome ok. the question is how are you connecting to a headless machine if it doesn't have any network interfaces other than lo? 19:21 stappers the headless machine is the host that is running qemu, I can ssh to it, qemu runs the linux image (but no eth0) 19:22 dignome ... how do you even ssh into it? what is that connection going over! 19:22 pbrook You mean no eth0 inside the guest? 19:22 stappers yes, no eth0 inside the guest 19:23 pbrook You need to load the guest ne2k pci (ak rtl8029) drivers. 19:23 stappers mmm 19:26 stappers the guest image doesn't contain 'modprobe', the dir /lib/modules/ is empty 19:27 dignome hm. i can see how things went off... should have asked about ifconfig -a specifying to run it on the *host* ;p 19:31 pbrook stappers: Sounds like you need to unbreak your gues OS install. 19:31 stappers the host has lo, eth0, sit0 and tap0 19:32 stappers unbreak as in rebuild? 19:32 stappers the guest OS image I use is from the QEMU homepage 19:33 pbrook Oh. That doesn't have the right ethernet drivers on it. 19:33 stappers :-) 19:33 stappers :-/ 19:33 stappers so http://fabrice.bellard.free.fr/qemu/linux-test-0.5.1.tar.gz is obsolete 19:34 stappers and http://fabrice.bellard.free.fr/qemu/download.html needs an update 19:34 pbrook Yes 19:34 pbrook Feel free to create a n updated image and sent it to fabrice. 19:42 stappers pbrook: are you sure about 19:42 stappers pbrook Oh. That doesn't have the right ethernet drivers on it. 19:43 pbrook Fairly sure. It only has the isa ne2k drivers. 19:43 stappers the kernel config has CONFIG_NE2000 and qemu monitor reports ne2000 at `info network` 19:44 pbrook See above. 19:44 pbrook ne != ne2k_pci 19:44 stappers mmm While editing, I wondered which hardware is in the Debian version of Qemu. CHIPS signature.asc Description: Digital signature ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: VMware Player
In the development version of my Java frontend for QEMU (JQEMU) I've already integrated the Java VNC client from TightVNC and it works like a charm without any speed overhead! And it feels just like VMWare... Since Java is already available for a large variety of platforms this wouldn't require a big porting effort... Christian This gets my vote. Have you tried a compile to native with gcj for those who don't have/want to have the Java VM installed? Hi Tim! The last time I tried to compile JQEMU with gcj I had some errors because the Swing API wasn't fully supported by gcj. But that was a long time ago and I read that the gcj team have made significant progress since then so I'll give it another shot this weekend! Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/sources/qemu Module name:qemu Changes by: Paul Brook pbrook 06/06/16 21:48:48 Modified files: . : qemu-doc.texi Log message: Arm h/w doc updates. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.94r2=1.95 Patches: Index: qemu-doc.texi === RCS file: /sources/qemu/qemu/qemu-doc.texi,v retrieving revision 1.94 retrieving revision 1.95 diff -u -b -r1.94 -r1.95 --- qemu-doc.texi 14 Jun 2006 18:35:18 - 1.94 +++ qemu-doc.texi 16 Jun 2006 21:48:48 - 1.95 @@ -1524,6 +1524,10 @@ This means some devices (eg. ne2k_pci NIC) are not useable, and others (eg. rtl8139 NIC) are only useable when the guest drivers use the memory mapped control registers. [EMAIL PROTECTED] +PCI OHCI USB controller. [EMAIL PROTECTED] +LSI53C895A PCI SCSI Host Bus Adapter with hard disk and CD-ROM devices. @end itemize A Linux 2.6 test image is available on the QEMU web site. More ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QGui
Hello, Wayne here, I would like to know if there is some user documentation for the QGui application? Everytime that I try to use it at the end where it says save I always get the same message that says Run time error 76, path not found. Any input would be much appreciated. Thank you for your time, Wayne _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
