On Mon, Dec 24, 2012 at 4:01 AM, Timon Wang <timonwst@gmail.com> wrote:

If a vm join AD domain, the name is registered in the AD server, when I copy a VM, the name will conflict with the source VM. I wanna to know if I can change the VM computer name automaticly.

This is not a hostname issue. This is a pure AD/NT-SID issue** (Security Identifiers). It affects all virtualization solutions, even Hyper-V. Two (2) systems must have unique SID enumeration.** When you have standalone systems that are not part of a domain, as long as the two systems never see each other, it's typically not an issue. But when they are part of a domain, it is an issue, because there must be an unique SID enumeration for any domain member. You should never clone/create/instance/etc... a system once it's been joined to a domain, unless you use a solution that undoes its SID enumeration. Microsoft introduce sysprep years ago so when a system reboots, new local SIDs** are enumerated. This is recommended for all systems when cloned, whether they join an AD domain later or not. Some virtualization solutions don't bother to sysprep the system before joining them to a domain. This is because the SID enumeration in a domain is domain-wide, and the local SIDs are usually not utilized. This drastically reduces issues although there can still be issues between two nodes that have the same local SID enumeration.** There is no way around this issue, as it's a core NT issue. The recommended solutions are to either ... - Always run SysPrep before making a template, regardless whether an AD member or not - Join the domain as part of a local group policy before the system comes up (e.g., still has duplicate local SIDs) In oVirt/RHEV, you can join the domain as part of the SysPrep scripts. The easiest way to do this is to create an user in your AD domain that only has the delegation and no other role. The system is joined to the AD domain upon first boot of the VM instance using that user. -- bjs, MCITP/MCSE/MCSA **NT INTERNALS NOTE: The local System Accounts Manager (SAM) and other portions of the local NT systems' Registry, as well as the local NTFS file systems attributes, are where local SID are stored and utilized. The first NT system promoted to a Domain Controller (DC) has its SAM and SID enumeration because the initial, network-wide SIDs for the domain (that's an over-simplification, but similar), and it no longer has its local enumeration (all DCs are like this, there is still a local SAM/SID enumeration, but it is not referenced, which is a long and complicated story with some issues). When a local system joins a domain, and becomes a domain member, it starts using those SID references. The local SAM/SID still exist and are known (unlike a DC, which stops using them altogether), but are typically not utilized. So SIDs are usually no longer an issue, unless you have member workstations/servers directly accessing and managing other member workstations/servers (e.g., IPC like to C$ or similar). It is very, very important that anyone managing Windows systems understand these internals, especially when it comes to domains. Sadly a lot of MCSEs (especially older ones) don't seem to, among other NT and AD internals. Microsoft still doesn't offer a good AD internals course, although they do have a good NT internals course as well as set of books. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith ---------------------------------------------------------- Computers are precise, but not accurate, and make mistakes due to lack of input, as lack of awareness and observation