Can't VMotion after Virtual Center Upgrade

[lucheman]

I have 4 ESX 2.5 hosts. I just upgraded Virtual Center to 2.0. Since doing that, I can not migrate or vmotion any of the Virtual Machines anymore. It fails with a "network copy failed" error message.

Any ideas?

[jasonboche]

Possible resolution for your issue (DNS related):

http://www.vmware.com/community/thread.jspa?messageID=551581

[Dave_Mishchenko]

This may indicate a problem with name resolution. Do you have the servers registered in VC with FQDN? If so, from a console on the ESX hosts can you ping the other ESX host involved in the vmotion?

If not, you can

1) put the registered name in this file on the ESX hosts: /etc/hosts

2) reconnect the hosts in VC using FQDN (assuming the ESX hosts can ping each other with the same FQDN).

[lucheman]

Excellent, thank you guys. Two last questions:

I understand how host files work, but how exactly do I use vi to edit the etc/hosts file?

In order to verify that this is infact a DNS problem, couldn't I just remove the servers from Virtual Center, and then re-add them by using their IP address instead of their FQDN? This way DNS would not be used right? If VMotion works this way, then I know for sure it is a DNS issue and that I will need to edit the etc/hosts file, right???

[jasonboche]

Hah... I personally avoid the VI editor if I can. nano[/b] is a much more Windows Admin friendly editor and it's bundled with ESX.

nano -w

ie.

nano -w /etc/hosts

To exit and save changes,,

CTRL + X to exit

Yes to save changes

ENTER for default file name (assuming you want to write to the existing file name)

/etc/hosts is where you would place your static host names to resolve the DNS resolution issue. You'll want to place two names in the host file for each host instance:

hostname1

hostname1.fqdn.name

hostname2

hostname2.fqdn.name

hostname3

hostname3.fqdn.name

etc.

The single hostname entry is the one that kills HA and is generally having sporadic issues in VirtualCenter. To this day I do not understand why VirtualCenter must be able to resolve the single hostname when the host is registered in virtualcenter with the FQDN. It's idiotic.

Message was edited by:

jasonboche

If this is a DEV environmet, sure you can remove and re-add using the IP address, but this process is more destructive to the environment as you will lose all of your historical host performance data.

[lucheman]

Dude, you rule, thanks. (I guess my Windows Admin background shines through even when I try to hide it!)

What do you think about what I said about testing it without DNS though, is that a valid test? To recap, if I remove the ESX server from Virtual Center, and then re-add it to Virtual Center using the IP address instead of the name, then I try the vmotion again. Does that make sense?

[jasonboche]

Yes, it's a valid test, but I could edit /etc/hosts just as fast or faster (and less destructive) than evicting the host out of VC, readding by IP, testing, evicting again, readding back by FQDN, then re-setting up DRS, HA, VM boot order, etc.

[lucheman]

I understand, I am just thinking if I have a problem editing the etc/hosts file for some dumb reason.

On that subject, if I remove the ESX server from virtual center and then readd it, the vms on that ESX server will continue to run right? Why do you call it destructive?

I promise that is my last question: I will mark your reply as correct after this.

[jasonboche · Accepted solution]

It's just a text file.

Even in the worst of botch jobs, you can copy an /etc/hosts file from a different ESX server and customize it for the new host.

On that subject, if I remove the ESX server from

virtual center and then readd it, the vms on that ESX

server will continue to run right?

Yes, the VMs will continue to run.

Why do you call

it destructive?

Because you will likely lose your historical host and VM data and depending on your configuration, you may have to reconfigure for DRS and you might also garf up any special VM resource reservations, limits, and shares because in the process of pulling the host out of a cluster and a resource pool, you will also yank the VMs out too.

I promise that is my last question: I will mark your

reply as correct after this.I understand, I am just thinking if I have a problem

editing the etc/hosts file for some dumb reason.

[lucheman]

Sorry, I lied:

I just want to be sure that I CAN run Vmotion, Clone, Migrations, etc, on Virtual Machines that reside on ESX 2.5 boxes, using Virtual Center 2.0.

I know I can't configure the ESX 2.5 boxes themselves using VC 2.0, but I can still VMotion and Migrate all of the VMs on those boxes right?

[jasonboche]

Oh yeah, sorry, I forgot your hosts were still ESX 2.5. Forget what I said about resource pools and clusters.

Yes, cold migrations and hot migrations (VMotions) should still function with an ESX 2.x host in a 2.x VirtualCenter environment.

[lucheman]

Thanks man. I appreciate all the help.

[mvoss18]

I've been managing a 2.5.3 environment managed by VC 2.0.1 for awhile. No problem doing VMotion or cold migrations. The only issue I've had is changing shares or reserving cpu, which I can do in the MUI.

This might sound rather simple, but I am assuming you right-clicked on each host and make sure that VMotion was enabled with the right ip address. We are using FDQNs for the hosts in a full AD environment with DNS.