kvm/qemu Full Fatdog gui desktop - without X

[user1111]

There's a good starting/reference point for kvm/qemu here ...

https://docs.google.com/document/d/1SaJ ... 7-rzE/edit

When kvm/qemu is started to serve vnc, there's even no need to have X available/running on the host system. And if you're running a framebuffer cli system as the client, then no X is required there either. Despite which - you can still have a full X/gui type desktop !!!

Yep! You can run a full fatdog gui desktop despite neither your laptop (client running cli framebuffer) and server (desktop server system) having X loaded. And at near native cpu speeds assuming kvm is available/enabled/used.

qemu even supports copy on write (and snapshots), so conceptually the actual choice of gui desktop system that was being used could use that instead of having to build in aufs for save/not save type filesystem layering.

I've been tunnelling raw vnc from the (desktop) server to my (laptop) client through ssh - so its encrypted, and I've also turned on ssh compression - and the speeds are very good/network load relatively light. When both the laptop and server are on the same LAN its near-as good as running natively - at least for most things. But yes video's do start to show some lag, especially if full screened.

Framebuffer thread/post
viewtopic.php?f=60&p=8655#p8655

Building a small kernel/initrd with just framebuffer, ssh and vnc
viewtopic.php?p=6629#p6629

I'm using such a small system on my laptop (client). 5.2MB vmlinuz filesize, with initrd built in (kernel was built with xz kernel compression chosen). Boots, wifi net connects, sets up the ssh tunnel (ssh -t -f -N -L 5901:localhost:5901 192.168.1.4 ... where that 192.168.1.4 IP is my desktop systems LAN IP) - in readiness to run vnc (framebuffer vnc in my case (fnvnc)).

For the server, I'm using Fatdog (of course), booted with pfix=nox ... so just cli With qemu installed and kvm enabled (I had to set 'Secure Virtual...' in my bios for kvm to be available)

Once the server has booted to cli, I run a command something like (UK specific i.e. uses -k en-gb keyboard layout switch) ...

Code: Select all

qemu-system-x86_64 -vnc :1 -usbdevice tablet -cpu host -monitor pty -k en-gb -smp 4 -boot d -vga std -enable-kvm -m 2048 vHDD.img

The default port for vnc is 5900, in the above I set vnc to use display :1 which means that it is serving vnc to port :5901 (to avoid potential conflict if vnc were to be started on the server). The -usbdevice tablet switch helps keep potential multiple mouse cursors better aligned with each other, otherwise in some cases you can end up with two mouse cursors, near each other. In other cases its best to leave that -usbdevice switch out. The -cpu switch tells qemu to just 'emulate' the same cpu as the host systems actual cpu (rather than having qemu emulate another choice of cpu). The -smp 4 switch matches the same number of cores that I have on that PC (that doesn't however have to match, I could for instance set it to 8 and when booted qemu would emulate having 8 cores even though the hardware being used only had 4 cores). -boot d just indicates the type of boot (you can change that to boot from DVD, HDD ...etc as per the first links documentation). The -m 2048 defines the amount of ram the qemu is being allocated i.e. 2GB.

Once that is started on the server, even though the server has no X running/available, the kernel (kvm) and qemu (emulation) serve up the OS as built/stored into the virtual HDD (vHDD.img) - which again in my case I installed Fatdog. So whilst the server still remains showing just a cli command prompt, no gui, when I vnc into the server using framebuffer cli, up pops the full fatdog desktop system (gui). I'm using a vHDD for the boot, but it could equally have been a .iso ... or whatever (such as the default Fatdog64-811.iso that you use to boot/install Fatdog with).

As I tunnel vnc through ssh, its as simple as running vnc localhost 5901 (I've sym linked fbvnc to vnc) on the client (laptop). Rather than setting up a ssh tunnel as outlined above, you could use vnc directly to the server (vnc 192.168.1.4:5901 in my case), but then network traffic would be higher, due to no compression through a ssh tunnel being used.

So there you have it, both client (laptop) and server (desktop) running just cli OS's, but where you have the full benefit of a X/gui desktop. Yes full screen videos can be laggy, but still comfortable if windowed, and I haven't any sound being forwarded ... so not the full Mccoy gui desktop experience, but still generally usable (general browsing using chrome/whatever, running libre office, image editing ...etc.). And yes it is cheating, as X is actually available, it's just being run in kvm/qemu (kernel space/qemu emulation).

Some like to have multi-boot choices, different Puppy's/Dog's maybe even Windows. With a kvm/qemu server you could multi-boot different systems - at the same time. Having both a native Windows and Fatdog/whatever available on the desktop. Maybe sshfs sharing folders (directories) etc. In the above I used two different boxes, client laptop and a desktop PC as the server - but there's no reason why you might combine both into the same box - have your laptop for instance being both the kvm/qemu vnc client/server. And as qemu supports copy on write/snapshots ...etc. you don't have to have a layered filesystem in order to achieve layered filesystem like functions - such as the option to save changes, or not.

[jamesbond]

Brilliant!

[user1111]

Of course you don't have to run kvm/qemu in a framebuffer/cli. Provided kvm is available/activated you might ...

Open gslapt (in Fatdogs control panel, system tab)
Click Update
Select qemu-arm-x86_64 (4.2.0x86_64-1) to be installed, and Execute
Obtain/locate a copy of the Fatdog64-811.iso
Open a terminal
cd to where the Fatdog iso is and run

Code: Select all

qemu-system-x86_64 -vnc :1 -cpu host -usbdevice tablet -monitor pty -smp 4 --vga std -enable-kvm -m 1024 -cdrom Fatdog64-811.iso &

Then: Menu, Network, Tigervnc viewer ... and open localhost:5901

On my 1366x768 laptop it starts with a larger resolution, so I used Fatdogs control panel, desktop, display ... to change the resolution, Applied and OK'd that

F8 is the control key, i.e. toggles showing a menu list, where for instance you can select 'Full Screen'

I've used the Fatdog iso to 'boot' in the above, could equally be a puppy iso ... or whatever. Just be aware that many Pup's aren't up to Fatdog's high standards , so you might find that the mouse or whatever doesn't work. Bionic pup 64 bit version seems to work OK

s.jpg (139.77 KiB) Viewed 1374 times

b.jpg (181.47 KiB) Viewed 1372 times

PS to see if your system supports kvm, from the documentation I linked to earlier

To ensure Linux requirements are turned on in the running distro. Check to see if the kernel is turned on by:
# lsmod| egrep --color=always kvm
If it is not (no answer from lsmod command), then turn it on:
# modprobe kvm-amd (for AMD CPUs)
# modprobe kvm-intel (for Intel CPUs)
If an error message gotten from an above command, make sure your BIOS has “virtualization” set on.

Also, being able to boot a iso in isolation is OK, but its nice to also have a HDD available, such as to store changes. You might create a virtual HDD using (2GB size in this case) ...

qemu-img create vHDD.img 2G

Just append that vHHD.img name to the end of the qemu command line in order for it to be included

Code: Select all

qemu-system-x86_64 -vnc :1 -cpu host -usbdevice tablet -monitor pty -smp 4 --vga std -enable-kvm -m 1024 -cdrom Fatdog64-811.iso vHDD.img&

Once the iso has booted you will need to run gparted to create a partition table, create a partition, and format that partition (and also set its 'boot' flag on if you intend to use it a a boot device) before it can be used. Installing grub4dos onto it would also be my preference. With a vHDD setup and Fatdog initrd/vmlinuz copied onto that etc. you might drop booting the iso altogether and just boot using the vHDD i.e. drop out the -cdrom Fatdog64-811.iso switch from the qemu command line

Code: Select all

qemu-system-x86_64 -vnc :1 -cpu host -usbdevice tablet -monitor pty -smp 4 --vga std -enable-kvm -m 1024 vHDD.img &

[user1111]

Let's say that you don't want to vnc serve a entire desktop, but perhaps just chrome browser alone. For this you shouldn't have chrome already running as that would conflict with the setup (chrome doesn't like running multiple separate instances)

we can start vncserver using display :2
# vncserver :2
... that will prompt you to enter a 6+ character password (twice to verify) that will be needed by the vnc client.

and start chrome running on that
# DISPLAY=:2 google-chrome-spot &

Now in Menu, Network, tigervnc viewer we enter the IP and the display number plus 5900 as the port number

localhost:5902

and enter the password we defined earlier ... and that drops you into a vnc'd chrome session.

We used the local system as both the server and client in the above, of course they could be on different machines, in which case the client would enter the servers IP when connecting, maybe something like

192.168.1.4:5900

Fatdog runs its networking programs as userid spot for security reasons, interestingly however is if you use that vnc chrome to navigate to file:///tmp then you can see the contents of /tmp, and also see what disks and disk formats are available in the /tmp/udev-fatdog-drive-icon folder (tut-tut (bit of a security flaw ??))

[user1111]

Booting Fatdog to cli (pfix=nox kernel boot switch set), with qemu installed and kvm available, and starting kvm/qemu with the following fatdog iso boot line ...

Code: Select all

QEMU_AUDIO_DRV=alsa qemu-system-x86_64 -vnc :10 -cpu host -machine type=pc,accel=kvm -soundhw ac97 -monitor pty -k en-gb -smp 4 -boot d -vga std -enable-kvm -m 2048 -cdrom Fatdog64-811.iso vHDD.img &
sleep 3
./fbvnc localhost 5910

along with starting fbvnc into that straight after (I allowed a 3 second sleep time to give qemu a change to 'get going')

... and sound worked OK.

I've added a vHDD to that boot, that I'm using for savefile and swap

Works reasonably well, but fbvnc is the let down, not really refined enough keyboard/keys wise. I need to (yet to do) set up some xmodmap translations for certain keys.

Fundamentally the above is just cli (framebuffer) where the same laptop is both vnc client and server - that enables a full Fatdog gui desktop with sound ... without having loaded X in user-space.

Browsing youtubes etc is OK, but if full screened there can be some lag at times. Usable in the absence of anything else, however a full accelerated Radeon/whatever graphics is naturally superior for quality compared to the framebuffer. Some of that lag may be down to using seamonkey.

[user1111]

You can boot kvm/qemu using a partition instead of a iso or .img image file.

For instance I boot using grub4dos installed on sda1 with a range of menu.lst boot items, pass /dev/sda (actual hdd not the partition) to qemu, and on startup it presents the same menu.lst bootup such that I can select one of the boot choices and have that loaded into qemu

Code: Select all

QEMU_AUDIO_DRV=alsa qemu-system-x86_64 -full-screen -k en-gb -usbdevice tablet -soundhw ac97 -vga virtio -smp 2 -boot d -machine type=pc,accel=kvm -cpu host -enable-kvm -m 2000 -snapshot /dev/sda &

That will 'share' the same files on disk, so any changes made within the qemu session will be reflected onto actual disk. If however you also use the -snapshot qemu boot parameter, then its a read only session, any changes made are lost at shutdown, the changes are stored in a temporary folder that are lost at shutdown and your actual HDD content remains unchanged.

There are also options to create Copy on Write snapshots i.e. persistent recording of any changes made just for the qemu sessions.

More recent versions of Barry's EasyOS caters for booting, configuring things as you like, and then rebooting using another choice that runs that setup 'freshly' each time, all changes made during the session are lost at shutdown/reboot. You could do similar using the above qemu method i.e. boot normal, configure things, and thereafter boot/use the qemu version with -snapshot parameter so all changes are lost at shutdown (clean/pristine boot each time).

Another choice with qemu is to include -vnc :59 (or whatever port number), which then has the qemu session being served to vnc (which by default starts at port 5900, so -vnc :59 qemu parameter has the vnc session served to port :5959 i.e. have a vnc client run vncviewer locahost:5959 to vnc into that session.

You can also set things up to be able to ssh into (and/or out of) the qemu guest to/from the host (main system), so I guess you could sshfs mount a 'persistent' save folder/area for when using the -snapshot qemu boot method, i.e. broadly doesn't save changes, but where some changes could be selectively preserved to the main session, such that those changes were again evident at the next qemu boot.

[wiak]

You can boot kvm/qemu using a partition instead of a iso or .img image file.

I'm also messing around with kvm/qemu at the moment, though for different reasons. My partner wants weechat on her desktop and there is no good solution for that in Linux (aside from programs to mirror actual android screen to desktop such as scrcopy), so I'm working on using Android-86 in qemu with hope I can make it as seamless as possible to copy files between host and guest. Unfortunately I am working on too many projects right now (which is crazy since I try to work on no such projects during my summer, which is here now) so chopping and changing between them on different days (and sometimes losing track on the way...).

wiak

[user1111]

OpenBSD on my laptop is awkward as the wifi adaptor isn't supported, so I have to tether it/use my phone as a wifi hotspot, or plug in a ethernet. Alternatively I can boot Fatdog, wifi net connect in that, and then kvm/qemu OpenBSD - which then picks up the Fatdog's wifi network connection as though it was hard wired. To install/run OpenBSD using Fatdog kvm/qemu ...

Code: Select all

qemu-img create -f qcow2 disk.qcow2 32G
wget https://www.mirrorservice.org/pub/OpenBSD/6.8/amd64/cd68.iso

.. something like a 10MB download

Run that installer:

Code: Select all

qemu-system-x86_64 -m 2048 \
  -cdrom cd68.iso \
  -drive if=virtio,file=disk.qcow2,format=qcow2 \
  -enable-kvm \
  -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:2222-:22 \
  -device virtio-net,netdev=mynet0 \
  -smp 2

I allocate 2048MB to the qemu (-m 2048 parameter) you may want to revise that up or down according to your hardware.

Run through the installation process, mostly the default options will suffice. When installation has completed, select the Halt choice and once that finishes close the window. Note that you're not installing to your actual disk(s), its being installed to the virtual/qemu 32GB disk as created in the first line of code above.

Then boot that

Code: Select all

 qemu-system-x86_64 -m 2048 \
  -drive if=virtio,file=disk.qcow2,format=qcow2 \
  -enable-kvm  \
  -netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:2222-:22 \
  -device virtio-net,netdev=mynet0

Note that if you enabled sshd then the above maps localhost port 2222 to the guest (openbsd) ssh port 22 i.e. in fatdog 'ssh localhost -p 2222' ssh's into the OpenBSD system. If you've sshd running on the host then you can ssh from the guest to that using ssh 10.0.2.2.

To configure OpenBSD typically I edit/create ...

~/.Xdefaults add ..

Code: Select all

Xft.dpi:144
xterm.faceName: DejaVu Sans Mono
xterm.faceSize: 12

.xsession ... create and add ...

Code: Select all

xrandr --output default --mode 1280x768
cwm

.cwmrc and add

Code: Select all

fontname "DejaVu Sans:size=11:antialias=true"

... for a cwm window manager choice (that OpenBSD contains by default). cwm is awkward at first if you're not used to it, so you might prefer to install jwm instead (pkg_add jwm, and in the above .xsession file change 'cwm' to 'jwm').

To install packages into OpenBSD ... use pkg_add, for instance I install

Code: Select all

pkg_add ssvnc-viewer 

... to install vncviewer

In the attached image I've booted fatdog, kvm/qemu'd OpenBSD as per the above, and then within that vnc'd into another Fatdog bog (vncviewer 192.168.1.4) in which I'm running vlc playing some music. The fonts don't look good in that image because I've scaled things down, at normal full screen resolution levels (ctrl-alt-F toggles full screen) they look fine/great.

[user1111]

Pushing sound from the kvm/client through qemu, and I was encountering jitter/stutter. Compiling sndiod for Fatdog and using that ... and the kvm/qemu session runs smoother/quicker/better for me.

i.e. In Fatdog host

sndiod -d -a on -f rsnd/1 -L- 2>/dev/null &

(use rsnd/0 if you use sound card 0 instead of 1)

Start qemu and for instance AUDIODEVICE=snd@192.168.1.5/0 firefox-esr

where 192.168.1.5 is the IP of my Fatdog host.

I'm running OpenBSD as the qemu guest, so firefox-esr is compiled with sndio support, as is mpv (for mpv run it with -ao=sndio parameter).

Haven't tried it, but I guess that you could forward sound for different programs to differences devices. i.e. just set up a sndiod -L- (listening) on whatever device(s) and for each program set whichever you prefer as the target to receive/play the sound. mpv played to whatever device you have attached to your TV, firefox sound to your laptops speaker ... whatever.