Virtualbox and licensing


(Jason Scott) #1

Caveat: I haven’t had chance to install and play yet.

When providing Windows apps via Virtualbox, surely this requires an OS license? More importantly, this underlying OS needs to be patched and managed like any other OS, so are you not doubling the overheads?


(Kenny Kennington) #2

Jason, Yes the underlying OS will need a license, but if using Win7, the EWA allocation can be used to cover this. As the Virtual instance is only being surfaced from within Linux, the virtualised windows version is protected by the “Linux” security blanket. General updates to the VM can be managed by “Patch Once” deploy everywhere. It is a different concept to how we managed devices now, but infinitely more secure as you are not exposing the Virtual core. Hope this makes sense…


(Jason Scott) #3

Somewhat. So the Windows virtualbox image would be managed centrally and redeployed to all NHSbuntu devices after each update? If so, is it possible that delta changes can be deployed and used?

I’m a little hazy on the Linux security blanket though. Surely you’re exposing the Windows OS + app through a bridged network interface? Is the level of abstraction enough to prevent things like WannaCryptor from reaching the virtualised instance?

I’m downloading today to install and experiment.


(Rob Dyke) #4

Hi Jason,

We use tooling from Hashicorp to help ease Windows virtualisation pain…

  • Packer - automagically building Windows images
  • Vagrant - distributing Windows images

Our packer definitions are extended from boxcutter - here’s our fork of the repo.

In NHSbuntu/nhsbuntu-boxes you’ll find

  • a helpful installer script for packer/vagrant/virtualbox - install.sh
  • Vagrantfile for Win7 ENterprise with SP1 (32bit and 64bit)
  • Provisioning scripts using chocolatey to deploy JRE, Gemalto, HSCIC IA

Hope this helps you get started.

/rob


(Rob Dyke) #5

Not quite double, but I do accept your point.

Virtualising Windows with the Hashicorp tooling helps significantly here.
We can:

  • fully test patches before deployment
  • ensure that VMs are not tampered with by validating checksums
  • provision new applications silently and on demand using scripts
  • enforce VMs are updated on startup using version control

These four features alone are significantly more efficient than
conventional build and deploy techniques.

Rob


(Jason Scott) #6

Thanks Rob.

Patching and sending out a new, fresh image is a lot quicker than trying to patch or rebuild multiple machines, so you’ve got a benefit. It’s just like our Citrix environment with the one gold master image that 56 servers rebuild from nightly.