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

Virtual machines, emulation, etc.
Message
Author
gcmartin

#21 Post by gcmartin »

Hello @Step
step wrote:... 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

User avatar
ETP
Posts: 1193
Joined: Tue 19 Oct 2010, 19:55
Location: UK

KVM Host Operation

#22 Post by ETP »

I am posting this as a warning to others not to make the same mistake as I did which resulted in initial failure. :oops:
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
Attachments
Asus_Bios.jpg
(54.04 KiB) Downloaded 1221 times
Regards ETP
[url=http://tinyurl.com/pxzq8o9][img]https://s17.postimg.cc/tl19y14y7/You_Tube_signature80px.png[/img][/url]
[url=http://tinyurl.com/kennels2/]Kennels[/url]

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

#23 Post by 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

#24 Post by gcmartin »

In looking over the thread, I think this post may have been missed. I will attempt to help.
slavvo67 wrote: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.
slavvo67 wrote:... 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

A 32bit Puppy with most everything builtin

#25 Post by 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
Last edited by gcmartin on Thu 24 Jul 2014, 23:36, edited 1 time in total.

stemsee

#26 Post by 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

#27 Post by 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

How to run guest VM w/2nd setof monitor+keyboard-mouse+sound

#28 Post by 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

Boot a Guest from the same drive as the running Host

#29 Post by 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.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#30 Post by 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
Attachments
s.png
xenialpup64 host running xenialpup64 virtual (guest)
(117.6 KiB) Downloaded 477 times
Last edited by rufwoof on Mon 25 Sep 2017, 00:14, edited 2 times in total.

wiak
Posts: 2040
Joined: Tue 11 Dec 2007, 05:12
Location: not Bulgaria

#31 Post by wiak »

rufwoof wrote: 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

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#32 Post by 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.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#33 Post by 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).

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#34 Post by 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
Posts: 1715
Joined: Mon 15 Aug 2016, 22:47

#35 Post by belham2 »

rufwoof wrote: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.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#36 Post by 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.

Post Reply