Imagine, if you will, the following scenario: A hapless computer tech/geek/programmer has spent several weeks or months working furiously on his desktop computer. He flees out the door early one morning to hop on an airplane, and very carefully totes his precious laptop with him so he can continue to work on it. The total travel time is a laborious 30 hours, but no worry, he will get some work done on the laptop. While stuffed into a seat somewhat narrower than a conservative politicians mind at 30,000 feet, he opens his laptop, cracks his knuckles (generating some furious shushes and a stern glance from the lead flight attendant that he, of course, assumes is a flirty wink) and prepares to be productive. He’s got Dropbox, so he has all his latest files and code, so he is set!
But wait.
Over the weeks (or months) that he has focused his work on his desktop
he has applied numerous patches, tweaked his development t environment ,
installed utilities and, worst of all, he discovers that the version of SQL
Server/Visual Studio/Favorite App was upgraded on his workstation, but he
forgot to upgrade it on his laptop and now he can to little or even no
productive work! If he’s lucky, he has
his ISO files on a small HD with him and he can spend the next several hours
installing the latest software (if he remembered to sync his portable drive),
and trying to remember all the tweaks he applied over the past months, etc. If he is unlucky, he does not have his ISO’s
and other needed files and will have to wait until he gets somewhere with
decent Internet access to start getting his laptop into a fit state to be used.
So, while this never, ever happened to me
on a trip to Australia, I have adopted the habit of doing my development work
primarily on virtual machines. This has
several advantages. First, as virtual
machines are completely portable (even from Mac to PC via Fusion and
Workstation), my development machine on my laptop is always the same as my
development machine on my desktop – I simply use the same VM files on either
one. Another benefit is that when I
upgrade my physical computer (desktop, laptop or both), called the host, I don’t need to waste any time
installing all the apps, patches, services, etc. before I can get productive again. Nor do I need to try to remember all the
favorite tweaks I have accumulated over the past. I simply need to install VMWare Workstation
or Fusion onto a clean OS, and I can start running my development virtual
machine immediately. And the
snapshoting features of Workstation are very, very cool.
However, it starts to get to be a problem
when you VM(s) are getting to be 60 to 80GB and more (It’s not even that much
fun when they are just 40 GB). Why? The most common way you are likely to
transfer your VMs from machine to machine is over USB or LAN. It will start taking 10+ minutes over gigabit
Ethernet (or USB3), and 30+ minutes over USB to copy those files when file
sizes are over 60GB.
So how to get my large VM to run on
multiple different computers without always having to copy the files back and
forth? I decided to use linked clones. I created my base VM, took a snapshot called,
cleverly, “BASE” and set the VM as a template (Virtual Machine Settings à Options à Advanced). I further set the template directory to read
only. This base template VM, which by
itself (in my case) is about 40GB, will be copied to all the machines I am
likely to use, and will live on a USB3 thumb drive as well. Next, I created a linked clone to the
template VM, and coped those files as well to the USB3 drive. After a few boots, configuration tweaks, etc.
this VM is about 2GB on size. Once the
base VM exists on my various workstations, all I have to do is copy my linked
cone (I find it runs poorly from a USB3 Flash Drive) to whichever machine I
will be working on. By keeping the paths
to the parent (base) VM the same on all my machines, I won’t have any
trouble. If the path differs, I will be
prompted to point the VM to a parent VM, which is quick and painless.
