Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat. The purpose of this eBook is to educate the reader about ransomware attacks.
Course Of The Month
4 days, 19 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
VMWare migrating to new server room?
Posted on 2011-03-21
Just wondering what the easiest way to migrate an ESX server with site services from one building to another with no downtime. (buildings connected by fiber)
We have two ESX servers in a cluster. I'm guessing I can vmotion VMs off of one ESX server, then physically carry it over to the new site and bring it up, then VMotion the others over? The VMs are 40gigs minimum. At what point would this not make sense and at what bandwidth? They will be connected via Fiber to 1gb switches, but the buildings are still a mile apart I think.
Please assist.
Thanks EE
We have two ESX servers in a cluster. I'm guessing I can vmotion VMs off of one ESX server, then physically carry it over to the new site and bring it up, then VMotion the others over? The VMs are 40gigs minimum. At what point would this not make sense and at what bandwidth? They will be connected via Fiber to 1gb switches, but the buildings are still a mile apart I think.
Please assist.
Thanks EE
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
2
5 Comments
If both ESX hosts share the same storage, then yes, you can VMotion the VMs on the current host to the host in the new location. If they do not share the same storage, you can use Converter to move/convert the VMs (do a V2V basically) to the new host/location. If you have VMotion capability then there would be no downtime. If not, using Converter would keep your source VM live while conversion is taking place, but once the conversion is done, you will need to power down the source, then power on the converted VM.
~coolsport00
~coolsport00
Active 2 days ago
Ok cool, yes we have VMotion license and shared storage.
Why is shared storage necessary? Couldn't I move the datastore (vmdk) of the virtual machine from the source SAN to the local ESX box once moved to the new site? We won't have SANs in both locations so the SAN will also be moving.
Get it? To reiterate, two ESX servers with 400GB local storage are both connected to a SAN (SUMO) where the datastores reside.
The plan would be to move one ESX server to the new TCF, then VMotion the datastores to the ESX server local storage, then physicaly move the SAN and second ESX server to the new TCF, then vmotion everything back from local storage to SAN.
Would this work?
Why is shared storage necessary? Couldn't I move the datastore (vmdk) of the virtual machine from the source SAN to the local ESX box once moved to the new site? We won't have SANs in both locations so the SAN will also be moving.
Get it? To reiterate, two ESX servers with 400GB local storage are both connected to a SAN (SUMO) where the datastores reside.
The plan would be to move one ESX server to the new TCF, then VMotion the datastores to the ESX server local storage, then physicaly move the SAN and second ESX server to the new TCF, then vmotion everything back from local storage to SAN.
Would this work?
Shared Storage is a requirement to have for (specifically) Storage VMotion (sVMotion) amongst all ESX hosts in a VMware Datacenter (not necessarily phys datacenter...but a vCenter Datacenter object). And you need to have Ent licensing, as well. So, if you have storage that can be seen by both ESX hosts, you can migrate/sVMotion the VMs to your off-site host ("host2") while 'live' (still powered on). VMotion on the other hand simply allows you to move your VMs while live to a new host, not new storage. You can still migrate a VM to new storage at anytime regardless of your licensing (as long as you have vCenter Server), but the VM just needs to be powered down.
So, if I understand you correctly, this is my suggestion - you have 2 hosts in different phys locations; "host1" at current site you wanna move and "host2" at destination site, and both are connected to the *same* SAN, correct? You wanna move "host1", as well as the SAN, to the new location/destination where "host2" is, correct? So, what I recommend is VMotioning the VMs on "host1" to "host2". Then simply sVMotion the VMs to local storage on "host2". After all VMs are off "host1" and the SAN, power down both "host1" and your SAN and move them as needed. Once both "host1" and the SAN are up in the new location, and the SAN is connected to both hosts again, you can VMotion the VMs you want on "host1" back to it and sVMotion them to the SAN if you like.
Hope that helps.
Regards,
~coolsport00
So, if I understand you correctly, this is my suggestion - you have 2 hosts in different phys locations; "host1" at current site you wanna move and "host2" at destination site, and both are connected to the *same* SAN, correct? You wanna move "host1", as well as the SAN, to the new location/destination where "host2" is, correct? So, what I recommend is VMotioning the VMs on "host1" to "host2". Then simply sVMotion the VMs to local storage on "host2". After all VMs are off "host1" and the SAN, power down both "host1" and your SAN and move them as needed. Once both "host1" and the SAN are up in the new location, and the SAN is connected to both hosts again, you can VMotion the VMs you want on "host1" back to it and sVMotion them to the SAN if you like.
Hope that helps.
Regards,
~coolsport00
Active 2 days ago
Yes that is what I asked whether or not I could do. So we both agree.
One more thing, about the migration od datastore, I have migrated the entire datastore without the VM being turned off, and takes a long long time. 4-12 hours per machine and the VM was on. Unless I am missing what you are saying and am going crazy? Please correct me or that statement if you will, it's making me a little nervous. I don't want any gotchas or "oh that's what he meant"
Thanks again
One more thing, about the migration od datastore, I have migrated the entire datastore without the VM being turned off, and takes a long long time. 4-12 hours per machine and the VM was on. Unless I am missing what you are saying and am going crazy? Please correct me or that statement if you will, it's making me a little nervous. I don't want any gotchas or "oh that's what he meant"
Thanks again
Yeah...I just had to get my brain wrapped around everything...sorry :P
Yes, for a sVMotion...(migrating VM to a different datastore), the process could indeed take a while. And, depending on the VM size, and WAN bandwidth, that sounds about right (4-12hrs). What happens during a sVMotion is a snap is taken of the VM; the orig VM and it's files are then transferred to the new datastore; any changes made to the VM will be added to the snap file; upon completion of the transfer of files, the data in the snap will then be written to the orig VM vmdk and the snap deleted. So, that process could take a while to complete.
~coolsport00
Yes, for a sVMotion...(migrating VM to a different datastore), the process could indeed take a while. And, depending on the VM size, and WAN bandwidth, that sounds about right (4-12hrs). What happens during a sVMotion is a snap is taken of the VM; the orig VM and it's files are then transferred to the new datastore; any changes made to the VM will be added to the snap file; upon completion of the transfer of files, the data in the snap will then be written to the orig VM vmdk and the snap deleted. So, that process could take a while to complete.
~coolsport00
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Will try to explain how to use the VMware feature TAGs in the VMs and create Veeam Backup Jobs using TAGs. Since this article is too long, I will create second article for the Veeam tasks.
This article outlines why you need to choose a backup solution that protects your entire environment – including your VMware ESXi and Microsoft Hyper-V virtualization hosts – not just your virtual machines.
Teach the user how to configure vSphere clusters to support the VMware FT feature
Open vSphere Web Client: Verify vSphere HA is enabled: Verify netowrking for vMotion and FT Logging is in place or create it: Turn On FT for a virtual machine: Verify …
Teach the user how to install log collectors and how to configure ESXi 5.5 for remote logging
Open console session and mount vCenter Server installer: Install vSphere Core Dump Collector: Install vSphere Syslog Collector: Open vSphere Client: Config…
Suggested Courses
Course of the Month4 days, 19 hours left to enroll
688 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.