Imaging PCs: Difference between revisions

From All Hands Active Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 99: Line 99:

===Proposed solution===
=Proposed solution=
Please comment here with questions or comments.
Please comment here with questions or comments.

Revision as of 01:22, 2 December 2014

The process of imaging PCs has two projects in motion presently

Centralized files

Synology NAS has been purchased by Tyler W.

Configured but not installed.


  • LDAP Server is configured.
  • Give each member unique account with a fixed amount of storage.


2x 250gb drives

Configured in RAID

Supports external via ESATA or USB for backup.


Add to network at

Expose to external at


External - Local - NFS/SMB2/AFP/FTP/WebDAV and


Michael G. and Tyler W. started project to move machines to images.

Current machines are riddled with malware. Master image was not kept up to date and cloning using ghost is pretty annoying/not being done.

Proposal was to explore hypervisors and install OS as an image on each machine that could be pushed down or pulled down from NAS as needed. Add support to each machine.


HV - Hypervisor VHD - Virtual Hard disk (format varies by option) PPT - PCI Pass through (Assigns a dedicated device to a VM) TF2 - Team Fortress 2 VDA - Virtual Desktop Access.

Options tested

-- Xen -- Qemu -- Windows VHD support

Game tested on each instance was TF2 on Medium settings. Frame rate considered good was 60+. TF2 is extremely old at this point but I considered it a good benchmark for the baseline of gaming that we'd do at the shop. Many games I see played run on source.

Licensing issues

Our copies of Windows at AHA are not licensed for virtualization. They sell VDA licenses that licenses a client instead of the OS that runs it. We don't have them. This might be a route to check out. The desktop licenses are only licensed for how we have them installed. Windows 8 has a Personal Use License included with some copies. This would allow us to install a VM of Windows on a machine and legally use it there. We cannot host that VM on a server or remote connect to it. [[1]]

Problems across all of the options

Windows really doesn't like being virtualized in a multi-install environment. Graphics performance is not great with existing cards at AHA unless they are used in passthrough mode. This requires purchase of another graphics card for use by the host OS. Network issues with clashing host names for SMB sharing and if we did proper DNS.

Xen (Debian) as hypervisor, Windows and Linux on VHD

Installed on a box, configured both Linux and Windows as images.

Linux- No major problems. Multiple copies cannot be started on the same network without tweaking the Xen host to mask each one on Proxy. Annoying but workable. Windows - Using the virtual frame buffer graphics performance for games is slow...

Successfully installed Xen on a box and configured both a Linux and Windows distributions. I tested both virtualized graphics card drivers and passthrough setup.

Virtualized graphics performance is not okay for heavy or even medium gaming. Similar to performance on Qemu. Passthrough graphics performance is great. This requires purchasing a dedicated graphics card for use by the host OS when the internal card is passed through to VM.

With multiple graphics cards ideally add a KVM switch so a key combination will switch the monitor, keyboard and mouse between host and the VM.

Guest OSs are easy to make as images.

Annoying to setup.


Installed Qemu on Debian without Xen. Qemu can also be leveraged by Xen for certain OS installs. Installed both Windows and Linux on Qemu setup using VHD.

Linux - Runs fine has passthrough of framebuffer via emulated drivers. Has 3D support but not as fast as native. Multiple copies of OS aren't easy to do without configuration to each. Windows - Runs fine. Used passthrough of framebuffer via emulated drivers. Has 3D support but not as fast as native. Won't support newer games at decent settings without a better graphics driver. Multiple installs are problematic since device names clash on the network.

Both are VHDs but have network naming problems when run on multiple machines.

Windows VHD support

Windows has built in VHD support.

You can bring up cmd line and mount a VHD during windows install.

This lets you create images which you can easily remove of an OS afterward or move between machines if hardware is similar. Only one OS loads at a time the benefit is simply that you can have multiple images that are easy to replace on the same machine. That OS has full use of the graphics card. This is ideal.

Windows only. This doesn't change our current situation in anyway except if we wanted to test other versions of Windows.


Allows booting VHDs via multiboot in Windows that are not Windows based installs. This allowed me to install and configure Linux. No different really then setting up Grub to allow multi os booting. Seems to play nicer with UEFI than Windows/Grub combination. Windows is still not in an image though.

Grub2 Image support

Grub2 has support for loading images. See VBoot above as it's features are used by my test install of Vboot just simply with a Windows host.

Proposed solution

Please comment here with questions or comments.

Tyler W.: We should review our gaming requirements. If we still need to play games at full speed to support members, then virtualization is out of the question until we have funds.

We can virtualize (have funds!): Qemu or Xen are the way to go. Xen's passthrough is great, but requires that we also purchase hardware in addition to Windows 8.1 licenses. Legally we cannot virtualize our copies of Windows 7.

We can't virtualize (we are broke): Dual boot with the Linux image being a VHD booting enabled by VBoot.

NAS is used to store both a VHD of Linux that we keep up to date and the same across all machines. NAS is used to store ghost image of Windows drive. NAS LDAP is used to control access to both Windows and Linux.

Guests: Kiosk Linux Account.

Members: Named personal LDAP enabled Linux account with file storage and a shared Linux Steam library. Do not have SUDO but can build and install packages in their local directory for personal use. We'll provide a base set of packages that we keep up to date.

Only those with express need for Windows gaming (games that we can't run on Linux) get tagged in LDAP to be able to authenticate on Windows. Idea is to phase out Windows use on lab machines.

We actually keep the ghost image of Windows up to date this time. Update process would be. 1) Pull existing image from NAS to a machine via ghost. 2) Bring image up to date and install new software, patch all games to current date. 3) Push clean image to NAS. 4) Update machines from NAS.

Machines auto boot to Linux VHD.