The problem is that if using a the same domain controller ("DC" aka your primary AD server) from several machines, the DC will cache the SID and machine name of each machine that connects to it, and store Secure Channel tokens on both the DC and each machine. These are valid for 30 days before being recreated, and old tokens are remembered to ensure continuity; much the same as old passwords are cached so you can't re-use them when certain AD policies are in place. This whole process exists so you can't spoof a machine in a Windows network, which is what you're doing, albeit on purpose and with good intentions.
First a non-solution, then two solutions. You may be able to fix this for 30 days by copying your SharePoint image after the initial connection to AD rather than before. But eventually the Secure Channel token requires renewal and at that point, you're out of luck.
The real solution: this is a case where unique SIDs and machine names will cause some configuration pain but will solve the problem. What each SharePoint server needs is a unique identifier as described on pp. 41-44 for building farms.
Where the pain comes is that the SID and new machine name are assigned after Windows Server 2003 is installed, but before SharePoint. If you're wishing that part of the install could be scripted easily, that's a hope for Windows Server 2008.
Speaking of 2008, it's said that server name changes on Vista Server are painless (see the last paragraph of http://bobfox.securespsite.com/FoxBl...ost.aspx?ID=45
) and SIDs aren't used in SharePoint's configuration database though they do tend to "grow roots" in the registry.
The other solution: Perhaps you can clone your AD server and pair each with a SharePoint server to spin up isolated development farms. This would eliminate the token caching issue, because each AD server is paired with a SharePoint server. For me this would be less effort to install AD and DNS on a base image for cloning than SharePoint plus my development tools. If you still need a central DC, your virtual machines could simply be on a different domain with a trust to your "physical" domain.
If you choose that route, you should only need a minimal virtual hard drive (1 to 4 GB?) and 256 MB RAM (or less) to run an effective DC with AD and optionally DNS. Remember to remove unused Windows components and services. Really low memory will mainly affect this server's boot time, but once running AD is extremely efficient.
Hope this helps,