Server 2008 SP1 VSS Writers Not Responding

Do any of the VMs you're trying to back up contain dynamic disks? (That's in disk management within the VM, dynamic disks as opposed to basic disks. Not dynamically expanding VHDs)

To quote Microsoft:

When you perform a backup of the virtual machines, you must back up all volumes that host files for the virtual machine, including the InitialStore.xml file (in C:\ProgramData\Microsoft\Windows\Hyper-V, by default) and the volume(s) containing the VHD(s) and configuration XML files. For example, if the virtual machine configuration files are stored on the D: volume, and the virtual machine virtual hard disk (VHD) files are stored on the E: volume, and InitialStore.xml file is stored on the C: volume, you must back up the C:, D: and E: volumes. Virtual machines that do not have Integration Services installed will be put in a saved state while the VSS snapshot is created. Virtual machines that are running operating systems that do not support VSS, such as Microsoft Windows 2000 or Windows XP, will be put in a saved state while the VSS snapshot is created. Virtual machines that contain dynamic disks must be backed up offline.

If you disable the VSS provider then there is a good chance that you're not going to get a consistent filesystem on the clones. That's one good reason not to do this. Another problem you have here is that you need to be 100% certain that there's no risk that one of the clones will ever come up on your live environment - that will be a very bad thing. If you restore one of those clones in a production environment (ie with any other DC still active) then you risk triggering USN rollback - see this technet article for more info and Zoredache's answer in this earlier ServerFault question.

The best way to handle this is to create another VM, and as JakeRobinson said follow the standard procedures with dcpromo and let it sync itself up. You can keep this online, or keep it mostly offline and let it sync periodically if you wish, but this way you don't run any risk with corrupting the AD databases.