Yes. PaperCut will work fine and is fully supported on VMs such as VMware, EX Server, Microsoft Virtual Server, Hyper-V, VirtualBox, Xen, KVM, Parallels, and QEMU. We do have many large customers now running PaperCut in virtualized environments (on Windows, Mac and Linux). We’re finding that more users, both large and small are moving across to virtual machines to host their print queues and print control software. There is also a growing trend in private cloud deployments.
- Take care not to skimp on RAM. Allocate a server class amount of RAM to your VM. NOTE: PaperCut will use 1/4 of the available memory of the machine by default. So if you are building a VM for the PaperCut App Server, start off with a 4GB VM, and allow PaperCut to use up to 1/2 of the memory by making this config change. We find that many sites have a tendency to run their VM’s light on RAM. Linux systems generally handle this well but Microsoft Server guests will suffer with poor performance with low RAM. If the VM is dedicated to running PaperCut, see the KB article Increasing the Memory Available to PaperCut NG and PaperCut MF.
- IMPORTANT: Ensure that the VM host does not artificially restrict physical memory allocated to the PaperCut machine. VM tools often allow admins to restrict a guest VM to a maximum amount of physical RAM. This option can have severely adverse affects on the PaperCut system. Ensure that the PaperCut guest VM has full access to all the physical memory allocated to the guest OS. (See the section below for a technical explanation as to why this is important).
- Keep an eye on system performance over the first few weeks of operation. We’ve seen sites deploy PaperCut on overloaded VM Hosts causing guests to be starved of resources. This would usually be observed by seeing slow printing performance and/or a sluggish “feel” when using the web administration interface.
- Ensure you allocate enough CPU resource to the VM. PaperCut is highly multi-threaded and we recommend more than one virtual CPU - particularly if the machine is acting as both the PaperCut primary application server and a busy print server.
- Take care with backups. Although a snapshot or copy of a whole VM disk image is a backup option, scheduling a direct PaperCut data file or database backup is still strongly recommended - i.e. one small corruption in a part of a disk image may render the whole filesystem useless. Having a backup of just the files you need will reduce the changes of such a mishap occurring.
Why is VM physical RAM allocation important?
PaperCut is a real-time application. It needs to be able to respond to network requests in a timely manner. Network requests come from a variety of sources ranging from secondary print servers, MFD embedded software, desktop client software, and of course Administrators using the web browser interface. Because of this real-time nature, it’s important to ensure that the operating system has Physical RAM reserved.
If an operating system’s physical RAM is swapped out by the VM host, the whole operating system may freeze while its memory is paged back in. (Note that this behavior is different to application swapping as the whole operating system is contended rather than just an application.) During this period the operating system will be unable to process new TCP connections in a real-time fashion. TCP connections may back up (or time-out) and when the system returns, and the TCP traffic will flood back in. This may swamp the system. PaperCut has seen this “bursty” network behavior cause issues on large sites with high print volumes, a large number of active clients and/or a large number of jobs in a hold/release queue. These issues have been resolved by ensuring that memory allocated to the Virtual Machine Guest hosting PaperCut is reserved physical memory.
Comments on individual technologies:
QEMU: As a general rule we do not encourage the use of QEMU in a Linux server environment as the performance is a little slow. Instead consider KVM. KVM builds on QEMU and leverages hardware vitalization. XEN is another popular alternative.
Keywords: artificial, virtualisation, hypervisor, HyperV