Moving Virtual Center from VM back to Physical

[juchestyle]

Hey guys,

While I think this is straight forward, I would like to simply confirm and of course hand out points for worthwhile contributions.

Here is what we got: We have VC 2.5 running in a VM that connects to a remote SQL instance. I have a physical computer that is ready to get VC installed, the lic file has been moved over but nothing installed yet.

What we want to do: We think the right thing to do is stop the connection on the VM to the remote SQL database. Turn off the VM. On the physical machine, install VC 2.5, and point it to the remote SQL instance, next next finsh.

Anything we should be wary of, is it this simple and straight forward? Any gotchas?

Respectfully,

Matthew

Kaizen!

[Chamon]

I have seen posts with people having trouble with the wording during the VC install in relation to connecting to the existing database (they accidentally wiped it out ). You may want to look at this first and of course be sure to have a good backup of the db.

[juchestyle]

Only one person wants points?

R,

M

Kaizen!

[wila]

Hi Matthew,

Did you read this thread? and more importantly Mike his document?

--

Wil

[mittim12]

I also think this is a very straight forward migration. The other poster brings up the database wiping problem with 2.5 but I thought that was only when performing upgrades. Since your DB is already up to date youy should simply be able to point VC to there and be fine. Will you be naming the new VC box the same as the old? If not you will need to specify the new license server on the various ESX host.

[Patrick_Miller · Accepted solution]

Matt,

I just went through this, although it was going from a physical server to another physical server. Works exactly as you described, didn't have any issues.

[juchestyle]

Allright, so the problem I am having. Trying to move ESX hosts from old vc to new vc. They get over to the new ok, but then stop responding.

I think the issue is that the agent is not upgrading properly or there is a config file that still points to the old vc, or the old agent never uninstalled.

Alittle help anyone?

Respectfully,

Matthew

Kaizen!

[mittim12]

Are all your host having this problem or just a few? What version of ESX are you running on the host with the issues? Are there any error messages?

[Chamon]

Did your ip address or Host name of the VC change? Are the hosts pointing to the correct License server? Do you have static entries in the Host files? May need to remove them from the VC and then add them back. It is a new server so does the vpx user account still work?

[juchestyle]

Every single one...on the phone with vmware now.

Kaizen!

[Chamon]

Sounds like the same problem as in this post if your IP address has changed on your VC

http://communities.vmware.com/thread/123880?tstart=0

[juchestyle]

yeah, I see that post, and we have removed and added back into ad nauseum with no luck. Vmware is talking to escalation now.

the seems to be a file that is keeping the old IP address from the old vc, and not letting us get past that.

r,

M

[Chamon]

Did you change the IP of the vc? I just saw another post that they needed to change the IP in the ODBC connector.

Do you need to remove the vc agent from the hosts?

remove vc agent on server

rpm -e VMware-vpxa-2.0.x.xxxxx(get the full packaged name by typing command "rpm -qa | grep -i vmware-vpxa)

Don't know if that will help.

[RParker]

We did this, and it was pretty simple.

However, in the mean time I attempted a database upgrade (SQL 2005 SP2) and it never did work. We just installed a FRESH DB, and everything worked. But simply shutting off the previous VC, and ensuring the NEW VC is working (all updates, .NET, add-ins, etc) you should be able start the NEW VC service, and everything should work fine.

[RParker]

I think this is rather interesting timing considering recent posts about people insisting that VC works fine in a VM, but we found otherwise. It's rather peculiar that you would all of a sudden start using a Physical box for VC as well.

We found the VM to be rather inconsistent with respect mostly to networking, and other than that we have no networking problems, only the VC in a VM. I did try a stand alone workstation, VM Server (A rather large, equivalent ESX config box with only 1 VC/ VM instance) and of course ESX and finally we came to the conclusion that the difference was the VM, we put it on a Physical host and everything has worked flawless, and MUCH, faster and more reponsive. We aren't using VM's for management again.

[mittim12]

Did you change the IP of the vc? I just saw another post that they needed to change the IP in the ODBC connector.

Do you need to remove the vc agent from the hosts?

remove vc agent on server

rpm -e VMware-vpxa-2.0.x.xxxxx(get the full packaged name by typing command "rpm -qa | grep -i vmware-vpxa)

Don't know if that will help.

We had this same problem when attempting to manage 3.01 host from our new 2.5 VC environment and the the rollback of the VC agent corrected our problem.

[juchestyle]

totally new vc, new ip, copied over the old database. Yeah, this should have been a no brainer.

We have uninstalled the old agent and put it back - no go

we have stopped and restarted all sorts of things - no go

Good times!

Respectfully,

Matthew

[RParker]

The process is:

remove ESX host from cluster.

login to ESX host as root.

remove users vpxa and vimuser

reboot host.

Add new ESX host to new cluster.

There shouldn't be any lingering information.

[juchestyle]

Good ideas. The problem is that we want to be able to preserve all the settings we have out there. We can start from scratch, but we want to keep everything we have already built. not start from zero.

Respectfully,

Matthew

Kaizen!

[samugi]

Have you checked to make sure that on your new VC physical server that the 'VMware Virtual Center Unique ID' is set to the same value as VC was using prior to moving it. This can be found under runtime settings in VC management server configuration.

Hope this helps.

Sam