Here is the long version of my question. I hope it's clear.  

"Recommendations for Scheduling with TSM for VE" in the TSMVE wiki recommends 
"including the ESX server that is processed in the name" of options files, and 
by examples, the backup instance names too.  We did that, and were quite happy 
with the model until we learned that our ESX hosts are sometimes moved between 
clusters for load balancing. When that happens, host specific names will create 
side-effects.  Specifically, the backup instance which processes that host will 
no longer be in the same cluster as the host it backs up --which will degrade 
its backup performance, and its processing will have to be moved to a backup 
instance on the new cluster. 

Our testing has shown that a backup instance needs to live in the same VMware 
cluster as the ESX host it processes for best performance. We don't let LUNs 
mix between clusters, so we can't put all our backup instances on one host and 
zone it to see all the LUNs in a datacenter.  

We are installing multiple (4) backup instances per virtual machine. Each one 
will process one ESX host which is named in the DOMAIN.VMFULL option in its 
dsm.opt. 
  
For backup instance names, we could use specific names as recommended, like 
TSMVE03-ESX01; or generic names, like TSMVE03-A  (where TSMVE03 is the name of 
the virtual machine underlying the backup instance, 'A' is anything, and ESX01 
is the host processed.)  

If we use specific names, it should be easy to see which backup instance was 
affected by a host move, since the host is part of its name.  But, it will be 
complicated to manage after that.The old backup instance will have to be 
removed, since it can't be reused, and a new backup instance with a new 
specific name installed on the new cluster. Hooray for dsmcutil, but it can be 
moody.
 
If we use generic names, it will be difficult to see which backup instance was 
affected by the host move, since generic names are meaningless. But, once it is 
found, perpetuating the backup process will be easy to manage. Just stop CAD on 
the old backup instance. It can even be reused for another ESX host by 
modifying its DOMAIN.VMFULL option. A handy generic backup instance on the new 
cluster will be put into use for the moved host.
 
Each naming scheme has strengths and weaknesses. If a table and column is 
available which contains the DOMAIN.VMFULL option we could use a select 
statement to find the backup instance affected by a host move. Being able to do 
this would allow us to use generic names for backup instances which should make 
management of host moves easier than if backup instances had host-specific 
names. 

I would be glad to hear if I have missed the point somewhere in absorbing the 
TSMVE documentation. 

With best wishes,
Keith Arbogast