Here's a Guide to run Multiple PUPs simultaneously - KVM

Virtual machines, emulation, etc.
Message
Author
gcmartin

Here's a Guide to run Multiple PUPs simultaneously - KVM

#1 Post by gcmartin »

Tired of rebooting whenever you are testing a new PUPPY distro; if so, read on.

When Microsoft bought VirtualPC, Linux kernel developers responded after evaluating, the then current, alternatives. They then settled on added virtualization ability in the Linux kernel, now known as KVM. It has been around since as long as 64bit PCs became available to consumers.

This feature of the Linux kernel allow running additional distros, simultaneously with your booted distro.

Puppy's current "official" 64bit offerings have this feature built-in. And, observing shows that the KVM booted distros perform at native speeds. (In fact, in my testing, FATDOG runs faster. So fast, that the only way I know I'm on the subsequent FATDOG is by its blinding speed. FATDOG normally is fast, but, for some reason, running via KVM "appears" faster.)

Here's is a PUPPY Linux Guide to running several PUPs side-by-side without lag. <=== Click here

This Guide can be used no matter if you are running Live or Frugal or Full. The distro you boot has immediate access to the internet just like anyone has when booting on a real PC.

Knock it around; kick the tires; see for yourself. Impress yourself and your friends as you show them how you can run several distros simultaneously without lag. Or dedicate one distro for Internet, while another for local needs. You are only limited by the number of creative ideas you might think of.

Here to help

IMPORTANT NOTE: The Guide provides a test to insure your CPU has the KVM "acceleration" feature. If your PC shows you have the feature and your secondary distro boots slowly, PLEASE REVIEW THIS POST ABOUT YOUR BIOS! In all cases, one should expect the additional guest PUP to run at a native speed.

Edited: typos.
Last edited by gcmartin on Mon 01 Jun 2015, 04:08, edited 9 times in total.

gcmartin

#2 Post by gcmartin »

The Guide shows the 2 things required to allow running/testing a PUP while running your main PUP: namely
  1. Add the PET to your main running system to allow this to occur
  2. While your main system is running, boot an additional ISO desktop right before your eyes
Its really that simple.

Update 1: The guide contains tested procedure for sharing content that the "Host" distro has with a distro running in the "Guest".

The Guide, in the post below, covers how to do this.
Last edited by gcmartin on Fri 16 May 2014, 09:45, edited 4 times in total.

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#3 Post by slavvo67 »

GCMartin:

I read between the lines and note you mentioned 64 bit. Does this mean a 32 bit will not have this ability? I'm still leaning towards the 32 bit pups. Considering that I have a hundred or so cd's burned, this might be a nice alternative and certainly a more environmentally friendly one.

Kind regards,

Slavvo67

gcmartin

#4 Post by gcmartin »

The steps in the Guide was tested using 64bit systems because those, of mine, are the primary distros I now run and test with.

I have not taken the time, yet, to test the Guide's directions using a 32bit PUP. But, I would guess that if they pass the lsmod test, shown in the document's 1st steps, that you could use 32bit QEMU PET/SFS to accomplish the same that the User Guide shows on a 32bit PUPPY distro as the main running system. If you are running FD64/LH64 desktops, you can boot either 32/64 bit distros in the guest as shown. The guest(s) you boot can do any productive tasks just as if they were running alone on the PC.

Just a note, every 64bit PC comes/came with a minimum of 1GB of RAM. This, in most cases, affords the user enough RAM to get good performance in running their main distro while testing a 32bit PUP distro, side-by-side. I think that is what you are asking. Thus the 2 most important items for excellent performance is the CPU feature (only a very,very,very few 64bit PCs, Atoms, did NOT have it) and of course, RAM.

Further, I hope everyone understands that the Guide works, no matter if you are running a Live PUP, a Frugal PUP, or a Full PUP. And, it instructs to allow booting of another 32bit or another 64bit distro while also having the main distro active, too. "I know, I'm redundant in saying this. But those who have run a VM system understand why I repeat this statement."

If any issues are found, please report them. And if there are any improvements noted, please share them.

Hope this helps

User avatar
neerajkolte
Posts: 516
Joined: Mon 10 Feb 2014, 07:05
Location: Pune, India.

#5 Post by neerajkolte »

Hi gcmartin,

The new qemu v2.0 sfs and pet didn't work in Fatdog64-630.

When sfs is loaded all system fonts change to square blocks had hard time unloading the sfs. Problem went away when after unloading.
The pet gave following output in terminal..

Code: Select all

# qemu-system-x86_64 -enable-kvm -m 1024 -cdrom /aufs/devsave/LinuxTools/precise-5.7.1.iso                       
qemu-system-x86_64: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
Older qemu 1.5.3 pet from Fatdog Package Manager works nicely.
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.â€￾
- Amara’s Law.

User avatar
Whitesnow
Posts: 118
Joined: Tue 20 Nov 2007, 19:18
Location: Italy

QEMU 2.0.0 64 bit

#6 Post by Whitesnow »

Hi neerajkolte and everyone. I'm the author of QEMU 2.0.0 SFS, so I reply for my package (that gcmartin had converted in PET).
neerajkolte wrote:The new qemu v2.0 sfs and pet didn't work in Fatdog64-630.
I compiled QEMU for LHP 64 bit, that is based on Slackware binaries. Your main problem is that Fatdog64 is based on Ubuntu, as far as I know. Therefore, compatibility is not guaranteed.

Take a look at http://murga-linux.com/puppy/viewtopic.php?t=88604

For forum information, as gcmartin current QEMU SFS link is mine:
please, if you want to share, don't link directly my repo resources. They often will be overwritten by newer versions or can be moved for more efficient folder organization or for hosting reasons. Don't leave orphan links all over the web, browse repository instead (that is safe to link).

Bye.
[b][i][color=darkred][size=134]*.* Snow *.*[/size][/color][/i][/b] :wink:

gcmartin

#7 Post by gcmartin »

In the Guide, it references a QEMU version 1.53 PET in the additional software section. That version is from @JamesBond, last year and it works for both FATDOG and LightHouse64.

User avatar
neerajkolte
Posts: 516
Joined: Mon 10 Feb 2014, 07:05
Location: Pune, India.

Re: QEMU 2.0.0 64 bit

#8 Post by neerajkolte »

Whitesnow wrote:I compiled QEMU for LHP 64 bit, that is based on Slackware binaries. Your main problem is that Fatdog64 is based on Ubuntu, as far as I know. Therefore, compatibility is not guaranteed.
I didn't know two 64bit distributions are that different. I thought may be just some problem with dependencies. I am quite new to linux. Just using fatdog for 3 months only. This looks like nice opportunity for me to learn making pets and sfs from source. :-) Thanks.
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run.â€￾
- Amara’s Law.

stemsee

KVM

#9 Post by stemsee »

Hi gcmartin

I just tried this on my Emsee-2nd Edition pup which is 32bit precise derivative. When i ran the command to boot the iso i get this 'VNC server running on127.0.0.1:5900' then there is disk activity as though booting the iso. . Upon connecting vnc viewer, a box flashes open and shut. So it works but I have not been able to keep the vnc viewer open, as yet. Firefox returns RFB 003.008 - i tried an online vnc viewer but it reports a problem with the connection or vnc server settings. So it all works, just can't see it!

slavvo67
Posts: 1610
Joined: Sat 13 Oct 2012, 02:07
Location: The other Mr. 305

#10 Post by slavvo67 »

I have yet to try this but I can see it as a great addition to someone like me that burns many different ISO's over the course of a year. Trying this is definitely on my list of "to do".

Best,

Slavvo67

gcmartin

#11 Post by gcmartin »

Thanks @Stemsee.

What he share is EXACTLY WHAT IS NEEDED! ... Feedback!

For those who have looked over the Guide they are seeing 2 "Approach-es" to running a 2nd/subsequent PUP distro. Approach #1, the command line approach and Approach #2, the GUI launch tool approach.

The launch tool option for VNC was not tested: and therefore was not included in the Guide and its discussion.

I propose that we tackle the VNC approach in a separate thread or on the "QEMU Launch" thread as that is where it is made prevalent in that tool's offering. Here's why: Currently, the Guide DOES NOT address using the "real" LAN that the PC is attached to via the main running distro (the Host). Thus, currently, the Guide does show the setup where the additional distro (the Guest) can access the Internet but, their is no ability, demonstrated in the Guide for extending this to the real local LAN.

That extension in the KVM discussion is certainly on my horizon, just not addressed just yet.

So, to do so, we will need to show how the Bridge-Utils can be made to allow the Guest to be accessed via VNC from another PC on your LAN, just as is done for a Real PC attached to your LAN. (I am sure that some of you have noticed that in the "Additional Software" section of the Guide, this utility is shown while there is no discussion about it, ... that is, no discussion about it yet)

I am hopeful that as more and more members become aware of this Linux feature and its current implementation, that we will mature to use the many great thing that Open Source provides in Linux to expand the scope and understanding on the benefit of KVM in the kernel.

In a nutshell, I am looking forward to building instructions to allow those who do use this LInux feature, to boot virtual PCs (teh Guests) so that they look like "Real PCs" on the LAN. (I believe that @JamesBond has actually done this using FATDOG/KVM.) We just need to gather instructions together to do so.

In the meantime, the Guide is helpful to allow members to simply download and "fire-up" any PUP of their choosing. And, because of its current state in the Guide, there is extremely useful built-in security to the overall running distro as well as within the virtual distro as well. Thus, it adds a level for those who would want an isolated environment for banking and other such kinds of concerns.

The Guide attempts to provide an easy and safe step into the fruits of this LInux technology so users have excellent understanding of what they are doing. So, its not just a simple Guide, it expand the knowledge and options for using their PCs, easily for the day-to-day PUP stuff we do.

So, in a nutshell, expect that the Guide, and the Linux tools shown will expand to add additions to take advantage of the features that Linux has given us.

I am hopeful that if FATDOG/LightHouse/Slacko64 advances into the future, they will see fit to incorporate Bridge-Utils in the base system for the advantages that 64bit systems offer in resources to use. The additional cost is too little to not have the benefit available for it extends well beyond just KVM in the local system.

Hope this helps.

User avatar
mikeb
Posts: 11297
Joined: Thu 23 Nov 2006, 13:56

#12 Post by mikeb »

I choose the vnc option and connect to it by launching vncviewer.
I used 127.0.0.1:1 for a local connection to test.

So only 3 points... has :1 been used, is there a firewall on, has the vnc command line for qemu changed .. i use -vnc:1

mike

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#13 Post by jamesbond »

neerajkolte wrote: The new qemu v2.0 sfs and pet didn't work in Fatdog64-630.
When sfs is loaded all system fonts change to square blocks had hard time unloading the sfs. Problem went away when after unloading.
That's because the SFS keeps keeps stuff in /usr/etc instead of /etc.
The pet gave following output in terminal..

Code: Select all

# qemu-system-x86_64 -enable-kvm -m 1024 -cdrom /aufs/devsave/LinuxTools/precise-5.7.1.iso                       
qemu-system-x86_64: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
Older qemu 1.5.3 pet from Fatdog Package Manager works nicely.
Yup, missing dependency. As it was built in LHP64 it picked up whatever library there.
Whitesnow wrote:Fatdog64 is based on Ubuntu
Fatdog64 is based on T2-build, similar to Puppy Wary/Racy (but 64-bit while Racy/Wary is 32-bit), not Slackware or Ubuntu.
I compiled QEMU for LHP 64 bit, that is based on Slackware binaries
LHP64 is a derivative of Fatdog64, with a lot of additional programs and libraries (and polish!) on top of Fatdog base. It is *not* based on Slackware. The problem is exactly that - LHP64 has many additional libs that Fatdog doesn't have.

I am hopeful that if FATDOG/LightHouse/Slacko64 advances into the future, they will see fit to incorporate Bridge-Utils in the base system for the advantages that 64bit systems offer in resources to use. The additional cost is too little to not have the benefit available for it extends well beyond just KVM in the local system.
bridge-utils is already built-in to Fatdog since 630. For earlier versions, use "busybox brctl" which does the same thing.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

gcmartin

#14 Post by gcmartin »

JamesBond wrote:bridge-utils is already built-in to Fatdog since 630. For earlier versions, use "busybox brctl" which does the same thing.
Thanks @JamesBond. Good guidance and understanding.

I will remove that application link from the Guide, as its not required for the PUP distros that the Guide is built on and could be cause for user confusion (certainly was the case with me).

What this means is that both FATDOG and LightHouse64 are fully featured such that only QEMU is required to be instantly operational to boot additional distro and to do more advanced uses of the booted distro(s), the guest(s), than what the simple, "get started" items", that the Guide already demonstrates.

Most importantly, additional distros (the guests) could provide important functions for users in addition to what the main desktop (the host) is being used for.

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#15 Post by Ted Dog »

anyone recall the other method if your uefi machine hardware HAS virtual hardware builtin but removed from settings by Microsoft loader. Found a website to hack UEFI by flipping bits and re flashing but would rather fake out QEMU or have it NOT use the more modern driver system. I use Fatdog64 630.. Thanks.

User avatar
Whitesnow
Posts: 118
Joined: Tue 20 Nov 2007, 19:18
Location: Italy

#16 Post by Whitesnow »

jamesbond wrote:
neerajkolte wrote: The new qemu v2.0 sfs and pet didn't work in Fatdog64-630.
When sfs is loaded all system fonts change to square blocks had hard time unloading the sfs. Problem went away when after unloading.
That's because the SFS keeps keeps stuff in /usr/etc instead of /etc.
So a couple of links could fix, I wonder.
Anyway, I've just compiled again (in Fatdog64 and correcting paths) 2.0.0. It works for LHP, too. I've tested both.
Please, note that this one will be, probably, my last effort in QEMU support for Puppy, because my hardware is going dated (I cannot use QEMU anymore since last versions, I can only make a very slow X-test after compiling). So, all my last packages were a gift for community, not usable by me.
I'm going to upload, on my repo, new packages (SFS and PET) in the next hours. Check availability in this thread, monitor for updates: http://murga-linux.com/puppy/viewtopic.php?t=88604.
For those of you that have still downloaded old SFS, to avoid mistakes, this is md5 checksum of the new one: ffe06d0edb37de3edf4797463053875b.
jamesbond wrote:
Whitesnow wrote:Fatdog64 is based on Ubuntu
Fatdog64 is based on T2-build, similar to Puppy Wary/Racy (but 64-bit while Racy/Wary is 32-bit), not Slackware or Ubuntu.
I remembered that someone talked about what I wrote (I read that), maybe because, in the past, Fatdog64 wasn't build in pure T2 like it is now.
jamesbond wrote:
Whitesnow wrote:I compiled QEMU for LHP 64 bit, that is based on Slackware binaries
LHP64 is a derivative of Fatdog64, with a lot of additional programs and libraries (and polish!) on top of Fatdog base. It is *not* based on Slackware. The problem is exactly that - LHP64 has many additional libs that Fatdog doesn't have.
Let me say what I read, one more time. LHP64 is, nowadays, based on Fatdog64 kernel (thank to you and Kirk), but core packages are from Slackware (glibc, gtk, cups, xorg-server and dependencies). This condition is relevant in our topic, as my old QEMU package compiled in LHP, as I just tested, can't run in Fatdog64 not only for lack of libraries, but for dissimilarity of glibc version, too.

Bye.
[b][i][color=darkred][size=134]*.* Snow *.*[/size][/color][/i][/b] :wink:

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#17 Post by jamesbond »

Whitesnow, I can only say thank you for your service to the community here. My previous post was meant as a clarification for everyone concerned - not to discourage you at all.

I don't understand, though, why qemu 2.0 is giving you problem? I haven't tried it myself (I'm still on 1.6.2 - don't see the need to upgrade) but as far as I know if you don't enable kvm then it should work even on older machines without hardware VT-assist; and qemu is well known to have decent speed even without acceleration.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

gcmartin

Slacko64/FD630/LightHouse64 - tested stable n KVM kernel use

#18 Post by gcmartin »

Version 2.0 PET from @WhiteSnow works in Slacko64, FD630 and LH64-602b. The steps tested for each distro were the approaches shown in the Guide.

Simple to use
To use QEMU V2+, instead of the older PPM versions to gain QEMU on your system (shown in the Guide), advance to the bottom of the Guide, select and download QEMU V2, and install.

Also, note, that current versions of, both, QEMU by Puppy member @WhiteSnow and QEMU Launcher by Puppy member @MikeB can be obtained by the links in the Guide.

Here to help

gcmartin

#19 Post by gcmartin »


step
Posts: 1349
Joined: Fri 04 May 2012, 11:20

#20 Post by step »

gcmartin wrote:Update 1: The guide contains tested procedure for sharing content that the "Host" distro has with a distro running in the "Guest".
Thanks. The guide seems to imply that one can use FatDog64 to connect a share via the SAMBA server subsystem. It includes a picture of a desktop menu selection of Network>Samba Simple Management. I can't find such a tool in FatDog64-631. Is it an additional pet for FatDog?
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]

Post Reply