Tiny Headless Linux VM in Windows

2013-11-09 tech development linux

One major drawback of doing web development on Windows is the difficulty of running software primarily developed for Linux, things like redis, node.js and git. With great virtualization software nowadays, it is very feasible to run Linux software inside of Windows without any performance penalty. In particular, running Linux headless, and accessing the VM only over the network, is a great resource-saver.

Here’s how to get a headless Linux virtual machine running under Windows in 10 minutes. My tiny Linux distribution of choice is SliTaz 4.0, whose installation ISO is a respectable 8 MB. It’s tiny and fast: installation to disk takes about 30 seconds, boot time is about 10 seconds (running on my five year old laptop). When I have the headless virtual machine running, I access the shell via SSH (with Putty) and edit files via SFTP (with WinSCP). [Why not use Vagrant?] [Why not use shared directories?]

In VirtualBox (I am using 4.2.10), create a new virtual machine. Give it as much RAM as you want. I give 512 MB which is probably more than enough, depending on what you want to do. For the hard drive, make a dynamically allocated VDI with a maximum size of 8 GB or so. Set the virtual machine to boot from the SliTaz 4.0 base ISO (8.08 MB) and start it.


After booting from the ISO, you should arrive at a splash screen. Choose “SliTaz Live” to run the operating system from the read-only media. Choose the language and keyboard settings, and then you will get thrown to a login prompt. Login as root; the password is root. Now we want to install the operating system onto our VirtualBox disk. We have to partition and format the disk image, which we accomplish like this:

# fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
Disk /dev/sda doesn't contain a valid partition table

# fdisk /dev/sda [note: same disk as reported above]
Command (m for help): n [note: create new partition]
Command action
   e   extended
   p   primary partition (1-4)
p [note: primary partition]
Partition number (1-4): 1
First cylinder (1-1044, default 1): [ENTER]
Last cylinder or +size or +sizeM or +sizeK (1-1044, default 1044): [ENTER]
Command (m for help): w [note: write and exit]

Now fdisk -l should show /dev/sda having a partition table. Take note of the partition name, which will probably be /dev/sda1.

Run tazinst new setup.conf which will create the installation configuration file setup.conf. Edit it with vi setup.conf. You will want to change the following:

  • TGT_PARTITION="/dev/sda1" or whatever partition fdisk -l told you.
  • TGT_GRUB="yes" otherwise you will not be able to boot from the hard drive.

If you’ve never used vi: press i to start editing the text of the file. When you’ve finished editing the file, press ESC and type :x, then press ENTER.

Now proceed with the installation: tazinst install setup.conf. This should take less than a minute and then it will bring you back to a prompt. reboot. You can log in as tux; the password is blank.


At this point, the operating system is installed and bootable on the virtual hard drive, but some things have to be changed before it’s truly usable. The 8 second GRUB countdown is one of those things (especially for running the VM headless). Run su (remember the root password is root). Then vi /boot/grub/menu.lst and set the timeout to 0.

While you are still root, tazpkg get-install sudo (tazpkg is the SliTaz package manager). Once that finishes, visudo and insert the following line at the end of the file: tux ALL=(ALL) NOPASSWD: ALL. This will let you execute sudo from the tux user without being prompted for a password, if you’re into that sort of thing. Now we can exit and proceed as tux using sudo.

We want the SSH daemon (SliTaz uses dropbear) to run at system boot. Run sudo vi /etc/rcS.conf and modify the value of RUN_DAEMONS to contain dropbear. Mine reads firewall dropbear; there are probably other daemons listed which you should feel free to delete. In addition to running the SSH daemon, you should also sudo tazpkg get-install sftp-server, which will enable SFTP over SSH.

Here are some additional changes that I make which are up to personal preference:

  • sudo tazpkg get-install bash and then edit the tux line in /etc/passwd to use /bin/bash.
  • sudo tazpkg get-install openssh (to replace the dropbear SSH client, which is a headache if you are using git).
  • sudo tazpkg get-install vim-tiny (to replace vi).
  • To have the shell respect HOME and END keys, add the following to ~/.profile: bind '"\e[1~": beginning-of-line' and bind '"\e[4~": end-of-line'.
  • Again in ~/.profile, remove the alias rm and alias mv lines.

After you’ve made all of the changes you want to make, poweroff.


To run the virtual machine in headless mode, go into the VirtualBox GUI and SHIFT+DOUBLECLICK the virtual machine you just made. Edit the settings for the virtual machine (it’s okay if it’s already running at this point), go to “Network”, “Advanced”, click on “Port Forwarding”. Add a rule where the “Guest Port” is 22 and the “Host Port” is whatever you want (say, 2222). Note that the default network type (NAT) is perfectly sufficient for what we’re doing.

Open Putty and connect to localhost on port 2222 (or whatever port you chose). Open WinSCP and do the same. Enjoy.

Once you have this base VM set up, you can duplicate it and spin off tiny virtual machines dedicated to different projects. I recommend doing full clones, avoiding VirtualBox’s “linked clone” feature which, in my experience, is prone to disk corruption.

Appendix: Why not use Vagrant?

Vagrant can be a useful tool, but I have two reasons for avoiding it in this case.

First, this is a very quick bootstrap process which can be instructive for somebody new or a refresher for somebody with more experience. Once the setup has been done once, duplicates can be made within VirtualBox, so it’s not a problem to spin up several copies for different purposes.

Second, the Windows port of Vagrant is not great. In order to SSH to the Vagrant VM, you have to use either cygwin or jump through hoops to use Putty. Also, the installation takes up over 200 megabytes, which can’t be justified for this use case.

Appendix: Why use SFTP rather than shared directories?

Shared directories are extremely slow (especially if you try to use something like git from inside the guest system). They also require the VirtualBox guest additions to be installed, which is a waste of effort and disk space in this particular case. WinSCP monitors file modifications so that any changes made in your text editor (on the host system) are more or less instantly relayed to the virtual machine.

comments powered by Disqus