Slackware & Qemu
Lately I've been trying to get working Slackware with special use case - creating VM. This purpose become not so easy to achieve, as Slackware has peculiar way of implementing modern solutions into system itself. First choice was to get Xen working, but after trial and error I've was able to compile, start and load Xen modules in proper kernel and create base of VM. Not bad, but eventually I came up short and haven't finished task as I wanted. Well...system does work, so does network, but I needed something actually running VM, so I switched to Qemu.
After finding some interesting articles about it, and tweaking after some excercise I was able to run VM. Here comes special thanks to VMS package author as it will take the most of heavy lifting for you, has nice config template and quite nice documentation. In manual it says you need several packages, so here road might become a bit bumpy, as some of them I've installed via slackpkg and some of them via slackbuilds.org (sbotools). Fun fact - I've tried it on 2 Linux hosts, both current and latest (October) was much easier to cooperate than the older one (June), so I needed mix both methods to get all necessary dependencies on board. After that, getting VMS from slackbuilds.org is a real breeze. Rock N Roll ! So I've prepared VM (according to docs in the VMS), installed entire Slackware inside VM without problems. It took some time, as I'm using 1 CPU with 512MB Ram (custom use case, as I need it for further development, multiplied by 10 so that will consume 10 CPU/Threads with >5GB Ram, and I need to run it on my server machine). I've started the VM, trimmed it a bit as I don't need now all the packages (rust, ruby, perl, php, mariadb have been removed) - result is 7.7GB used by system against ~10GB image size. That will need further trim to get below 5GB of system use. It might seem a bit much, but it has all tools I'm using on a daily basis, and we will see how it behave in cloud environment.
A bit of context here - The main reason of me getting into this venture, were problems with legacy systems on cloud VM's. These can become real pain when it comes to maintenance, especially system upgrade. Slackware never disappointed in that matter, even after several years with non updated system it still didn't show any problems. Actually I've tried to update from 14.1 (I've got one really old laptop) to current, and it went without any problems. Sure, it's good to remember to upgrade slackpkg first, before the rest of the steps but that's all documented now. Docs by the way are getting better and better.
Back to business. I was finally able to:
1. Configure VM - check
2. Run VM - check
3. Trim system inside VM - check.
Nice, I'm on a good road. 2 things left - how to run it in headless mode, then how to configure network so I can actually use it in headless mode. Running it without monitor was a bit of challenge, as most of internet posts are pointing into "non graphical options" and it has some use case, however not when you're not logged into X (graphical interface). So after getting several "gtk errors" I found a package to run VM in gtk-emulated state (search phrase: "how to run qemu vm without GTK ?"). Of course, slackbuilds.org do not disappoint in that matter as well - there is prepared package to get you going: ... and you just use it in prompt before vms command: ... . Isn't that great ? But one more thing left to do: networking. And that was a bit of hiccup, as I didn't want to bridge everything, so I decided to do some oldschool routing instead. That would eventually became a bit of pain, but somebody come to rescue us all - AlienBob. I found his script and modify one part only (regarding DNSMASQ). I've also used vde2 which starts tap interface with proper networking, but DNSMASQ is used to act as a DHCP server. So what actually was left to do ? Yes, you're right - ip_forwarding, but guess what - Slackware got that covered, so I've just started /etc/rc.d/rc.ip_forward and all is working as expected. I've got my VM on isolated network and my local devices has access to it. And that is just a prelude to another part.
To be continued...
