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

[Whitesnow]

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.

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.

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.

[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.

[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]

Update 1

[step]

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?

[gcmartin]

Hello @Step

... I can't find such a tool in FatDog64-631. Is it an additional pet for FatDog?

That tool, shown in the Guide, is one that is included in all Slacko64 and LightHouse64. It was developed by 01Micko 4 years ago to make life so very simple for Puppy Linux users to understand and share a folder with its LAN community of users. Thus Slacko and LightHouse64 users have it so easy with almost little thought to do this sharing from its desktop.

FATDOG64 is a bit behind the times as it uses an older SAMBA and it does NOT approach users the same way. FATDOG also has not adopted 01Micko's simple solution at this time.

But, I think, I can help. Do this and report what you see.

1. Open a terminal on FATDOG
2. Paste the results on this command to this thread

   Code: Select all

   bash-4.1# smbclient -U% -L localhost

Someone will respond

UPDATE
I will make changes in the Guide for FATDOG in a pristine state. Your answer for FATDOG sharing is here.

Here to help

[ETP]

I am posting this as a warning to others not to make the same mistake as I did which resulted in initial failure.
There is nothing wrong with gcmartin’s excellent guide but it needs to be followed exactly. The bash test in the guide which should indicate vmx or svm was passed and having a recent PC, I falsely assumed that KVM would be enabled in the BIOS. It was not and that test merely shows “capability

[mikeb]

Yes it appears common that virtualisation is disabled in the bios.... in my case I would have to update the bios and the default is disabled after that.

After all why would anyone want to run anything other than windows 8...so lets make sure they cannot.
Reminds me of when usb booting was disabled in new machines..

Mike

[gcmartin]

In looking over the thread, I think this post may have been missed. I will attempt to help.

I read between the lines and note you mentioned 64bit. Does this mean a 32 bit will not have this ability? I'm still leaning towards the 32 bit pups ...

The Guide was built and tested with the 64bit PUP distros shown. Once one of those PUPs is setup using the procedures in the Guide, the PUP will allow anyone to boot "any" x86 distro's ISO you might have...ANY.

... Considering that I have a hundred or so cd's burned, this might be a nice alternative and certainly a more environmentally friendly one.

Correct. This means that you can use a single 64bit PC to run several virtual PCs at the same time. This is great for additional booting a test ISO or booting one for a special mission like banking or like a TOR or ... or ... or ...

This is easy and simple to do.

Hope this is helpful

P.S. The Guide was created using 64bit PUP PCs because most every non-ATOM PC, even some ATOMs, too, has adequate resources for a successful KVM venture with no trouble. There are 32bits which carry the KVM feature, but I leave that for user evaluation and testing. Thus, the intent is to provide a Guide with the greatest opportunity for user success and NO frustrations.

[gcmartin]

Important Note: EmSeeV2 is the very first (1st) 32bit PUPPY distro that come with EVERYTHING preinstalled (OOTB) to immediately boot other distros, once on the EmSeeV2 desktop.

A tremendous speed increase is made available, primarily, thru the inclusion of the kernel's KVM module that some/many PC CPUs have from the factory.

There is an issue with hostname. FirstRUN is the simplest and best that resolves the problem without taking other steps and having to reboot EmSeeV2. Care must be taken should you want to ALSO run a 2nd EmSeeV2 as a VMguest while also running EmSeeV2 as the main system (VM host); or if you want to run several VMguests on an internal (to VM host) network with the VMguests LAN linked to each other.

Take it for a spin. I will bring an updated User Guide showing a one step boot a distro via the EmSeeV2 Menu, soon.

Here to help

[stemsee]

On the desktop bottom right corner click setup > gui opens next click internet , another gui opens.... on the bottom right of that gui is the hostname, type any hostname in the field and click the big green tick! There hostname resolved!

[gcmartin]

Thanks @StemSee. I posted on the EmSee thread to show a bug in EmSeeV2 hostname processing. But, for all VMguests a user boots which has FirstRUN, this hostname issue does not exist in the system's fields or in the LAN announcements to set pathways by name.

The QEMU features do indeed work on this 32bit distro.

[gcmartin]

1st
There is a new "Laucher" from @MikeB expanding ease of use & clarity.

And
A Puppy forum member, @Gobbi, explains here, how to assign a set of PC resources for use in a Guest virtual machine.

This is one additional solution on how to have 2 PUPs running off of one PC...protected from each other.

This allows a PC which has 2 video monitors, 2 keyboards, 2 mice, and optionally 2 sound cards to run separately on the same PC.

He explains how to assign those resources so that the 2nd distro boots using them, exclusively. Thus one person can have 2 systems on his physical desk running off one PC; or 2 people can individually, independently run, all the while on a single PC.

Here to help

[gcmartin]

A method, shared by @StemSee, has been shown on use of KVM WITHOUT creating or using Virtual Disk(s). Thus, his effort shows us how to boot the same system drive, HDD/USB/SSD/SDcard that was used to boot the PC. The thread is found by clicking here.

[rufwoof]

Bumping a old thread ...

Virtualisation is a good way to run Puppy. Running as root and any breakout from your browser or whatever potentially leaves a hacker sitting in root and able to access anything on your local lan, reformat disks ...etc. Whilst a corrupted Puppy might be easily/quickly reinstalled, other PC's or hardware devices on the same lan attacked by a hack might be much more troublesome to resolve. A pet hate of mine is how mozilla publish details of vulnerabilities that have been fixed in version x.y.z as that leaves anyone still running earlier versions more exposed (hackers given clear guidance of where to focus efforts).

Containers, chroot and Jails have known vulnerabilities, virtualisation is a better choice (for instance a vulnerability is to chroot out of a chroot; containers might still have access to hardware/HDD's etc that could have the partition tables wiped or whatever)

As a refresher (for this short guide, you either tick all the following four boxes or otherwise will have to dig deeper elsewhere (for instance this guide by gcmartin is a good starting point))

1. Ensure virtualisation is enabled in your BIOS, even though it might be supported if its set off in BIOS things wont work.

2. Ensure your system supports virtualisation, if neither of the following produce a return then you're out of luck

Code: Select all

cat /proc/cpuinfo | grep vmx
cat /proc/cpuinfo | grep svm

3. Is kvm module loaded ... if

Code: Select all

lsmod | grep kvm

returns nothing then run
for amd

Code: Select all

modprobe kvm-amd

or for intel run

Code: Select all

modprobe kvm-intel

4. is qemu2 installed? If not open PPM and update repositories and search for/install qemu2

Great, got to the end with all the boxes ticked ... then fire things up. You'll need a ISO of whatever puppy you want to run (for simplicity I'll call it 1.iso) and in a terminal run (assuming you're on a 64 bit PC)

Code: Select all

qemu-system-x86_64 -enable-kvm -m 1024 -cdrom 1.iso

I also tend to add -k en_UK to those parameters to set a UK keyboard, and add -soundhw all in some cases if the sound doesn't otherwise work (isn't detected). When you mouse click inside the virtual window the mouse gets locked in, Ctrl-Alt key combination releases that. Ctrl-Alt-f key combination toggles full screen

Within that puppy session your hardware is secure, even if a breakout occurs whilst browsing they're dropped into a limited space where little damage might be done.

Want to add a vHDD so you can save changes ...etc.

Code: Select all

qemu-img create vHDD.img 2G

run in a host terminal creates a 2GB vHDD and just append that name to the end of the startup command

Code: Select all

qemu-system-x86_64 -enable-kvm -m 1024 -cdrom 1.iso vHDD.img

After booting that, don't forget to run gparted to create a partition table, format the disk to ext3 or whatever, and set the boot flag on ... along with installing grub4dos (or whatever bootloader you prefer) and creating an appropriate menu.lst. If you copy the puppy.sfs, zdrv, initrd.gz, vmlinuz ...etc. files to that HDD (i.e. frugal install to the vHDD) thereafter you can boot without the ISO

Code: Select all

qemu-system-x86_64 -enable-kvm -m 1024 vHDD.img

[wiak]

2. Ensure your system supports virtualisation, if either of the following return nothing you're out of luck

Code: Select all

cat /proc/cpuinfo | grep vmx
cat /proc/cpuinfo | grep svm

Thanks for the useful quick step-by-step summary. Only thing I wondered is if that should be 'neither of the following' above, rather than 'either' (or do both need to provide output?).

wiak

[rufwoof]

Thanks wiak. One or the other has to return a result i.e. either svm or vmx needs to be present. I've corrected the earlier posting.

[rufwoof]

qemu runs surprisingly well on my setup. Currently I have a debian jessie frugal host running xenialpup64 guest, along with a ftp server setup on the host as a gateway for transferring files between the guest and host. I have that arrangement set to auto start the xenialpup guest at host startup (reboot).

A thought is that I've not seen such a Puppy default remastered (or otherwise) arrangement, such as XenialPup64 including a xenialpup64 guest. Yet that setup is very secure, running root within a guest virtual session is very restrictive in the event of a breakout from a browser or whatever as the only disk(s) that might be reformatted or any other damage is contained to what is within the virtual session, not the main actual HDD/PC. Puppy's gFTP makes it easy to share files between the two.

All the benefits of running as root, with considerably reduced risk (better than containers, jails etc.). And of course you could run multiple guests ... different Pup's or even Windows within that. Whilst when it comes to accessing actual hardware, its just a matter of switching to the host level (that generally you might not use for such things as using a browser or other external internet activities... restrict yourself to do all of those sorts of things from within the virtual guest sessions).

A nice clear separation/protection of your important files and hardware whilst retaining great flexibility/ease of use.

In general operation about the only thing that gives it away that you're running a guest is scrolling the browser window is a bit slower, as is moving windows around (still highly usable, but just not quite as snappy/quick). That may be because I've not set up the graphics other than setting the same resolution for both host and guest and I'm using a -vga std qemu boot (not the qxl nor vmware alternative choices).

[rufwoof]

A further thought. If all internet facing apps are contained within a virtual session (guest), and you use something like remote desktop from the host to view those, the virtualisation graphics lag is moved over to being under the host graphics, whilst all of the risk is contained within the guest. For instance browser running within guest that is being viewed by remote desktop from the host to the guest. If a web site forces the browser to crash and run arbitary code to download and run a file, then that has limited access to what it can do (could for instance reformat the HDD, but that would be the virtual HDD contained within the guest, not that actual PC's main HDD).

[belham2]

Bumping a old thread ...

Virtualisation is a good way to run Puppy. Running as root and any breakout from your browser or whatever potentially leaves a hacker sitting in root and able to access anything on your local lan, reformat disks ...etc. Whilst a corrupted Puppy might be easily/quickly reinstalled, other PC's or hardware devices on the same lan attacked by a hack might be much more troublesome to resolve.

It's kinda hard for a puppy, ddog or whatever I'm playing with to breakout when the first thing I do is completely remove SAMBA. Also on any Debian/Ubuntu updates with Ddogs, if it puts anything back in related to SAMBA, I delete it again. Plus, I don't know why anyone would run a pup and/or ddog that is not on its own, separate (though) secured network for just pups/ddogs/experiments. It's too stinking easy, for example with DD-WRT, among other options, to set up separate home secure virtual lans (vlans) that cannot see one another and/or interact with another in any way. Seems careless and crazy, given the wide-open (read: unaudited) nature of this forum and also how things are in the world today, to operate any other way.