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

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

[rufwoof]

i suspect Puppy on the same lan segment as other PC's/HDD's is common belham2.

Just been trying qemu over vnc. It can for instance be run using

Code: Select all

qemu-system-x86_64 -vnc :0 -monitor pty -k en-gb -smp 4 -boot d -vga std -enable-kvm -m 1020 -cdrom xenialpup64-7.0.8.5-uefi.iso -hda vHDD.img

where that -vnc:0 redirects graphics display to vnc. In that case I'm booting XenialPup64 iso and have a vHDD that is just ext3 formatted, not set as bootable, no grub4dos ... just using it for savefolder space.

Basically that parameter set is saying use vnc and when you do that you should specify the keyboard (-k en-gb in my case, other choices being ar de-ch es fo fr-ca hu ja mk no pt-br sv da en-gb et fr fr-ch is lt nl pl ru th de en-us fi fr-be hr it lv nl-be pt sl tr)

allocating 4 cores and boot d indicates to boot cd first

-boot c - Boot the first virtual hard drive.
-boot d - Boot the first virtual CD-ROM drive.
-boot n - Boot from virtual network.

allocating 1GB memory (-m 1024).

Weird, but whilst I have 4 cores and set smp to four cores, you can increase that. Running -smp 8 for instance has htop showing 8 cores (supported feature, not a bug).

I'm running that from a debian host, into which I also installed xtightvncviewer, so starting the above and then running xtightvncviewer :5900 ... and up pops the Xenial boot screen. A annoyance is that the mouse is seamless, but that does mean that when you mouse from debian across the xenial window you have the two mouse pointers that don't align, so if you reach for a menu option within Xenial for instance the debian mouse can take over and be outside of where intended. Also that's not set up for sound over vnc, so whilst videos play ok within Xenial, there's no sound (yet).

Response wise, playing videos was OK, but not great, not as smooth as if played directly on the host.

If used for isolation however its good. For instance Xenialpup hosting a copy of the same Xenialpup as a guest and using the guest version for browsing etc. does isolate hardware from risk.

You can set things up to just run a specific program such as firefox, so you could have one qemu guest to run that, and perhaps another to run vlc ...etc. Each program isolated in its own virtual space running as root but with limited damage risk (content of the virtual space). Far more acceptable to not having to resort to isolating Puppy from the rest of the lan.