VMware Cloud Community
theblackknight
Enthusiast
Enthusiast
Jump to solution

Best way to move VM from an old Blade environment to a NEW one

So this is my chance to really do it right this time. I'm San Antonio and we have all our VM's on an older blade environment.

Now I have a new C-class blades and want to figure out the best way of moving VM's from the old env. to the new one. The older blades are running ESX 3.0 and the new ones are running ESX 3.5

How should I attack this move? So far I've brought up a new VC server and added some of the new blades to the new cluster.

Reply
0 Kudos
1 Solution

Accepted Solutions
mike_laspina
Champion
Champion
Jump to solution

It depends on if you need to retain security and other settings and cannot tolerate down time.

I needed to keep the VM's online for the migrations that I have performed.

I also upgraded and virtualized the VC to ease the pain in every migration case. This is handy since you just migrate it as well.

I have also performed the import method, but I prefer not. They both work and I prefer the less disruptive method if possible.

Keep in mind that upgrading the VC also upgrade the management agents on each host - not a issue if your 3.0.2 is up to date on the old system.

http://blog.laspina.ca/ vExpert 2009

View solution in original post

Reply
0 Kudos
21 Replies
RParker
Immortal
Immortal
Jump to solution

Migrate from the VI Client will move the files and vmdk files to a new environment piece of cake. Or you can use VM Converter, does the same thing but it's a copy. Or you can copy the entire folder using the datastores in a VI Client, or you can copy the datastore folder to a another drive/machine and move it from there to the new datastore if the blades don't have direct connection.

You have many easy options to accomplish this.

Reply
0 Kudos
weinstein5
Immortal
Immortal
Jump to solution

The easiest way - assuming compatible CPUs and they all see the same shared sotrage - if vMotion them form the old blad to the new blade - and when you opportunity for a reboot update vmware tools. If the CPUs are not compatible then you can cold migrate - migrating the VMs when powered off this will also give you the opportunity to move storage if you would like -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
Reply
0 Kudos
JasonVmware
Enthusiast
Enthusiast
Jump to solution

If it is an entire blade migration meaning a new blade enclosure and a new SAN keep in mind storage Vmotion if you have to move the acutal VM's off an old Shared Storage location to a new Shared Storage location. If this is not the case the other 2 posts had many great solutions to your migration.

Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

Sorry, I should have been a little more clear.

This is a entirely differrent environment with new SAN and new blades using HP Virtual Connect. So I'm thinking I have to create a cluster in the NEW environment and call it "Old blade env" then add the old blade servers and then from there Vmotion them to the new blades, does that sound correct?

I dont think I'll have any CPU incompatibility issues...

Reply
0 Kudos
weinstein5
Immortal
Immortal
Jump to solution

In that case, if the VMs can have no down time then you will need to use Storage vMotion - if you can have down time I would suggest powering off the VMs and cold migrating which also allow you to move form one SAN to the other -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
Reply
0 Kudos
JasonVmware
Enthusiast
Enthusiast
Jump to solution

If I understand you correctly you have an old Blade system which is:

A blade enclosure

X number of Blades

Switches

SAN - of some sorts

Running ESX on the blades

and now you have a new Blade system which is an all new:

Blade Enclosure

X number of blades

Switches

New SAN

and you want to migrate your current ESX enviroment over onto the new hardware leaving the old hardware to be decommisioned correct ?

If this is the case I would setup the new SAN on the new Blade system and install ESX 3.5 on the new blades. Once you have the new system up and running tie it into your Virtual Center. Then if you have Storage Vmotion I would storage Vmotion the Vm's from the old SAN to the new SAN. Then you could Vmotion the Vm's over to run on the new hardware. Remeber Vmotion only moves or tells which ESX server will be running the VM however the acutally files are still on the old SAN. Storage Vmotion acutally moves the files from one SAN to another.

Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

Thanks guys, that was really helpful and yes Jason you're correct with the environments I currently have.

One last question:

So right now I have two totally seperate ESX \ SAN environments. I have seperate VC servers. VC1 is managing the old blade ESX hosts that are still running ESX 3.0.2 . VC2 is up on totally new hardware and right now it's connected to NEW ESX hosts running ESX 3.5 on embedded USB.

Are you suggesting that when Im ready to start migrating from the old env. to the new , that I add the NEW ESX 3.5 blades to the existing VC1 server, and then move the VM's that way? I could create a new cluster and call it "New Blades" and then vmotion\storage vmotion from the old env to the new, does that sound right?

Thanks again!

Reply
0 Kudos
mike_laspina
Champion
Champion
Jump to solution

Hi,

Do you need to keep the VC user security settings intact?

Are both SAN's visible to both Blade systems.

In order to move the VM's to the new system hardware you must manage the ESX hosts with the same VC.

You can add a new VC but you will have to either restore the DB to it and then add the new hosts to it ( this would allow you to drag and drop the defunct VM DB definitions to the new hosts) lot's of down time required to do that and it's not the optimum method.

You can manually import the VM's to the new VC which will lose some elements like any VC object level security settings, stats, audit trails etc.

Both SAN's must be available on at least one of the Blades in each system to move them over.

svMotion will be required as well as vMotion.

Regards,

Mike

http://blog.laspina.ca/ vExpert 2009
Reply
0 Kudos
JasonVmware
Enthusiast
Enthusiast
Jump to solution

Couldn't he hook up 1 of the blades to both SANs then Storage Vmotion his Vm's off the old SAN to the new SAN then manually import the VM's into the new VC2.5 which would interm lose object level security settings, stats, audit trails ect. Once that was done he could then Vmotion over the Vm's to the new blades in the new Blade center?

mike_laspina
Champion
Champion
Jump to solution

Yes. That works, the second Blade connection is not required. The wording in the earlier post is not clear.

http://blog.laspina.ca/ vExpert 2009
Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

Guys, thanks for all the great tips.

Mike, do you feel your instructions in your second to last post are my best and most painless solution?

Reply
0 Kudos
mike_laspina
Champion
Champion
Jump to solution

It depends on if you need to retain security and other settings and cannot tolerate down time.

I needed to keep the VM's online for the migrations that I have performed.

I also upgraded and virtualized the VC to ease the pain in every migration case. This is handy since you just migrate it as well.

I have also performed the import method, but I prefer not. They both work and I prefer the less disruptive method if possible.

Keep in mind that upgrading the VC also upgrade the management agents on each host - not a issue if your 3.0.2 is up to date on the old system.

http://blog.laspina.ca/ vExpert 2009
Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

Guys, this is even going to be easier...

We've decided to use the existing SAN that is connected to the old blade environment. So now that I already have a new VC server connected to the new environment, should I just connect one of the new blades to the old VC server and then vmotion and storagevmotion the VM off of the old blades?

We also do not need to keep an audit trail or permissions of the old VC...

Reply
0 Kudos
mike_laspina
Champion
Champion
Jump to solution

Do you want the end result to be everything running on the new VC?

Are you OK with the down time?

http://blog.laspina.ca/ vExpert 2009
theblackknight
Enthusiast
Enthusiast
Jump to solution

Thanks again Mike!

Yes, the end goal is to have everything running from the new VC server. Retaining permissions on the old VC server is not needed.

Yes, down time is fine. Plan on moving servers during the weekends

Reply
0 Kudos
mike_laspina
Champion
Champion
Jump to solution

Ok,

Then the lowest risk and least disruptive will be to connect the old blade up to the new SAN and cold clone or svMotion the VM's over to the new storage using the old VC then import them into the new VC.

http://blog.laspina.ca/ vExpert 2009
Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

Thanks Mike AGAIN!

So they've decided to use the same SAN and NOT purchase a new SAN. So at this point I just plan on adding a couple of the NEW blades to the old VC server and then vmotioning to the new blades. Not sure if they want to create new LUNS, but I might try to get them to do that and svmotion the VM's too...

Sounds like the right thing to do?

Reply
0 Kudos
mike_laspina
Champion
Champion
Jump to solution

What are the stake holders trying to accomplish? More processing power and a current VMware version?

http://blog.laspina.ca/ vExpert 2009
Reply
0 Kudos
theblackknight
Enthusiast
Enthusiast
Jump to solution

More processing power and a current VMware version is exactly what theyre trying to do. Better C class blades instead of the old p class

Reply
0 Kudos