Hi All,

I have a need for a permanently-on virtual Slackware machine which I want to run headless on an old laptop, IBM Thinkpad T410 (i5). My first thought was VMWare ESXi. For some reason I'm unable to download version 6.5 without starting a trial, however version 6.0 says my laptop has 3.8GB of RAM instead of the required 4, so refuses to install. I guess it's the same story with 6.5 anyhow.

Next I tried XenServer 7.0, which took about 15 minutes to boot, and was pretty much unusable. There is obviously something wrong with it on my hardware. I tried XenServer 6.5 next, and got much further, booted into a running system, but then the fun began: First I tried some pygtk application: OpenXenManager, however it seems to like crashing a lot. I tried to install an operating system using install media as Slackware wasn't listed, but couldn't select any ISO. A Google later I realised an ISO store has to be setup. So I setup an NFS share on my NAS, entered the location, and OpenXenManager crashed. I did the same thing again. Back in OpenXenManager once more I realised I'd somehow created two ISO stores with the same name, so I copied my Slackware ISO onto the share, but I don't get the option to select it to install from. I kind-of gave up at that point as it seemed XenServer was not for me.

I don't want to install a Windows 10 virtual machine to manage my instances, so I wondered if I should possibly be using bare Xen for this. There are some pretty comprehensive instructions here:
http://amree.github.io/2012/09/12/ge...-on-slackware/
however compiling Xen from SBo failed with an error for me.

So cut a long story short, I thought I would ask the forum, in case I can avoid all this complexity somehow.

How can I easily get virtualised Slackware (headless) on this hardware?

• I don't care what dom0 (or whatever terminology is appropriate) distribution I use, but I prefer it doesn't swallow the majority of that 4(3.8?)GB of RAM. Slackware would have been a nice choice in this respect, but isn't the only contender.
  
• I don't care what virtualisation tech I use so long as it's free.
  
• I just need a Slackware guest I can access remotely, from another Slackware desktop machine.

If you have a setup like this and you didn't have to jump through hoops to get it please let me know what you use.

Thanks!

You can install docker and run a Slackware image from the docker registry, however the docker environment has a lot of unique challenges from the point of view of Infrastructure Engineering, so if your doing anything other than application development with it, make sure it's an appropriate platform.

You can run a Slackware node in LXC or as it appears to be referenced in the vernacular "Slack Pimpin'".

If you prefer kernel virtualization over containerization, you can use KVM.

I have a setup like this but I use NetBSD Xen. Install NetBSD first, then Xen. Use LVM. Keep space on your disk for Slackware, which you install on bare metal, as you would if you were dual-booting. Then boot into NetBSD and configure Xen to boot this Slackware as a domU. I couldn't be happier with this but I'm afraid there were hoops to jump through. The NetBSD dom0 will chug away happily with just 256M. I have most of it documented but unfortunately not all. If you want to take this path I should be able to help but you would need to be comfortable with NetBSD because I take a lot for granted in my notes.

I got up and running with a Xen system in a fraction of the time I took with XenServer by using Alpine.

I had to zero the MBR on /dev/sda after installing Slackware because Alpine didn't seem to like what was left behind, and just quit with an error when trying to format the hard disk. A quick "dd if=/dev/zero of=/dev/sda bs=512 count=1" command later it seemed to work OK.

This page details what to do but is out of date. The installation of the Xen package seems to set you up for dual-boot already, so seemingly no need editing extlinux.cfg except:

I then booted into 'xen + Alpine' and promptly got a corrupted screen making the console unusable, then had to work out how to disable the mode switch. I think it was either video=vesafb:off or i915.modeset=0 which did it for me although I tried all the usual ones like nofb and vga=normal as well. It's not too obvious but I think you put the xen options before the first ---, and the kernel ones after, e.g.:

APPEND /boot/xen.gz --- /boot/grsec root=UUID=<YOUR-DISK-UUID> modules=ext4 --- /boot/grsec.gz

I've no idea what the second --- means though.

I was a bit stuck on understanding bridges. However I followed their example for Xen Dom0 and it works in the sense that I still have net access afterwards. Don't understand why lo was not mentioned in their example config though.

Gerard, will you be able to give me some hints on getting Slackware 14.2 running on this system, assuming there are some similarities with yours? I'm a little unsure if it will work given most other distros go on about setting up LVM, but there didn't appear to be any of that with Alpine.

Thanks!

Biff.

Looks like you are running, but Proxmox (AGPL) has low requirements for testing purposes. Might suffice if your needs do not demand a lot of RAM. Caveat: Proxmox is not designed for fake or software RAID, so use the single drive as is. Once created the VM can be accessed with SSH. The Proxmox web interface supports a virtual console interface to access the virtual system directly.

I think the reason I used LVM was to make it easier to boot into Slackware as a domU and, alternatively, on bare metal. I did reserve a non-LVM part of the disk for /boot. I installed NetBSD first, leaving most of the disk free for Slackware. I installed Slackware as normal, with lilo installed to root, not the MBR; perhaps it's not really necessary to use LVM but I remember it made life a lot easier, but that was possibly because NetBSD and Slackware both had LVM. (It's over 6 years since I did this and I really wish I documented every step of the way.)

When I say I installed Slackware as normal I mean I installed it as a second OS on the disk, after NetBSD. Not as a Xen domU, in other words. Once you install Slackware this way it's easy to boot into the system and make the changes needed in order to boot it later as a domU.

If you want to do what I did - boot Slackware natively and virtually - then you should probably compile a second kernel with the paravirtualization options needed for running under Xen. Copy the domU kernel and initrd to /boot on your dom0; make sure you give them a unique name so they don't overwrite the dom0 kernel and initrd. Keep the other kernel around so you can boot natively. Important as well that fstab in Slackware references UUIDs, not dev paths.

Hope this helps. Keep asking if not, but I found every single Linux Xen dom0 offering a nightmare, the slackbuild included. Having said that, I never tried Alpine, and I have heard it makes a good dom0 host. NetBSD, as ever, is just a pleasure to work with, after you run into one problem on top of another with Linux.

Proxmox does not itself have a facility for creating software RAID but you can drop to a shell before running the installer and create it manually or else use something like gparted beforehand. You should then be able to install Proxmox on the RAID array. At least that's what I was told about 8 or 9 years ago!

I think I am possibly missing some key Xen concepts. Let me just check some facts:

I understand a Xen-aware kernel can't be made to boot on real hardware, is that true?

I thought Xen had two modes of virtualisation, something they call PV and non-PV, so why not boot your Slackware into the non-PV (fully virtualised) so you can boot a 'normal' kernel that way, and prepare your PV one? (sorry if my terminology is wrong here).

How do I get my Slackware install files into my emulated container disk or is there no equivalent to, say, VirtualBox .VDI files? Is that why LVM is used to create similar?
Edit: I think this at least I figured out from this link

Can I even 'snapshot' Xen virtual machines at all?

I assume there is this work to do (kernel preparation) because Slackware doesn't provide a Xen-aware kernel to boot from, it would seem to be not too hard to prepare a new install ISO with Xen domU kernel added as an extra boot choice, are there any instructions on how to do that?

Absolutely helps to have someone to talk to about this, very much appreciate it.

Biff.

Not quite. Slackware will still boot on bare metal when you compile Xen options into the kernel. The beauty is that it will boot as a domU as well. All you're doing is adding Xen options to the kernel; if you don't remove any other options then a Xen Slackware will boot on real hardware just the same as a non-Xen Slackware.

Yes, Xen has paravirtualized mode, HVM mode, and a newer mode I'm not too familiar with, which seems to be a mix of the two. For Linux and BSD domUs you want paravirtualized mode. Much faster, in my experience. As fast as, if not faster than, a native install. You could create a HVM domU, and sort out your PV kernel from there, but my thinking was that it would be nice to have the option of booting Slackware on bare metal as well as under Xen, so I never did it your way, but there's nothing to stop you.

Well, there's your way of doing it, which is exactly like Virtualbox. Create a virtual hard disk, install Slackware on it, and then, if you want, compile the Xen options into the Slackware kernel so you can later boot this domU as a paravirtualized guest. I wanted my domU disk to be as close to bare metal as possible, which LVM gave me. And I wanted the option to boot Slackware natively, which LVM gave me. But there's nothing stopping you from emulating the disk, other than the slight overhead it might impose. With LVM you have a few more hurdles to cross, but for that price you get flexibility and better disk performance.

Well I never got around to that, so I'm no help there I'm afraid.

No, that's something else I never got around to. But, as with most things Slackware-related, it's really easy getting a Slackware domU working. And rewarding. Just don't try to get it running as a dom0 on recent hardware.

1 members found this post helpful.

you can use qemu as well. that can use kernel kvm and is reasonably quick. I am running 2 vms on a real slackware install, headless, with vnc, and the vms run kde ok, the only thing that is a little slow is network access.

After several evenings playing with Xen and XenServer I'm now a convert to Proxmox. I did get Xen working, dom0 and domU however I've yet to figure out how to get a VNC remote console display with it.

Proxmox was very easy to setup. The only thing that stumped me at first was that the NATed VM couldn't ping out. Maybe that's just how Qemu user networking always worked and I never noticed.

The other problem was the VNC display is a bit temperamental, and doesn't always update itself in Firefox when I first switch to it, I have to open a separate window with the console in, but it all works fine after that, for text mode or Xorg.

Next step is to get SPICE working in Slackware, and then I think I'm done.

Amazing that I've been using ESXi at work for almost a decade and never heard of Proxmox until the above post.

I'm using qemu + libvirt + virt-manager at work and home, and I'm quite happy with it.
Remote access to VMs via SPICE works flawlessly.
I also remote via RDP (windows VMs) or VNC over RDP (xRDP on linux VMs) when I'm not at my virt-manager workstation.

I made a small home lab a few months ago to learn Xen. I set up Slackware 14.1 as Dom0 using Xen 4.6.3 from Slackbuilds.

I ran into a few errors due to the patches. I remember not needing the symlinks_instead_of_hardlinks.diff patch, so I commented out the line that applied it.

The other patches were for earlier versions of Xen (4.6.1 and 4.5.), so I went and manually checked all of them to see if the source code still needed fixing in Xen 4.6.3, and modified the patch header to match the 4.6.3 instead of 4.6.1 and 4.5.0 which were available for the SBo script. After those small adjustments, the build went fine.

Looking over the SBo script for 14.2 (assuming this is the Slackware version you've tried), there are only two patches available, one of which is for the symlinks.

symlinks_instead_of_hardlinks.diff
use_already_present_ipxe.diff
Try modifying the patch headers to match the current release in Slackbuilds to 4.8.0; commenting out the line that changes the hardlinks to symlinks might also be safe. You can glance over the source code and see if it still tries to install hardlinks instead of symlinks.

2 members found this post helpful.

Unfortunately for me it's far from flawless. I get repaint issues in X when using either the noVNC or SPICE option connected to Proxmox. It's strange that they give the same problem.

I'm using:
spice-0.13.2-x86_64-1_SBo
spice-gtk-0.32-x86_64-1_SBo
spice-protocol-0.12.12-noarch-1_SBo
libvirt-2.1.0-x86_64-1_SBo
libvirt-glib-0.2.3-x86_64-2_SBo
gtk-vnc-0.5.4-x86_64-1_SBo
virt-viewer-0.6.0-x86_64-1_SBo

Do you need to connect to this laptop over the internet or the LAN? XDMCP might be the best option over the LAN.