The most important thing to do is to entirely turn off all the servers in your farm before you make their copies. If you don't, you're facing a very real risk that when you turn on that test farm you're going to be dealing with errors or corruption in various
areas of your farm. Search is the most likely function at risk, because SharePoint's search index files are very tightly coupled with its Search databases, but it could come in a lot of different areas. That's because timer jobs are almost always running somewhere
in a farm and if the state of that job on one server is different than it is on another while they are each copied, that will lead to issues. Or if a server is making an update to the database while its being copied but is done when the database is copied,
that's also a major issue. So you'll need to turn off all the servers to make sure that there aren't any running processes and ensure consistency throughout the farm.
Beyond that, there are the normal issues you could face in regards to copying VMs with name or IP address collisions, but that's not specific to SharePoint. One other thing I can think of mentioning is that you need to make sure to be careful in the event
that you need to copy content from one farm to the other: because you're going to copy the farm, all those GUIDs (Global Unique IDentifiers) that the farm uses to identify things like site collections, sites, lists, etc will not actually be unique. If you
have to move that stuff, you'll have to use SharePoint's content migration processes (including Export/Import) or the unattached content database option rather than copying a database or doing a Backup/Restore.
John
MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and
The SharePoint 2007 Disaster Recovery Guide.
My blog: My Central Admin.
