SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
You are really making it look more complex than it actually is.
Slackware is a good "hypervisor". If you load the kvm modules of the kernel then it can host multiple VMs with near-native performance. On your Slackware host you can still work as usual.
My QEMU VMs have multiple 'virtual' disks (just image files created with 'dd') and I use one of them for every VM as the swap. Sharing files can be done in many ways, as explained above: setup a Samba or NFS server on the host and let the guests read and write there. Or use QEMU's own 'firts' virtual filsystem driver which exposes part of the host filesystem into the guest and which you can then mount with the filesystem type "9p". If the host needs access to the guest's files you just setup Samba or NFS servers in the guests.
if you want to take the easy route, and you are on slackware current, you only have to install 3 packages from slackbuilds from ponce github, nl. acpica, virtualbox-kernel and virtualbox. if you have multilib enabled, you can compile vitualbox with pass SOFTWARE_VIRTUALIZATION=yes to the script. however If you are on slackware 14.2 stable, you probably better go for the installer from virtualbox website, otherwise you will end up with an older version of virtualbox
If you want bridged networking for virtualbox, you only have to edit "/etc/rc.d/rc.inet1.conf"
snippet of my relevant /etc/rc.d/rc.inet1.conf : EDIT: i forgot, but I don't use the network manager, so this is if you do setup network manually with a static ip.
Code:
# =============================================================================
# IPv4 config options for eth0:
IPADDRS[0]=""
USE_DHCP[0]=""
# IPv6 config options for eth0:
IP6ADDRS[0]=""
USE_SLAAC[0]=""
USE_DHCP6[0]=""
# Generic options for eth0:
DHCP_HOSTNAME[0]=""
# Config information for bridged networking
IFNAME[0]="br0"
BRNICS[0]="eth0"
IPADDR[0]="192.168.0.107/24"
USE_DHCP[0]=""
DHCP_HOSTNAME[0]=""
were br0 is now the bridged adapter, were I used the ip settings from my eth0, and left eth0 empty. If you setup a virtual machine in virtualbox, you have to select "br0" as network adapter to enable bridged networking for your vm.
It's not like you do unrecoverable damage to your slackware installation by installing these 3 packages, since you can always remove them if you want to go for kvm/qemu.
If you try it yourself, it will probably answer many questions you have.
I know how to run VM's. What I don't know is packages I really have to install - say I don't need KDE for Slackware host. I don't need Xfce and so on. And probably I don't 50% of libraries from /l. I don't need emacs - most of developments - say only to build custom kernel - read my first post. I just need stripped down Slackware. Probably I don't need even window manager - it would be nice if hypervisor would connect directly with X server. So one needs kind of rc.vbox script which connect to X server and rise up VM guest. As a part of system init.
Well, imo gpu pass-through is a bitch to setup. Perhaps someone else can help you to get that working. I probably read it all wrong. anyway, good luck.
I run slackware as a host and as a VM with qemu+libvirt with no problems on either side.
Using virtio gives slackware VMs near native performance.
If you want a GUI to setup and manage the VMs, you are better off with a full install + virt-manager.
If you want a "just enough slackware" to run the hypervisor, good luck with that as it is A LOT of work since there is no list of dependencies for slackware.
I can manage host within VM say ssh to host - maybe there is something more sophisticated - so no need for gui to manage VM' or any other services on host. Essentially ssh to host is like ssh to any other remote system - so I can run xapps on host connecting via ssh to xorg on vm's - kind of remote desktop. I don't think list of packages is a very big problem - say I can use Alpine as Gerard_Lally suggested, or Devuan - to find necessary packages. For me at this moment is that I have to wait for 15.0 stable. I plan to set it with custom 5.4 kernel on host - stripped down - while on VM' vanilla 15.0 Slackware - untouched. This way I will separate 5.10 from hardware. I mean host will have both 5.4 and 5.10 - 5.10 will go along Slackware upstream, but 5.4 will be default - I will provide updates myself. My feelings tell me it is good kernel. Perhaps in time I will switch to 5.10. Or 5.15 which will be probably next stable. But basically I don't touch anything without stable Slackware. Say per month updates for -current last time I did I downloaded 4 GB. Still little too hot as for me. If I succeed I share how it looks like.
Just this morning I installed VBox 6.1.18 (the *.run blob from Oracle) and the extension pack onto a *very* stripped down version of Slackware64-current. By *very* stripped down I mean that there are only 96 packages installed. It has networking (ssh, slackpkg, communicating with the outside world), can build kernels and runs the GIMPS software (mprime). I installed a VM (CLI only for installation) that seems to function correctly. Since there is no Python on the machine, there was an error during VBox installation about a missing Python directory but it doesn't seem to have affected the completion of the installation nor the running of VBox. If you don't want to build your own kernels, you could probably strip 8-10 packages from the list of 96.
I guess my point is that a very minimal Slackware64-current can serve as a VirtualBox host as long as you don't need things like X or GUI tools.
By *very* stripped down I mean that there are only 96 packages installed. It has networking (ssh, slackpkg, communicating with the outside world), can build kernels and runs the GIMPS software (mprime).
96 packages is kind of record. I mean time to time someone is asking for minimal Slackware installation. I can see that. Go top bottom to look for dependencies. Or you just have experience. No matter thanks. Not only me but probably others didn't expect one day is enough to provide basic setup. Again great thanks. By the way what's the largest prime today? I mean number of digits is enough.
No. But this led me to this solution. Trying something new and perhaps it is kind of future - Android on Linux is something similar. Split system along to provide hardware separation. Hypervisor creates devices and drivers for guest kernel from very beginning are created to work with these virtual devices. Hypervisor offers the same interface for every guest system. Say on guest system I don't need most modules - so even kernel can be stripped down. But I'm not planning this - at least not at this moment. But one think like that. So no OEM systems but rather OEM hypervisor. But this would require Microsoft Ok - which can be a problem.
Distribution: VM Host: Slackware-current, VM Guests: Artix, Venom, antiX, Gentoo, FreeBSD, OpenBSD, OpenIndiana
Posts: 1,011
Rep:
Quote:
Originally Posted by igadoter
No. But this led me to this solution. Trying something new and perhaps it is kind of future - Android on Linux is something similar. Split system along to provide hardware separation. Hypervisor creates devices and drivers for guest kernel from very beginning are created to work with these virtual devices. Hypervisor offers the same interface for every guest system. Say on guest system I don't need most modules - so even kernel can be stripped down. But I'm not planning this - at least not at this moment. But one think like that. So no OEM systems but rather OEM hypervisor. But this would require Microsoft Ok - which can be a problem.
None of this is a problem.
I have Slackware64-current running as VirtualBox Host
clients:
Slackware-14.2 up to date with custom kernel 5.11.6
Slackware-14.2 clean post DVD, not updated (gcc 5.3) with custom kernel 5.11.6
Slackware64-current setup mirroring host for safe udates (test before host upgrade)
Slackware64-current hardened with 5.4.105 hardened kernel (no modules) no initrd (if this is important for you).
antiX with 5.11.6-libre kernel
Gentoo-hardened
FreeBSD 12.2 p4 (custom kernel)
OpenBSD 6.8 (no VBox support) and custom kernel
OpenIndiana
Windows 8.1 (for photo editing professional software wunning windows only)
nethserver - for internal network with NFS (so all clients can share data with OpenBSD), internal mail and configured thunderbird for internal mail, Samba (alternative to NFS), Wiki, and more
Virtualbox clients can also use VBox shared folders, some are installed on EFI some not. Hardware offered by VirtualBox for clients is independent of what your barebone box has and it it pretty conservative so you can easily install any OS you want including OSes that do not support VirtualBox (e.g. OpenBSD running in full screen resolution).
Best currently type 1 hypervisor is Qubes OS, so if you need to play around with software that requires complete client isolation, this may be your choice.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.