Subscribe
Accepted Solution

RapidClone VM using Source VM IP before customization

I'm new to Rapidclones, using VSC 2.1.2.  I created four clones of a 2008R2 server, and left them powered OFF.  I powered one on and watched the console.  It booted up to the login screen and I saw VMware tools report that it got a DHCP address, which is correct.  However, at this point it was still named the same as the source VM and therefore it registered this DHCP address with DNS as the original source hostname. 

So I got on the source host console and did an ipconfig /registerdns to fix that.  As I was doing this, I noticed the clone rebooting.  It rebooted once or twice and then joined itself to the domain with its new clone hostname and DHCP address.  This part is correct... but I can't have my clones knocking my source VM off the network while they customize themselves.

Is this expected behavior?  Am I doing something wrong?  I chose to use an existing customization template as part of the rapidclone.

Thanks

Re: RapidClone VM using Source VM IP before customization

I am not sure if this is a support related questions.  , is this something your team handles? 

Mike

Re: RapidClone VM using Source VM IP before customization

Hi,

Since this could be a support related issue, if this is a P1 problem, you should contact NetApp Support.  If not and you have a NOW login, you could ask the question in the NetApp Support Community areas for SnapX products and software.

Mike

Re: RapidClone VM using Source VM IP before customization

I already do have a case open. Thanks.

Re: RapidClone VM using Source VM IP before customization

According to NetApp Support, this is working as designed.  Apparently, you're supposed to use this tool to clone a machine that has been sysprepped, not a running machine.  To me, that's "deploy from template" not "clone".  I can't remember if VMware's built-in clone will sysprep the clones before putting them on the network.

Re: RapidClone VM using Source VM IP before customization

Follow-up with a more correct answer.

I was causing the problem here.  After the clone (but before it was ever powered on), I looked at the VM config of the clone and saw that the network was not set to be connected at power on.  Thinking this was a mistake, I checked the box.  Checking the box was the mistake.  The way it works is the first time the VM clone is powered on, it does in fact have the name of the original so you don't want it to be on the network.  VMware handles the sysprep and reconfiguration to the new hostname, reboots, THEN connects the network.  When it boots up the second time, it has the new name and joins the domain as the new name and new IP.

So, long story short - if you just trust the software here, it'll do the right thing.  Don't mess with the clone until after you see it reboot automatically once.