
Ask HN: Is anyone using a VM for the work environment? - Artlav
I&#x27;ve been contemplating using a portable virtual machine for the work environment, and wondered if i&#x27;m alone at it.<p>Right now it&#x27;s Qemu with Arch Linux in it. The VM is headless, and is only accessible over SSH and VNC provided by the system inside of it. It can also be run by Virtualbox.<p>It can run on Linux and on Windows. Physically it&#x27;s a 64Gb thumbdrive with several disk images and all the software needed to run it.<p>The benefit is that you can use it anywhere without having to alter someone else&#x27;s machine, both physically by plugging the thumbdrive in and running the VM, and virtually, by running the VM on a server somewhere and accessing it remotely over VNC.<p>Other advantages are that you don&#x27;t need to close or shut down anything for the night - just disconnect&#x2F;save state and come back later to exactly the same place.<p>I got a feeling that i didn&#x27;t came up with this first, so the question is - do anyone use something similar, and in which ways?
======
kashyapc
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](http://libguestfs.org/virt-
builder.1.html) [2] [https://developer.fedoraproject.org/tools/virt-
builder/about...](https://developer.fedoraproject.org/tools/virt-
builder/about.html)

------
cauterized
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.

------
jupiter90000
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).

------
dacompton
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.

------
dhruvkar
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)

------
Osmood
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.

------
throwawayzzzzxx
Qubes OS.

