Best way to move VMs to new host with no shared storage?

[james411]

Hi, I have 2 ESXi hosts with no shared storage, and I want to move some VMs from host 1 to host 2. What would be the best way to do that?

I know there is a cold migrate feature in vCenter, but would I be better off using Veeam? If so, using quick migration or replication? I don't mind powering down the VMs.

Of the VMs I am moving, one will be a Domain Controller and the other a SQL Server. In the case of the DC, if using Veeam replication to move it, when I power it back on on the new host, will it think it has been restored from backup? Or does it not even know its been moved?

Thanks!

[Gostev]

Hi. Quick Migration is simpler and it's being used a lot in scenarios such as yours, based on the feedback we get. VMs will not notice the move, for them it will be just suspend/resume (or shutdown/startup) cycle. Thanks!

[james411]

Hi. Quick Migration is simpler and it's being used a lot in scenarios such as yours, based on the feedback we get. VMs will not notice the move, for them it will be just suspend/resume (or shutdown/startup) cycle. Thanks!

Thank you. I tried QM on a non-critical VM today just to see how it works. It went well, the only thing is it looks like I lost my original network adapter. This was performed on a powered on VM. I chose not to delete the source VM (I wanted to make sure everything worked OK). I have vSphere Essentials so no vMotion, but I left the check box to force Veeam QM unchecked since I figured Veeam should be smart enough to figure that out.

The new VM has Network Adapter #2 now and has a DHCP IP instead of the static it originally had. Is this expected behavior?

[PTide]

Do you have the same network configuration on both hosts?

[james411]

Yes.

Full disclosure, I actually tried QM last night as well, but I did it on a powered off VM. That worked fine. The moved VM kept its original network adapter and IP address. The odd thing though, was the summary screen of the job settings showed the Mode as "vMotion" which confuses me since as I said I don't have a licensed vSphere kit that includes vMotion. It also deleted the source VM even though I unchecked that option.

Here's some more information if this helps. Host A (source host in this case) has (2) Intel E5-2630 CPUs while Host B (destination host in this case) has (2) Intel E5506 CPUs.

I've noticed the following with the modes:
Host A > Host B with VM powered on: Cold Migration
Host A > Host B with VM off: vMotion
Host B > Host A with VM on: SmartSwitch
Host B > Host A with VM off: vMotion

[foggy]

I'd let support to take a closer look at your setup, since the behavior looks unexpected.

[veremin]

I'm wondering what is type of network adapter - e1000 or VMXNET3. Thanks.

[james411]

It is VMXNET3.

Can you comment on why it is choosing the modes its choosing (and how is "VMotion" possible with no vMotion licensed)? Again it seems to choose the following based on the power state of the vm and the source/destination host:
Host A > Host B with VM powered on: Cold Migration
Host A > Host B with VM off: vMotion
Host B > Host A with VM on: SmartSwitch
Host B > Host A with VM off: vMotion

Also, how can I make these moves seamless with my currently configured backups? The one VM I did that was powered off and used the "vMotion" mode was backed up fine. However, this VM that did the "cold" mode and lost it's original network adapter caused an error in the backup job it is in with the message "The object has already been deleted or has not been completely created." I did not have Veeam delete the source VM as I mentioned, it renamed it to _migrated. But, once I checked the moved VM turned on OK, I deleted the _migrated one manually. I'm assuming the backup job is looking for the _migrated VM? Is there a way to update the job so it knows to use the new VM on the new host and the current backup chain (ie not have to produce a new full backup)?

Thanks!

[foggy]

The migrated VM got new ID on its registration in vCenter and is treated as a new one by Veeam B&R.You need to re-add it to the job and map to existing backup file (depending on the backup method, it might require full VM backup during the next job run). The strange thing is it worked in another case (like if vMotion was actually used), so I'd still recommend contacting support with this and also verify the modes selection with them.

[james411]

The migrated VM got new ID on its registration in vCenter and is treated as a new one by Veeam B&R.You need to re-add it to the job and map to existing backup file (depending on the backup method, it might require full VM backup during the next job run). The strange thing is it worked in another case (like if vMotion was actually used), so I'd still recommend contacting support with this and also verify the modes selection with them.

Just an update, according to support I am experiencing expected behavior. The VM that lost its network adapter was a Windows 2008 R2 VM and apparently this is known behavior when backing up/replicating/copy/cloning a windows 2008 VM (http://www.veeam.com/kb1570). I was still confused why this would affect a quick migration, but support said if the mode chosen is not VMotion, the quick migration is essentially just a replication.

This is also apparently why this VM received a new ID in vCenter. Since the quick migration mode was not vMotion, it is registered as a new VM.

I didn't really get a clear answer on how it was choosing the modes it was and how my other VM used vMotion as the selected QM mode since I am not licensed for that, but I am thinking vMotion probably refers to vCenter supported migrations? Which in my case since the VM was off, Veeam essentially did the equivalent of me right-clicking the VM in vCenter and choosing "Migrate"

[foggy]

Right, I believe this is what is typically referred as "Cold migration", but reported as "vMotion" in Veeam B&R UI for some reason.