Page 6 of 8

Posted: Tue 26 Aug 2014, 15:19
by gcmartin
Hi Mike.

Questions
  • Will there be updates?
  • Will this expand to both 32 and 64bit to keep all in a single place?
  • And, would installation of your QEMU PETs include the Launcher as a builtin feature of the offering this thread presents to ease knowledge to use?
Great little system you have created for all of us.

Posted: Tue 26 Aug 2014, 15:55
by mikeb
Hmm well Whitesnow http://www.murga-linux.com/puppy/viewtopic.php?t=88604 was actually putting together QEMU itself...I just threw in the 32 bit one for a newer version to fill the gap. It also seems no puppies support 32 bit KVM.
In other words I am unclear what to do plus i don't have a 64 bit compiling environment on tap.

mike

Posted: Tue 26 Aug 2014, 16:48
by stemsee
It is the kernel which supplies kvm not the puppy! EmSeeV2.2 has both 32bit and 64bit kernels both with kvm support.

Posted: Tue 26 Aug 2014, 17:14
by mikeb
Ok well 'puppy' implies the kernel it comes with...something the user normally would not change.

So only one particular puplet then and no mainstream releases it seems and 'pet' implies we are dealing with puppy.

Thing is I only use QEMU 0.9 and kqemu.ko, so the latest releases are not exactly something I use myself or have the means to fully test....its would be better if said package builder could actually test his or her packages.

mike

Posted: Wed 27 Aug 2014, 05:08
by gcmartin
I think what @StemSee is getting at, is one of the primary reason for any user to use QEMU and your Launcher. Here is one case example (AND I DO recognize that some/many 32bit PCs may or may not have the KVM feature for processor acceleration). So for this case, let's assume for the moment that the user has a PC which has CPU virtualizatioin acceleration built-in.

This allows QEMU launch of a virtual PC with a 32bit processor, a virtual PC with a ARM processor, a virtual PC with a 64bit processor, or a virtual PC with any of the various CPU types manufactured in the world without ever having any of them. In other words, if you have a 32bit PC, this thread's stuff allows any user to "MASQUERADE" as any other kind of PC to boot and run a workload.

Of course, I know you already know this, but, any other user reading those recent post may not know that these tools, you present, allow them to do all kinds of running without having to go out and buy another platform to test, compile, build, or run. Thus even with a 32bit platform, one can run and get very good performance in the virtual machine, too.

Hope this helps readers see this as merely one of the many advantages of the Virtual Machine subsystem you provide us via your product mix.

Thus, compiling a 64bit QEMU is a reasonable accomplishment even on a 32bit PC using your Puppy tools.

Here to help

Posted: Wed 27 Aug 2014, 08:40
by mikeb
Well I was basically mentioning that I am not in the best position to support this.

I have an atom machine...I can run lighthouse and build the 64 bit version but not test KVM....but that macine is normally the one my partner uses.
I can build the 32 bit but the lenovo needs a bios flash for KVM so again cannot test it.

Even the gui needs a little second guessing for the above reasons.

mike

Posted: Wed 27 Aug 2014, 20:17
by stemsee
You enjoy a challenge!!

Posted: Thu 28 Aug 2014, 13:51
by gcmartin
BTW for QEMU, version 2.1 is available since month's beginning. Also, version 2.0.2

@MikeB - (I ask because I do NOT have a PC that does NOT have KVM acceleration feature)
Does the Launch utility checkbox for KVM feature, tell the user it is missing should they try to execute the Launcher with the KVM box checked?

Curious

Posted: Thu 28 Aug 2014, 19:25
by mikeb
Does the Launch utility checkbox for KVM feature, tell the user it is missing should they try to execute the Launcher with the KVM box checked?
The arrangement is that the checkbox ONLY appears if KVM is available ... so it's only giving the option of what is actually possible if that makes sense.
You enjoy a challenge!!
The last person that said that to me I made sure I never did any work for him again.
It tended to imply 'here is something everyone else has had a go at trying to sort and made a mess off so now you can sort it out usually for not enough money' :D

mike

Posted: Thu 28 Aug 2014, 19:37
by gcmartin
Thanks @MikeB. Excellent, as I remembered you did take KVM implentation into account with the Launcher utility. EXCELLENT!

Posted: Sat 30 Aug 2014, 11:25
by jamesbond
This is cool. But if I may suggest - would you be able to "save" the settings as named VMs?

I'm hoping to see something like this:
1. First launch - list of saved VMs, showing one-line summary:
- cpu/ram/storage/kvm enabled?/stopped/running.
Action buttons: add/edit/delete/start/stop selected VM, and of course "exit" button.

The status will be updated as one start/stop/add/delete/VM.

2. When on click add or edit button, then the "edit VM" screen shows, which is you already have here. Perhaps add options about port-forwarding.

This would give VirtualBox a run for its money!

Posted: Sun 31 Aug 2014, 19:42
by mikeb
Well QEMU is not as farty arsed as Virtual Box...that's one of its attractions so I don't see a reason to introduce such complexity really..... pick an iso or an already made image and yer running...or is that too simple for today's geeks :D

mike

Posted: Thu 04 Sep 2014, 16:33
by zigbert
When I press the 'Run qemu' button, nothing happens, but I get the error

Code: Select all

# qemu_gui 
debug: qemu-system-x86_64 -boot c -m 512 -hda /mnt/sdb1/tmp/qemu.img -hdb /dev/null -cdrom /mnt/sdb1/puppy/iso/slacko64-5.9.1.iso -smp 1
qemu-system-x86_64: error while loading shared libraries: libbluetooth.so.3: cannot open shared object file: No such file or directory
Do I need libbluetooth.so.3 to get this going?
I can't find any libbluetooth in my system.
I am running Slacko 5.7


Sigmund

Posted: Thu 04 Sep 2014, 23:03
by mikeb
If you are referring to the 32 bit version from here then it was built on Lucid which appears to have libbluetooth and I guess the configure pulled it in automatically as I never chose it specifically making it a dependency.

I don't see anything else that slacko may not have apart from a gnutls disagreement

Mike

Posted: Fri 05 Sep 2014, 03:39
by gcmartin
@Zigbert, you might consider adding a bit more RAM in the GUI to run your ISO.

In case no one noticed, @Zigbert is showing how to boot a 64bit ISO in a VIRTUAL 64bit configuration on a 32bit PC. Clever!

The ONLY idea that I have to offer, in doing so, is that you "may" want to insure your 32bit PC has the virtualization feature that accelerates the virtual configuration to nearly the native speed of the processor. If your PC has the feature, you will see it on the GUI screen. Also, REMEMBER, the Launcher GUI is configuring a Virtual PC's hardware that the distro/ISO/Image is to operate in.

If you are unsure how to, otherwise, determine if your PC has the feature, see this easy to follow post.

Hope this helps.

getting alsa audio to work in the VM

Posted: Mon 08 Sep 2014, 14:16
by step
So, on FD 700 with qemu 2.1.0 I can get alsa audio working in the guest OS (VM) this way:

Code: Select all

# export QEMU_SOUND_DRV=alsa
# qemu-system-x86_64 -boot d -m 512 -enable-kvm -hda /dev/null -hdb /dev/null -cdrom /mnt/sda5/file/VM/fluxpup-1.5.1.iso -smp 1 -soundhw hda
On a dual core Intel Core2 duo laptop the welcome bark bark spikes CPU usage to 70% (fluxpup 1.5.1 iso image).

The same hardware but running precise-Csipesz (aug14 iso image) is better; CPU ~15-20% playing a wav file, and at 20% live streaming internet radio (precise-Csipesz is loaded with playlists).

So if you start the front-end gui from the command line (or a script) and add -soundhw hda in the additional parameters field, you should have sound enabled. Here's an example with precise-Csipesz

Code: Select all

# QEMU_SOUND_DRV=alsa qemn_gui
debug: qemu-system-x86_64 -boot d -m 512 -enable-kvm -hda /dev/null -hdb /dev/null -cdrom /mnt/sda5/file/VM/precise-571RetroCsipeszPupV5EngHun2014Aug.iso -smp 1 -soundhw hda
Don't forget to add -soundhw hda.

Posted: Tue 09 Sep 2014, 16:39
by mikeb
Thanks for the info step :)

I read hda as a hard drive then realised its something like HD audio or the intel stuff.

Hmm I am guessing there is overhead if this option is enabled but not actually required but I am also guessing that adding the QEMU_SOUND_DRV=alsa by itself may not...ie it could be made permanent with no detriment to users not needing sound...is this a decent bit of guesswork on my behalf? In which case the option is simply up to the user via the additional parameters without having to resort to the command line.

mike

Posted: Wed 10 Sep 2014, 01:47
by gcmartin
Thanks for the insight @Step.
I like where you're going with this @MikeB. This has useful value and add ease of use with a visual option for the Virtual PC defined by the Launcher..

Posted: Wed 10 Sep 2014, 08:25
by mikeb
I also notice OSS, SDL and WAV audio options...more to play with...literally.

Mike

Posted: Wed 10 Sep 2014, 13:17
by step
mikeb wrote:I am also guessing that adding the QEMU_SOUND_DRV=alsa by itself may not...ie it could be made permanent with no detriment to users not needing sound...is this a decent bit of guesswork on my behalf? In which case the option is simply up to the user via the additional parameters without having to resort to the command line.

mike
I think you guessed right. Qemu_gui could set QEMU_SOUCE_DRV=alsa and leave it to the user to add additional parameters to effectively enable HD audio (perhaps a tool tip could remind of which parameters).