I want to try new OS releases as they arrive, such as Ubuntu 17.04 or Ubuntu 17.10 to see new features. I also like to look at Kubuntu, CentOS or other distros (Windows 11 when it arrives?) - or set up test environments knowing I may trash them and do not want to do this to my core machine.

What set of alternatives are there to do this without risking my main development machine? I am not looking for a debate on the BEST way, but which alternatives are available.

  • 2
    I mostly do that with virtual machines. See this question for a guide to the incredibly fast and easy setup using VirtualBox that you may want to link to in your answer.
    – Takkat
    Commented Mar 7, 2018 at 14:58
  • 1
    Personally, I use docker because your container is defined with an easy-to-understand script. You have complete control over the base image and what you install. Easy to share host files and devices, create virtual networks of containers, selectively expose ports with command line arguments, you can send commands directly to the container shell and execute applications within the container context. For example you can try centos userspace with a one-liner docker run -it centos /bin/bash
    – crasic
    Commented Mar 7, 2018 at 18:04
  • 8
    "Live CDs" used to be a big thing. Nowadays it would be a live USB drive. Commented Mar 7, 2018 at 22:13
  • 1
    Given the update model of Windows 10, it's unlikely that there will ever be a "Windows 11". Even if there's a major rebuild of the OS, Microsoft will most likely call it something else.
    – OrangeDog
    Commented Mar 9, 2018 at 12:18
  • 3
    You basically have three options: a virtual machine (VirtualBox or Docker), a bootable flash drive (modern alternative to a live CD), or dual boot. Choosing between the three depends on your needs, hardware, and experience. Commented Mar 9, 2018 at 14:41

9 Answers 9


USB alternatives

USB alternatives are good, when

  • you want to test the performance (on bare metal)
  • the computer is not powerful enough to run a system well in a virtual machine

You can use a USB pendrive with at least 2GB drive space and create a

  • live Ubuntu system in the pendrive.

    Boot from the USB pendrive and select 'Try Ubuntu' in the boot menu (and something similar with other linux distros). If you save data, install programs or tweak the system in a live (live-only) drive, it will not survive shutdown or reboot.

If you want to

  • try Ubuntu in a more advanced way or
  • save data, install programs or tweak the system and
  • you have/get a fast USB pendrive of at least 4 GB,

you can create a

  • persistent live Ubuntu system

or if you have/get a fast USB pendrive of at least 16 GB, you can create an

  • installed Ubuntu system (like installed in an internal drive, but in a USB pendrive).

    An installed system in a USB drive is stable and flexible, can be kept up to date and tweaked without any limits. In this way it is better than a persistent live system. It is portable between computers, if you can avoid proprietary drivers, but a persistent live system is more portable.


  • 2
    Since the poster has a running Ubuntu(?) installation, booting the ISO directly off the hard disk is a possibility too. Set up links to the (new) ISO, use the link in grub (add to your /etc/grub.d/40_custom), and have a FAT partition with directories for the casper-rw files (PERSISTENCE_PATH to identify which one to use). Add "toram" and the ISO boot performance is equivalent (or even faster) than a normal hard disk install.
    – ubfan1
    Commented Mar 7, 2018 at 16:33
  • 2
    Yes, @ubfan1's alternative is good, I have used it several times. Maybe it is slightly more complicated to set up than to create a USB pendrive, but once you have it, it can work well :-) See this link, help.ubuntu.com/community/Grub2/…
    – sudodus
    Commented Mar 7, 2018 at 16:47
  • 2
    Installation on separate storage device is the best way when you want to test how really the new OS release behaves with your hardware.
    – pa4080
    Commented Mar 7, 2018 at 21:38
  • This is absolutely the right answer. Trying to test an OS through layers of virtualization (or Docker, God forbid) on your current OS is like taking a new car for a "test drive" by towing it on a trailer behind your current car: sure, you kinda get to see what it looks like, but it just won't give you any idea of the performance.
    – A C
    Commented Mar 8, 2018 at 13:14
  • With USB3, this will probably work ok. If you have an older machine with USB2, it'll probably take noticeably longer to load. Commented Mar 9, 2018 at 14:36

One way to test new distros and OS versions is with virtualization. It does not require space for an additional PC/keyboard/video/mouse or adapters to run multiple PCs with a single keyboard, video, mouse. It only requires a single PC and some virtualization software.

This assumes that you have a machine with a multi-core CPU capable of virtualization and a reasonable amount of memory. I would recommend at least 8GB of memory with 16GB better if you have it.

If you are running Ubuntu and only want to try Linux distros (I do not believe Windows will work), you can use the free virtualization software packaged in Ubuntu: KVM or Xen. Both work fine, are FREE, and can run various Linux distros. However, the tools to manage the VMs are somewhat lacking. Oracle has a FREE version of a virtualization tool called VirtualBox and of course there is always the commercial VMWare product. Both VirtualBox and VMWare can also run Ubuntu on top of a Windows machine if that is your desktop of choice.

By using a VM manager, you will be able to add new distros as they come out, test them, play with the new features, and then discard them when the new release appears. They only eat up disk space when not running, so they do not even need to be discarded unless that becomes tight. With a VM manager, it is easy to balance 5, 10 or more distros on a machine and be able to boot them up and take them down as needed. If you are lucky enough to have a 32GB or 64GB machine, you can even run them all in parallel.

  • 2
    Windows can be run inside a VM; however, the newer versions are so heavy that you would need a pretty fast multicore for it to be usable.
    – ravery
    Commented Mar 7, 2018 at 12:58
  • A virtual environment also depends on support for that OS. New Windows releases will need alterations to the virtual machine software to support it so that might be a slight setback. Though I would expect them to prepare for new releases ;-)
    – Rinzwind
    Commented Mar 7, 2018 at 13:15
  • yeah - for testing we definitely need to upgrade the virtualization solution to the very latest release in order to be able to boot recent OS releases.
    – Takkat
    Commented Mar 7, 2018 at 15:01
  • 2
    KVM runs Windows 10 and 7 just fine. If by Xen you are referring to Citrics Xen Server, that also runs windows 10 & 7 as well.
    – Robby1212
    Commented Mar 7, 2018 at 21:39
  • 1
    @EricDuminil They were about as usable as Windows generally is. :) Commented Mar 8, 2018 at 17:33

As an even faster and cheaper alternative to sudodus’ answer you can boot directly from a bootable drive image file instead of a dedicated (USB) drive.

At least for Ubuntu ISO images (and derivatives like Linux Mint) the following recipe works. Other distributions may need further tweaking.

  1. Store the bootable drive image(s) in ISO format1 somewhere as a file on your internal storage drive(s)2.

  2. Add a Grub “parts” file, e. g. 35_isofiles, with the content

    set -e
    . /usr/share/grub/grub-mkconfig_lib
    shopt -s nullglob
        local isodevice="$(exec "$grub_probe" -t device -- "$1")" || return $?
        local isogrub="$(make_system_path_relative_to_its_root "$1")"
        local label="${2:-"$1"}"
        printf 'menuentry %s {\n' "'${label//\'/\'\\\'\'}'"
        printf '\tset isofile=%s\n' "'${isogrub//\'/\'\\\'\'}'"
        prepare_grub_to_access_device "$isodevice" | sed -e 's/^/\t/'
        printf '\t%s\n' \
            'insmod loopback' 'insmod iso9660' 'loopback loop "$isofile"' \
            'linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename="$isofile" ro noprompt noeject noplymouth' \
            'initrd (loop)/casper/initrd.lz'
        printf '}\n\n'
        printf 'Found "%s" image: %s\n' "$label" "$1" >&2
    for iso in /path/to/image.iso # <-- set path to your ISO image here
        make_iso_menuentry "$iso" "${iso##*/}" || true

    to /etc/grub.d and make it executable.

    Edit the file path in the indicated line to match your needs. You can add multiple paths and/or Bash glob patterns if you want.

  3. Make the file executable:

    sudo chmod a+x /etc/grub.d/35_isofiles
  4. Make sure that the Grub menu is enabled.

  5. Update the Grub configuration:

    sudo update-grub
  6. Reboot and select the newly added Grub menu entry to boot from the respective image file.

1 Other file system types are possible but may require other Grub commands and boot parameter tweaking.

2 LVM, RAID and encrypted file systems should work thanks to Grub’s utility library but I didn’t test them.

  • 2
    wow ! what a script ! I made the same thing manually by simply adding an entry in /etc/grub.d/40_custom and finding the good parameters; Not that hard given the help I had with wiki.archlinux.org/index.php/…
    – solsTiCe
    Commented Mar 8, 2018 at 14:15

Virtualization is by far the simplest.

However you have 2 seperate use cases here, which will have different solutions

1. Try out new distro's

Distributions are basically determined by the packaged applications, and userspace environment (e.g. SystemD vs init for boot)

If you want to "evaluate" the UIX of a different distribution, qualitatively, then I would recommend full-blown virtualization where you install the OS in its entirety and evaluate its usability. This is covered adequately in other answers.

If you simply need the userspace environment for testing then read on.

2. Testing and "throw-away instances" in different environments

It is easier, cheaper, and faster to use containerization, a form of light weight virtualization that uses the kernel to create sandboxed environments.

A container shares kernel resources with the Host, but otherwise has its own root file system, userspace, network stack, etc. It can be thought of, conceptually as a chroot on steroids. However, because the kernel is shared the virtualization is "thin", meaning that for most practical purposes it runs at the same speed as the host OS.

There is commonly used container system called docker. Docker has standardized images for practically every linux distribution you would like, and it runs on windows (however, windows images only work on windows, linux images work on both) . It has additional useful features to save space and performance.

There are also native open source alternatives for linux like LXC (which is built into the kernel!) , which can be used to much the same thing (but with more configuration required).

Simplified Example of a testing or build environment in docker

# Dockerfile

FROM ubuntu:17.10

RUN apt-get update && apt-get install -y build-essential

WORKDIR /workdir
  • docker build --tag my-builder .

Then from the command line, compile your project or tests in that environment in a variety of ways

"login" and compile within the environment, run tests etc. Assuming you are in source directory of your project

$ docker run -v "$PWD:/workdir" --rm -it my-builder /bin/bash
# echo "Now in docker container"
# make
# build/test/my-test
# exit
$ echo "Build artifacts are now on your host OS Directory :) "

Use as one-off

$ docker run -v "$PWD:/workdir" --rm my-builder make

You can even pass environment variables

$ docker run -e "CROSS_COMPILE=arm-linux-gnueabi" -v "$PWD:/workdir" --rm my-builder make

Or start a persistent instance and copy files into it explicitly

$ Start our instance in background 
$ docker run --name my-builder-inst -d my-builder
$ echo "Copy files to instance" 
$ docker cp /my/source/dir my-builder-inst:/workdir
$ echo "run project build"
$ docker exec my-builder-inst make
$ echo "copy build artifacts"
$ docker cp my-builder-inst:/workdir/build /my/output/dir
$ echo "destroy and delete container" 
$ docker rm -f  my-builder-inst

There are literally hundreds of other use patterns, however, the script-like image definition, extendable images, and command line use makes it extremely attractive for development, test, and even deployment environments

  • 1
    If you want system containers you should probably be looking at LXD (much simpler than traditional LXC userspace tools) rather than Docker (which is designed more for application containers). That said, both build on top of kernel LXC/cgroups support. See also, unix.stackexchange.com/questions/254956/…
    – Bob
    Commented Mar 9, 2018 at 2:24

I keep a separate partition on my drive (recommend 20GB minimum, more if you can).

I can install onto that partition any OS I want to test, and then reboot into it.

If everything is working well, I can deprecate my original OS partition, and eventually repurpose it.

But if the new OS is not working out for me (driver issues, unavailable software) then I can simply reboot back into my old OS, and be thankful that I still have it!


  • This way you really get to test the new OS on your hardware, so you can detect driver issues.

  • But if you only wanted to experience how the new OS feels, one of the other virtualization solutions is probably faster, easier and safer for you.

  • I keep my /home on a large separate partition, so it is independent of the two OS-es. (Do not accidentally reformat that partition!)

  • But I recommend you do not use a shared /home partition while testing. If the two OS-es have significantly different software versions, an application might change its config files in a way that is unsuitable for the other OS. So keep separate config files for each OS, until you commit to one of them. (*) see below

  • You don't need to create a second swap partition. You can use the same swap partition for both OSes.

  • Of course you need to be careful which partitions you format / install onto. So do a backup, and write down your partition ids and sizes (parted, p, q), before installing a new OS.

  • In order to dual boot between the two OSes, you need grub to detect both of them. In my experience, grub has always done this automatically. (But lilo used to be a different story!)

  • It is often possible to run software from one OS while you are on the other OS. I managed that using sudo chroot /mnt/original_os, although it was a fiddle to set up: I had to bind-mount /dev and /proc.

My record was 4 Linux OSes on one machine, and a Windows XP. I used to boot into Gentoo for speed and fun, but run my webserver and mailserver in a chroot to the trusted Debian OS.

(*) You can configure a different home folder for each OS, by editing /etc/passwd. Set your home to /home/you/arch-test then target the shared home partition in /etc/fstab and reboot. You can symlink some dotfiles to be shared across both OSes, whilst leaving others to be OS-specific.

  • 1
    Need to really trust their install scripts.....
    – mckenzm
    Commented Mar 8, 2018 at 19:10
  • Yes, there is more risk associated with this method. If you are really a careful person, you might try virtualization first and then a partition install, and only abandon your original installation if that works. Commented Mar 9, 2018 at 2:48
  • I would never do this again. I once ran into an apparently obscure d-i bug which blew away every encrypted partition, even those that weren't part of the requested installation. AFAIK this bug has not been fixed. Commented Mar 10, 2018 at 23:00

You basically have three options: virtualization (VirtualBox or Docker), a bootable flash drive (modern alternative to a live CD), or dual boot from a partition. Choosing between the three depends on your needs, hardware, and experience. Some of the other answers go into a lot more detail about a particular approach, but here's a high-level comparison to give you a framework for deciding between them.

1. Virtualization


  • pretty easy to set up
  • won't affect your primary dev environment
  • you can easily set up as many as you want, as long as you have the hard drive space - even create snapshots before making major changes, and just delete them when you're done with them


  • requires decent hardware to run two or more OSes simultaneously
  • performance is limited by the resources allocated to the VM, so you really won't get an accurate idea of how the OS version you're testing compares to your primary OS
  • since the hardware is all virtualized, you won't get an accurate sense of driver availability/compatibility either

2. Bootable flash drive


  • moderately easy to set up
  • won't affect your primary dev environment
  • performance is generally good with a USB3 flash drive, although there's definitely some variation depending on the quality of flash drive (USB2 will be slower - I'd avoid it for this purpose)
  • uses your actual hardware (other than the storage device), so you can see how well it plays with drivers and whatnot
  • you can easily set up as many as you want, as long as you have enough flash drives (and you can easily reformat them if you want to try something else)


  • requires having one (or more) flash drives dedicated to this purpose
  • performance depends on the quality of flash drive you use

3. Dual boot from a partition


  • gives you the best idea of performance, driver compatibility, etc, since it's running on the exact same hardware as your primary OS
  • can set up multiple at once, as long as you have the hard drive space (you just have to set up a separate partition for each one)


  • requires some low-level know-how to set up properly
  • messing with hard drive partitions and bootloaders always has some potential to bork your current setup (make sure you have a bootable flash drive or live CD handy before you start)
  • If you split out the Docker alternative as separate from virtualization in your post, I would be willing to mark it as the answer that covers all of the alternatives. IMHO, I feel containers are not true virtualization due to not running true full init systems and full kernels. Containers (docker, LXC, etc.) are more lightweight on resources as compared to full virtualization (etc)...
    – Ted Cahall
    Commented Mar 11, 2018 at 11:10


QEMU is a virtualization solution that theoretically solves this question's requirements for cheap and simple.

It allows drag and drop booting of operating system iso files within a Linux or Windows host.

It also allows booting of Live USB hard drives, within a host system and uses the persistence if available.

There is no need to build a virtual hard disk as with VBox.

QEMU is available as a command line app for Linux, Windows and other OS. It is also available as a GUI and is included with MultiBootUSB Linux and Windows versions http://multibootusb.org/.


QEMU can also be run from Virtual Machine Manager, which is faster than MBUSB but is not drag and drop.

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
sudo apt-get install virt-manager

For longer term OS testing a VirtualBox installed system is superior.

  • Thank you! I had not heard of this option. I will take a look at it.
    – Ted Cahall
    Commented Mar 12, 2018 at 16:33

The simplest and easiest way is using virtualization. You can download VirtualBox (it is open source) and install any operating system. And, I recommend you to create a snapshot before run for first time, in this way you can fallback to its previous state if you make any mistake setting it up, changing configuration, etc.

I have use and test several OS in this way. It is very simple and quick. Even, I have used MSDOS and Windows 3.1 using virtualization. You can install anything, even ChromeOS (with a little of work) or any version of Windows or Linux, it doesn't matter its desktop flavor.


I've successfully booted full installs of Ubuntu from USB drives for the last 3 years. USB 2.0 was a little slower than an older 3G SATA HD (7200 rpm 16 MB cache), but USB 3.0 is within a couple seconds of a SSD on a 3G SATA interface.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .