Ask HN: Is anyone using a VM for the work environment?

Yup. Issues with docker on osx caused me to move to a debian VM 6 or 7 months ago (that I ssh into from iterm). The main reason I still use it is because it would take several hours to transition back to osx.

For me, the scenarios mentioned are too improbable to justify that amount of tinkering. If you need what that gives you (portability etc), it would not be a terrible way to go about it. You could also look into amazon workspaces or vagrant.

2 VMs, one for admin tasks, one for dev tasks, both are VMPlayer format. Hosted on my plain old Winx64 PC at the moment, can be moved to headless host if needs be.

The idea of having it physically portable on a thumb drive is neat, never thought of that. I just use a vagrant script with a base box that has puppet so I can recreate a VM configured exactly how I want by issuing a single command (vagrant and puppet scripts are on a git server so could be pulled on other machines). I would lose state obviously on a new machine though. I guess one could use a cloud file service to store the VM and state(s) to avoid losing the state via a single point of failure (local physical media of some sort).

Others have spoken about Vagrant & Puppet. Here's another option.

One tool that I love (and happily recommend) in my daily workflow of Linux Virt/Infra development is `virt-builder`[1], it is part of the libguestfs project. Once the compressed image (250MB or so) is cached, it can spin up fresh template VMs (`virt-builder --list` to check the distribution list) just under 40 seconds.

In my workflow (also with headless VMs), I have two qcow2 disk images (& several others on disk) on my devel laptop. They're built / used this way:

Build a minimal disk image:

    $ virt-builder fedora-24 -o f24.qcow2 --format qcow2 --size 60G \
        --root-password password:secure-pwd

Then, import it into libvirt (NB: despite the tool's name 'virt-install', it is not installing anything here, but merely importing the disk image):

    $ sudo virt-install --name dev-vm1 --ram 4096 --os-variant fedora-24 \
        --disk path=./f24.qcow2,format=qcow2 --nographics --import

(The above will be QEMU, if you have hardware virt extensions, it will be a KVM guest).

You could then manipulate it with `virsh`, libvirt (Virt API through which you could manage KVM/QEMU/Xen) shell, to manage snapshots, & other guest life cycle activities.

FWIW, I wrote a bit more verbiage (which also adds a quick note about snapshot management, so you could revert to a known sane state, if something goes haywire) here[2].

You can do far more interesting things with 'virt-builder', by supplying it to install packages you need, trivially creating secure new 'clones', etc.

[1] http://libguestfs.org/virt-builder.1.html [2] https://developer.fedoraproject.org/tools/virt-builder/about...

Qubes OS.

Using Vagrant and Ansible to spin up VMs. It's dead simple, pretty much just one command after copying a vagrantfile and playbook into working directory. Downside is that it takes a while to provision (updates, install commonly used programs and set up dev environment) a vm the first time (~10 minutes)

Not right now, but I did at a previous gig. Virtualbox on a Mac. It worked ok, but was a PITA to get networking configured properly; and anything filesystem related was painfully slow b/c we needed sharing.

We were in early stages of development for a brand new project, so it wasn't all THAT portable in the sense that installed dependencies changed enough and frequently enough that you would need to take a new snapshot if you intended to use it elsewhere. Or more likely, install an old snapshot, pull the latest codebase, and spend half a day puzzling out why it wasn't working and getting it running again.

It might work better for a project in a more stable stage of development.