Good information Keith, we were really shooting to eliminate any in guest 
backups if possible with the exception of any hosts that have physical RDM's. 
Licensing wise are you guys capacity based or PVU based? We're utilizing PVU 
right now so that was another big reason we wanted to pull the agents out of 
the guests to save some costs there as well. We've found however that the file 
level recovery with TSM for VE is really too slow and unusable with any other 
back-end storage other than VTL or disk in our opinion.

Are you utilizing one overall policy for all your TSM for VE backups? Sounds 
like with the way you're capturing mainly the OS that would work really well in 
your environment.

----- Original Message -----
Hi Ken,
We have been using TSMVE 6.4 for a couple months, I wouldn't call the following 
a set of best practices, but they work well for the restore service we provide.

File restore services are still provided with TSM Extended Edition. Nothing 
different there. Recovery of the first disk on virtual machines is provided 
with TSMVE 6.4. Should disaster strike, the frst disk is restored by TSMVE, 
then files and directories are restored with TSM Extended Edition. We only 
snapshot the first disk.

Our standard virtual machine is created here with a first disk of 60 GB and 
additional disks for data storage. VM admins are encouraged to install their OS 
on the first disk. We snapshot the first disk only by adding this statement to 
dsm.opt for each data mover; INCLUDE.VMDISK "*" "Hard Disk 1"

If the first disk of a virtual machine is greater than 60 GB, that guest is 
excluded from snapshots by appending '-NB' to its display name in the vSphere 
client. Then, '*-NB' [ star dash NB ] is added to the exclusion filter in the 
TSMVE plug-in when a scheduled or run-now backup is created.

We use one data mover per cluster, and put the data mover on the cluster it 
backs up for performance reasons. We exclude the data mover from the backup 
using the filter, and back it up with TSM/EE. Each cluster is scheduled for 
backups once a week, and two versions are kept. Our largest cluster has 12 
hosts and about 420 guests. Our 'vmlimit' options are fairly conservative, and 
could change with more experience. Here they are:

VMMAXPARALLEL 8
VMLIMITPERHOST 0
VMLIMITPERDATASTORE 1

So far, so good.

Best wishes,
Keith Arbogast
Indiana University