VMware Cloud Community
Wayne-O
Contributor
Contributor
Jump to solution

3.0.1 upgrade - Datastore Question

Greetings All,

I am currently planning out a migration to ESX 3.0.1 and I have a datastore question.

My current SQL backend is on a server that I no longer wish it to be on. I have built a new SQL server and I was wondering if I need to migrate the actual database from one SQL server to the other prior to moving forward with the upgrade so that Virtual Center will be able to migrate smoothly from one server to the other.

I am not performing an IN PLACE upgrade. I currently run 3 2.5.2 ESX servers and I just installed 3 new servers that are identical to the other 3 and I will be installing 3.0.1 on these servers.

I have created 3 identically sized LUNS in my SAN that will be used to migrate the current VMs to.

I currently have a Virtual Center 1.0 server and will be building a new Virtual Center 2.0 server so it will not be an in place upgrade either.

Here is a link to a layout of what I am trying to accomplish. Any feedback is appreciated. Thanks!

-Wayne-O

<a href="http://photobucket.com" target="_blank">!http://i33.photobucket.com/albums/d96/h0stile17/VMWAREupgrade.jpg|alt=Photo Sharing and Video Hosting at Photobucket|src=http://i33.photobucket.com/albums/d96/h0stile17/VMWAREupgrade.jpg|border=0!</a>

0 Kudos
1 Solution

Accepted Solutions
Freitag
Enthusiast
Enthusiast
Jump to solution

Definitely, registering the old 2.5 in the new VC2 and doing the migration ist the best option that worked for us.

Otherwise you have too much manuell work on command line and coping.

View solution in original post

0 Kudos
5 Replies
soleblazer
Hot Shot
Hot Shot
Jump to solution

You would have to add the 2.5 hosts into the new 2.0.1 virtual center, then you could use dmotion to migrate. The ESX server is going to have to see the old luns as well as the new ones.

Should work, I would run your plan by vmware just to make 100%.

Freitag
Enthusiast
Enthusiast
Jump to solution

Definitely, registering the old 2.5 in the new VC2 and doing the migration ist the best option that worked for us.

Otherwise you have too much manuell work on command line and coping.

0 Kudos
Rob_Bohmann1
Expert
Expert
Jump to solution

Sounds like you are using the migration strategy, meaning running parallel environments and migrating individual vms from the 2.x environment to your 3.x environment. This is what we did and we are still in the process of these migrations. So we are running a VC 1.3 server to manage our 2.5 environment and a 2.0.x server to manage our 3.0.x environment. At some point we will fold all our remaining 2.5 servers into our VC 2 server and retire our 1.3 VC server, but with firewall rules, stability concerns of VC 2 (so far so good with patch 2), etc we are holding off for now.

With fewer guests and hosts you could just bring up a VC 2 server and setup your new environment. No need to move your SQL database if you do not want the performance data. Your new ESX 3/VC2 config will be stored in the new database ont eh new server.

Depending on your migration strategy, you may not even need the old VC server, once you are comfortable with the new one (use patch 2).

If you are going to use VC 2 to manage your migrations (Dmotion or cold migration), then you might just want to keep the old VC around until you are through with the migrations.

Wayne-O
Contributor
Contributor
Jump to solution

Thanks for the responses that you gave me. My main question is answered and thats great!

I'm still a little sketchy on the dmotion tool and I'm reading up on it today but I might opt for a cold migration. Having said that:

I may not use dmotion since I can buy some downtime. I plan on copying the .vmdk files between the LUNS. Is this what you mean by cold migration?

THANKS AGAIN!

0 Kudos
Rob_Bohmann1
Expert
Expert
Jump to solution

Yes cold migration is using the migration menu when the vm is powered off. This is how we migrated our Novell servers and a few others that we were unsuccessful using our other methods. We have not used Dmotion, though we may try that with future migrations.

After the migration you upgrade the virtual hardware, change vswitch if necessary, boot it up and install the tools.

0 Kudos