Puppy Linux Discussion Forum

[mikeb]

Thanks for the feedback... obviously some aspects of qemu are out of the scope of this interface.

General...-smp refers to the simulater guest cpu(s) so my wording is wrong..I will amend.
As for kqemu It seems it can only fullly accelerate one cpu and reverts to more emulated multi cpu for 2 or more.

mike

[gcmartin]

Thanks for the ability to define a virtual Guest PC with more than 1 core! The earlier report I shared has had another performance bump in the Slacko64 Guest as, now with the multiple cores, allows Slacko64 better desktop performance threading, while its launched Guest is running. Guest virtual PCs are "flying" comparatively.

This tool is a great assist for design and setup of the virtual PCs that ISO/distro boot into.
Your tool, QEMU Launcher, makes it easy for others to understand the creating an "internal PC" on the running desktop. Thx!!!

[mikeb]

Ok another update now we seems to have something useable.

version 0.4

Added a box for additional parameters as suggested earlier
Merged in kqemu support so should give the appropriate option for KVM or kqemu or no acceleration.
Clarified smp wording.

Mike

[neerajkolte]

Hi mikeb,
The GUI is improving nicely.
New users might find it actually easier than virtualbox.

Thanks

-Neeraj

[mikeb]

Ok did realise I had had a mental blank which was sorted out after compiling QEMU.

Package updated to 0.5....

Added choice of virtual machine taken from the included binaries (doh!)
Added help button which opens qemu main doc in default browser.
Removed the kill button since the gui has that anyway..or you can simply close the window...same effect. Also it is possible if somewhat masochistic to run several virtual machines so one kill button seemed a little inappropriate.

By the way how do you escape from full screen mode?

Also I built 2.0.0 on Lucid (32 bit) so wondered if that might be useful ... thing is I did not have opengl or SLD enabled/present which makes it more generic but I wondered if there was a significant performance hit without them?

If its useful I could make a sfs and pet including the gui here...

mike

mike

[mikeb]

Ok one for testing.

QEMU 2.0.0 built on Lucid so for 32 bit OS and machines.
Needs glibc 2.11 so unsure of support on older puppies... 'should' be ok on newer.
Used the defaults which makes a pretty generic build.
I cannot test KVM without a bios update so some feedback would be nice. Also of course 2.6.33 lucid has no KVM support anyway but one of the new builds might. I included the gui so hopefully a load and run package.

If its ok I will make a pet too..
It includes the binaries for running static erm binaries but at this point the gui does not include this funtionality.

https://dl.dropboxusercontent.com/u/110545536/Puppy/QEMU-32bit-2.0.0_sfs4.sfs

mike

[gcmartin]

[mikeb]

Ok added 32 bit builds of QEMU to the first post....

mike

[gcmartin]

Installed 32bit PET into a Guest on the Host. Guest configuration is seen by Hardinfo below. The Host's Virtual Guest shows KVM hardware presence.

But, when attempt is made to use the Launcher to test booting a virtual Guest in this Guest, i get the following terminal messages:

[mikeb]

Ok libcurl-gnutls.so.4 is included in default Lucid so I was uncertain but assumed newer pups would included for the same reasons it was in lucid... It would appear that is not the case.

Adding it to the pet would not be the most sensible move by its nature especially after the recent security revelation about gnutls.

It is possible to symlink it to libcurl.so.4 which is usually present.... it would also be possible to build it without curl support but what does that affect?


mike

[mikeb]

Ok I looked into kvm modules for Lucid.

Short story is they cannot be built as additional modules on kernels 2.6.32+ ...and chances are any pups with older kernels will lack the glibc for qemu itself...but that's Linux for you.

Sooo had a plan ... Compiled the lucid kernel with the KVM enabled.... but...another shortened story .... the modified kernel will only work with a fresh set of modules even though it would appear to be unconnected with the main goings on. I did try hacking versioning which did get the originals loading but they were not happy... the plan was a new vmlinux plus 3 modules and leave the rest intact for a simple update.

SO what I do have is a KVM enabled 2.6.33.2 kernel plus a full set of modules including KVM which work nicely as a set... all in a sfs which of course is also useless for standard puppies since it would load under the old ones plus of course the initrd needs altering unless you have a full install. The other problem is of course any extra modules compile with the original config will not work/load either.

If anyone wants this kit of parts let me know

Bonus bunny is I did get to configure and compile my first kernel.

#######

purely experimental but here is the kernel and an sfs of the full module set...note i am posting while running this actual build.
https://dl.dropboxusercontent.com/u/110545536/Puppy/vmlinuz-kvm
https://dl.dropboxusercontent.com/u/110545536/Puppy/Kernel-lucid-kvm_sfs4.sfs

####

Generally is would be good to know which pups do have kvm support...at least for the 32 bit since 64 seems covered. Also which have libcurl-gnutls and which do not.

mike

[gcmartin]

In using V5, I found a bug that would need some thought on addressing. If the ISO name (and probably all user paths) contains a "blank" in the filename, the Launcher misbehaves. such that when the qemu command is issued, it results in an error.

Another concern is that the RAM allocation default should be bumped as well as the default might be better suited to having the CD Boot button selected such that an initial "Launch" for a new user has a better chance of success with as little changes as possible.

Also, I am wondering if the most recent screen-fills can be saved for the next desktop execution of the QEMU Launcher.

Lastly, I am not sure if it applies, but there is some work being done in GTKdialog behavior shown here.

Here to help

[mikeb]

Hmm spaces in names ... that sneaked in it seems... ok will check it out.

Saved configs...yes its doable... it IS possible to specify and open directory too which would be helpful since files tend to be in the same place..I do that for pburn. Stuff I left while focussing on getting everything working.

Default ram...you suggest 512MB?

The name subject... 'QEMU control center' does actually sound good.

That gtkdialog info (action) does not apply in this case. I also quickly tried with gtkdialog 4 and all seemed ok too...the new maintainer seemed to have retained backward compatabiity which is helpful.

mike

[gcmartin]

"gtkdialog 4" Wow. This would move PUPPY into the 21st Century. People here are still talking about gtk1. They are still wrestling with old philosophy which predates Y2K (after 15 years, one would think we got it by now).

Any help and information you provide, I am sure, some/many developers will find useful as they too are looking for a sign to move forward.

QEMU Control Center Utility
Thanks for what you have done for the community with this little utility. I can do an ISO test in minutes versus the time I had to do things before with burning an ISO, unloading a running PC, booting the ISO (sometimes several times to isolate audio/video/LAN issues) and reporting back to the community with timely/useful information. The KVM virtual machine performance is nothing short of phenomenal (but, you already know that).

Now, I just download, boot to test, and report back to the community when needed in minutes. No issues of media or anything. This has become too simple for explanation.

Thx!!!

[mikeb]

just to clarify gtkdialog4 refers to as far as I know the puppy reference to the release era of thats binary as a simple reference for script writers. Its not directly related to gtk version...indeed its written for gtk2 and has only recently started to port over to 3.

gtkdialog = the first time it was used on puppy.

gtkdialog2 the second version with altered syntax

gtkdialog 3 third release...syntax changed again

gtkdialog 4...the latest which seems to have retained the version 3 syntax as a subset and added considerably more.

1, 2 and 3 code are not compatible so scripts have to specify which binary they were written for.

Well will make those changes soon and post it here when done

mike