Best Practices for Templates
Virtual machine templates are very powerful and versatile. The following best practices, culled
from many different areas of IT infrastructure management, will enable you to derive the most
value from templates and avoid starting ineffective habits.
Install Antivirus software and keep
it up to date: In today’s world
of viruses that are hyper efficient
at exploitation and replication, an OS installati
on routine has to merely initialize the network
subsystem to be vulnerable to attack. By deploy
ing virtual machines with up to date antivirus
protection, this exposure is limited. Keep
the antivirus software current every month by
converting the templates to VMs, powering
on, and updating the signature files.
Install the latest operating system patches, and st
ay current with the latest releases: Operating
system vulnerabilities and out of date antivirus
software can increase exposure to exploitation
significantly, and current antivirus software isn’t
enough to keep exposure to a minimum. When
updating a templates antivirus software, apply any relevant OS patches and hotfixes.
Use the template notes field to store update reco
rds: A good habit to get into is to keep
information about the maintenance of the template
in the template itself, and the Notes field is a
great place to keep informal update records.
Plan for ESX Server capacity for template managemen
t: The act of converting a template to virtual
machine, powering it on, accessing the network to
obtain updates, shutting down, and converting
back to template requires available ESX Server re
sources. Make sure there are ample resources for
this very important activity.
Use a quarantined network connection for updating templates: The whole point of keeping
antivirus and operating systems up to date is to av
oid exploitation, so leverage the ability of ESX
Server to segregate different kinds of network tr
affic and apply updates in a quarantined network.
Use the same datastore for storing templates and
for powered on templates: During the process
of converting templates to virtual
machines, do not deploy the template
to another datastore. It is
faster and more efficient to keep the template’s
files in the same place before and after the
Install the VMware Tools in the template: The
VMware Tools include optimized drivers for the
virtualized hardware components that use fewer ph
ysical host resources. Installing the VMware
Tools in the template saves time and reduces th
e chance that a sub optimally configured virtual
machine will be deployed to your production ESX Server infrastructure.
Use a standardized naming convention for templa
tes: Some inventory panel views do not offer
you the opportunity to sort by type, so create
a standard prefix for templates to help you
intuitively identify them by sorting by name.
Also, be sure to include enough descriptive
information in the template name to know
what is contained in the template.
Defragment the guest OS filesystem before conv
erting to template: Most operating system
installation programs create a highly fragmented
filesystem even before the system begins its
useful life. Defragment the OS and convert to
template, and that way you won’t have to worry
about it again until the system has been in production for a while.
Remove Nonpresent Hidden Devices from Template
s: This problem will like
ly occur only if you
convert existing physical images to templates.
Windows will store configuration information
VMware VirtualCenter Templates
ESX Server 3/VirtualCenter 2
Best Practices for Templates 10
about certain devices, notably network devices,
even after they are removed from the system.
Refer to Microsoft TechNet articl
e 269155 for removal instructions
Use Folders to Organize and Manage Templates: Folders can be both an organizational and
security container. Use them to
keep templates organized and secure.
Create Active Directory groups that map to Virtua
lCenter roles: Rather than assign VirtualCenter
roles to individual user accounts, create dedi
cated Active Directory groups, and place user
accounts in those groups.
Wouldn't presenting a Template Datastore to all hosts let you run into the maximum allowed hosts per volume ?Hosts per volume 64
As per the configuration maximum guide: Hosts per volume 64
The templates will have to be registered somewehere on a management cluster for instance.
Then you deploy the templates from your shared datastore to a datastore, probably, dedicated to the target cluster.
So the source host (where the template is registered) does not have direct access to the target datastore.
Only the receiving host has access to the source and target datastore.
In this case, I still do not think that VAAI will help you, and data still travels across your network interface.