Change NIC settings in a VM snapshot

[goAtsy]

Hello,

I'm writing a PowerShell script that clone parts of a customers production environment by automating storage systems and VMware Infrastructure.

The process in short...

• Take snapshots of source VMs | VI (to get more consistent state to copy)

• Take snapshots of storage volumes where source VMs reside | Storage

• Remove snapshots of source VMs | VI

• Map the volume snapshot to the same cluster as the original volumes | Storage

• Rescan, resignature and rename datastores | VI

• Create a resourcepool and register the cloned VMs from the new datastores | VI

• Connect cloned VMs to new networks isolated from the production networks | VI

• Revert the cloned VMs to the consistent snapshot | VI (the cloned VMs now runs on the same hosts as prod)

Now the problem...

When reverting to snapshots the cloned VMs NICs are set back to the original production networks, as that was the state at snapshot time. And as most source VMs were powered on when taking the snapshot the clones will be to. And I can't risk having that state even during the few seconds it takes to set the NICs to new networks.

I mistakenly thought that the snapshot only affected the disk state and not VM settings.

I'm looking for any smart idea on how to work around this problem. I know that the method RevertToSnapshot_Task in the vSphere API has a suppressPowerOn parameter. Unfortunately it requires 4.0 and my customer runs 3.5. Otherwise I could live with using that and starting them after reverting to snapshots and changing networks.

The Get-NetworkAdapter CmdLet has a -snapshot parameter with the help description "Specify the snapshots from which you want to retrieve virtual network adapters". That sounds like I could get a network adapter from a snapshot and pipe it to Set-Networkadapter. It sounds a bit far fetched and I can't get it to work at all.

If you know how it works or have any other idea please let me know.

Thanks in advance

[LucD]

I'm afraid the Set-NetworkAdapter cmdlet doesn't allow you to specify a snapshot.

Which is understandable when you look at the VirtualMachineSnapshot object. You can read the config and obtain the portgroup to which the NIC in the snapshot connects. But there is no method for the VirtualMachineSnapshot object to change the config.

Perhaps a stupid suggestion, but can't you have an ESX (or ESXi) server that is not connected to your production network ?

A kind of staging ESX/ESXi server.

That would allow you, imho, to:

1) do the RevertToSnapshot_Task on that ESX/ESXi server or use the Set-VM -Snapshot cmdlet.

2) allow the guest to power on (because, like you said, the snapshot was taken in the powered on state)

3) change the network adapter's portgroup of the guest with the Set-NetworkAdapter cmdlet)

4) vMotion (with the Move-Vm cmdlet) the reconfigured guest to an ESX server that has a portgroup that is connected to the production network.

[goAtsy]

Hi LucD,

The script will run to rarely to justify dedicating a host, and if we decide to clone the full production environment a single host can't take the load.

Thanks for the idea anyway

Edit: My head wasn't working... We could of course send one VM at a time through the dedicated host. Change the settings and move it on to the production farm. That would take care of the load problem.

[goAtsy]

We will probably create snapshots without preserving memory state. That will result in a powered off state when reverting.

[LucD]

I think that will be the easiest and most flexible solution.

[tonygent]

Hi - sorry to stick my 5 pence in, but why not revert to the snapshot "THEN" change the network settings?

It does make more sense to the have the VM's shut down, as the snap will provide "Application Consistency" assuming you have the VMware Tools VSS Driver installed, so there is no fear of the apps being in a bad way.

You can kick off a task to revert the snap, monitor, wait until it's done, change the network settings, then boot the VM.

[goAtsy]

Hello,

I don't follow you tonygent

Revert to poweredoff snapshots and then change networks is the conclusion we got to above.

But what I preferably would like to do is to take snapshots of the production VMs with memory state and then revert the cloned VMs to these "powered on"-snapshots. But as the cloned VMs will be registered to the same hosts we can't (IP/naming conflicts).

As we cannot bring down the production environment that is about to be cloned, the best solution, atleast for ESX 3.5, seems to be to take snapshots without memory state (results in poweredoff clones), and that wouldn't give higher application consistency.

[tonygent]

Hi again.

Sorry If I'm confising matters. Yes I agree that you can't bring the VM back with RAM on the same host. My point is that application consistency SHOULD be valid even for VM that has a SNAP taken without memory. With the latest VMware Tools there is a VSS Compliant consistency driver, this means that snaps taken within VMware will have applications (like SQL and EXCH) placed into a VSS consistent state prior to the snap being completed.

I'm no expert on VSS, but this should assure you an application consistent snap even though you are are not snapping the RAM.

I'm unsure if you will need to use VSS commands to "revert" the VSS snap created by VMware tools, but I expect that this should not be required.

Hope this is slightly more clear :smileygrin: