I would greatly appreciate any help. I did some research before posing but my situation might be different and found little on this particular scenario. Is it possible to move a virtualized DC with exchange from one old VM to a new VM? Would like to find any best practices on moving them across without any issues. The old DC and exchange will be demoted when done. Much appreciated.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DC and exchange virtualization 1
- Thread starter joblack23
- Start date
Can you be a little more detailed as to what you mean by an "Old VM" and "New VM"? If you are asking if you can migrate a VM from vSphere 4.1 (old) to 5.1 (newer) than yes, that is a very simple process. If you are asking if you can migrate a VM from GSX (oldest) to 5.5 (newest) well that will be a little more challenging, but there are ways.
- Thread starter
- #3
Thank you for your reply. Currently we have an old Dell poweredge with VM5.1 installed that has been in operation for a very long time. I need to move the AD/exchange from this server to a different server which will be also virtualized. Thanks for any info you might be able to provide.
-
1
- #4
vSphere 5.1 is just barely a year old. If you are moving the VM from 5.1 to 5.5, which was just released about a month ago, and I assume you do not have vCenter and are just using stand alone servers, than your best method would probably be to schedule an outage and shutdown the VM. Browse the datastore on the host and download the folder containing all the VM parts to a USB drive and then uploading it to the new server and then right click your vmx file and select add to inventory.
That being said, I suspect there is more to the story about what you are trying to achieve and what versions of the VMware hypervisor you are running.
That being said, I suspect there is more to the story about what you are trying to achieve and what versions of the VMware hypervisor you are running.
- Thread starter
- #5
Thanks cabraun,
Yes, I will be going to 5.5. 5.1 accepts very little ram. I can't scheduled shutdown as it would be too long. I plan on integrating 2013 into the existing 2010 and move mailboxes across. What I am trying to achieve is to remove the old and aged hardware with very little downtime without f#%^^ing up. Thanks again for your info.
Yes, I will be going to 5.5. 5.1 accepts very little ram. I can't scheduled shutdown as it would be too long. I plan on integrating 2013 into the existing 2010 and move mailboxes across. What I am trying to achieve is to remove the old and aged hardware with very little downtime without f#%^^ing up. Thanks again for your info.
ArizonaGeek
IS-IT--Management
You're better off creating a new virtual server, install AD and Exchange, copy roles, schema, and mailboxes. Then demote the old server. You're going to have far fewer issues. Make sure you read the 5.5 release notes before you install it. There are some major changes that will affect you.
The biggest questions I have, are you running vCenter? Are your hosts connected to a SAN or direct attached storage?
The answer is always "PEBKAC!
The biggest questions I have, are you running vCenter? Are your hosts connected to a SAN or direct attached storage?
The answer is always "PEBKAC!
There have been a couple of inquiries to the existence of vCenter in this thread with no confirmation, so the community is left to assume that the free hypervisor is the one that is in play here. vCenter is being asked about because it makes a HUGE difference in what you can do what you are stuck with.
To achieve the "very little downtime without f#%^^ing up", follow Arizona's advice. Leave the source VM on the old hardware and migrating the data to a destination VM on new hardware. No matter what, you are going to follow a migration process if your goal is to implement Exchange 2013 and upgrade from Exchange 2010. So you can just do the migration (like Arizona is suggesting), or you can continue on the original path you posted about and try to move the VM it's self to new hardware before migrating. With out the use of vCenter, you will be stuck with a powered off simple file transfer of the VM. I would suggest using Converted for this, but you can follow Cabraun's advice and copy the files directly from the datastore. To know how long it will take, first do a test copy of something (and ISO file or other VM). Note the size, copy the file, time it, do the math. If a 1GB file take 5minutes to transfer, then a typical DC that should be over 40GB would take about 3 hours. It is not exact, but it does give you a guestimate of time and the window you will need to ask for downtime. Again, I suggest using Converter to transfer the VM to a new host.
BTW, before you even try to move the VM, make sure no SnapShots exist. You can not move a VM that has snapshots. If you access the datastores directly, you will successfully move the VM and blow it up at the same time. Converter will tell you NO and not let you move it if there are snapshots.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
To achieve the "very little downtime without f#%^^ing up", follow Arizona's advice. Leave the source VM on the old hardware and migrating the data to a destination VM on new hardware. No matter what, you are going to follow a migration process if your goal is to implement Exchange 2013 and upgrade from Exchange 2010. So you can just do the migration (like Arizona is suggesting), or you can continue on the original path you posted about and try to move the VM it's self to new hardware before migrating. With out the use of vCenter, you will be stuck with a powered off simple file transfer of the VM. I would suggest using Converted for this, but you can follow Cabraun's advice and copy the files directly from the datastore. To know how long it will take, first do a test copy of something (and ISO file or other VM). Note the size, copy the file, time it, do the math. If a 1GB file take 5minutes to transfer, then a typical DC that should be over 40GB would take about 3 hours. It is not exact, but it does give you a guestimate of time and the window you will need to ask for downtime. Again, I suggest using Converter to transfer the VM to a new host.
BTW, before you even try to move the VM, make sure no SnapShots exist. You can not move a VM that has snapshots. If you access the datastores directly, you will successfully move the VM and blow it up at the same time. Converter will tell you NO and not let you move it if there are snapshots.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
If you are snapshoting your DC you are just asking for trouble. I set all my virtualized DCs vmdk's to be independant persistent and therefore un-snapshotable. I don't even want anyone to possibly even consider the idea of snapping a DC and then reverting back at some point later. Talk about a quick way to make your life miserable.
I would also never use converter or any other tool to P2V or V2V as DC. Way too much trouble than it is worth. If the DC is already as a VM and you do not have the ability to vMotion, than either shut it down and copy it as I previously described or do as ArizonaGeek described and build a new VM and DC promo from scratch, transfer the FSMO roles, install Exchange and move the mailboxes (I hung up my Exchange admin hat a long time ago so I could not begin to tell you how to go about that or how to move the mailboxes etc.) Then dcpromo your old DC to demote it and then clean up any Exchange stuff and shut the old server down.
All that being said, I am still not convinced that you know for sure what version of VMware you are even running. You say "Old VM to New VM" and you say "old Dell poweredge with VM5.1 installed that has been in operation for a very long time". Certainly vSphere 5.1 has not been in operation for a "very long time". It's like 14 months old at the most. Hardly a "Very long time" in the world of virtualization and hypervisors.
You've got several people here that are very happy to help you out, but you really need to give us a better idea of exactly what we are working with so that we can give you the best advice possible.
I would also never use converter or any other tool to P2V or V2V as DC. Way too much trouble than it is worth. If the DC is already as a VM and you do not have the ability to vMotion, than either shut it down and copy it as I previously described or do as ArizonaGeek described and build a new VM and DC promo from scratch, transfer the FSMO roles, install Exchange and move the mailboxes (I hung up my Exchange admin hat a long time ago so I could not begin to tell you how to go about that or how to move the mailboxes etc.) Then dcpromo your old DC to demote it and then clean up any Exchange stuff and shut the old server down.
All that being said, I am still not convinced that you know for sure what version of VMware you are even running. You say "Old VM to New VM" and you say "old Dell poweredge with VM5.1 installed that has been in operation for a very long time". Certainly vSphere 5.1 has not been in operation for a "very long time". It's like 14 months old at the most. Hardly a "Very long time" in the world of virtualization and hypervisors.
You've got several people here that are very happy to help you out, but you really need to give us a better idea of exactly what we are working with so that we can give you the best advice possible.
- Thread starter
- #9
Hi cabraun. Hope you had a good Thanksgiving. Let me try again. Old configuration: VMware 5.1 (Free version limited to 24G) with Exchange 2010 and DC on the same old box (about 7 years old and confirmed by the receipts of the hardware) inherited setup.
New config: Just installed (VMWare 5.5 with vCenter installed with two ESX hosts and SAS storage). I am going to migrate Exchange 2010 to 2013. I agree with you and was never in my mind to take snapshot of the DC. I need my exchange on HA which brings me to another question: Should I use VM Fault Tolerance or do the exchange cluster? I need to have exchange up at all time. The FT looks like a good setup but don't know yet how VM will bring the database up (second partition where database will be stored).
Thanks again.
New config: Just installed (VMWare 5.5 with vCenter installed with two ESX hosts and SAS storage). I am going to migrate Exchange 2010 to 2013. I agree with you and was never in my mind to take snapshot of the DC. I need my exchange on HA which brings me to another question: Should I use VM Fault Tolerance or do the exchange cluster? I need to have exchange up at all time. The FT looks like a good setup but don't know yet how VM will bring the database up (second partition where database will be stored).
Thanks again.
You may not want to use FT with Exchange. It still only supports uni processor configuration, no SMP yet. MS Clustering would be the most inexpensive supported solution for what you want. There are other options, I my self really like Neverfail's solutions. Works very well, and is what I use to get around the FT limitation.
VMWare has said FT SMP will be supported in future version of vSphere.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
VMWare has said FT SMP will be supported in future version of vSphere.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
- Thread starter
- #11
Thanks for your help Brent,
I am facing with a difficult situation and the reason I was looking at FT. I posted a similar info request in the Exchange forum. I did try clustering and as long as i don't make E partition available to the cluster, everything works fine. As soon as I do that, I get 2 pages of all kinds of error. After cracking the books and google, i found somewhere that SAS is not supported in DAG. HP support thinks that VM does a better job at making exchange HA as suppose to MS cluster.
Thanks.
I am facing with a difficult situation and the reason I was looking at FT. I posted a similar info request in the Exchange forum. I did try clustering and as long as i don't make E partition available to the cluster, everything works fine. As soon as I do that, I get 2 pages of all kinds of error. After cracking the books and google, i found somewhere that SAS is not supported in DAG. HP support thinks that VM does a better job at making exchange HA as suppose to MS cluster.
Thanks.
VMware HA does great with your typical application / web / file / print etc servers. You lose a host, within 60-90 seconds the VMs that were on the lost host are running again on a different host, provided you are N+1 or better. Database servers like Exchange, SQL, Oracle etc will not be as tolerant of a host failure, but with a little work you will get them back up and running reasonably quickly.
As already mentioned, FT will only work with uniprocessor currently and all FT will protect you against is a host failure. A failure in the VM protected by FT, will be replicated to the 2nd VM immediately therefore if you are trying to protect against a bad patch or something, FT will give you nothing. As soon as your source VM dies or BSOD's so will your secondary VM.
Again, I am not an Exchange admin. I hung that hat up shortly after we migrated from 5.5 to 2003. So I am not familiar with all the current Exchange resiliency options available today. But I can tell you that if you must have five 9's or better of uptime, even if FT supported SMP, you would still not be guaranteed that. Physical servers with multiple, well distributed DAGs is probably a much better option.
As already mentioned, FT will only work with uniprocessor currently and all FT will protect you against is a host failure. A failure in the VM protected by FT, will be replicated to the 2nd VM immediately therefore if you are trying to protect against a bad patch or something, FT will give you nothing. As soon as your source VM dies or BSOD's so will your secondary VM.
Again, I am not an Exchange admin. I hung that hat up shortly after we migrated from 5.5 to 2003. So I am not familiar with all the current Exchange resiliency options available today. But I can tell you that if you must have five 9's or better of uptime, even if FT supported SMP, you would still not be guaranteed that. Physical servers with multiple, well distributed DAGs is probably a much better option.
ArizonaGeek
IS-IT--Management
2010 and 2013 handle crashes much easier these days than the older versions. Our Exchange is on a VM and we're looking to upgrade to 2013 very soon (probably next week) and we've never had an issue with it. We run a single machine for about 200 users. We actually bought another license to run a DAG when we upgrade but the more we're reading and talking with others who've done the upgrade I think we're sticking with the one server. Now with that, we run two DC's separate from Exchange and I wrote a rule in VMWare that they are never to be on the same physical host. We use Commvault as a back up of Exchange and AD. Commvault skips the VMDK's of Exchange and AD. In the event of a crash, I would never restore the VM. I would do a complete re-install of the VM. We use backups in case someone deletes a user and we need that user back.
Joblack23, you're still better off creating a new machine in your VM cluster and then migrating the data over to it. You'll have no downtime this way. I can't think of any other way to move to the new environment that doesn't require at least some downtime.
If you can squeeze a few hours of downtime like on a Saturday night or something, I would suggest an upgrade the old server to ESXi 5.5 using a trial license, connect it to your cluster and migrate all the servers to the new environment. That wouldn't be too bad and would buy you time to get your upgrade going.
The other option is what Brent said, copy the files from one environment to the other with the Exchange server powered off. Where you will have problems is if you have more than one DC, you risk one of the DC's tombstoning and then you're going to have problems.
Build the new server.
Good luck!
The answer is always "PEBKAC!
Joblack23, you're still better off creating a new machine in your VM cluster and then migrating the data over to it. You'll have no downtime this way. I can't think of any other way to move to the new environment that doesn't require at least some downtime.
If you can squeeze a few hours of downtime like on a Saturday night or something, I would suggest an upgrade the old server to ESXi 5.5 using a trial license, connect it to your cluster and migrate all the servers to the new environment. That wouldn't be too bad and would buy you time to get your upgrade going.
The other option is what Brent said, copy the files from one environment to the other with the Exchange server powered off. Where you will have problems is if you have more than one DC, you risk one of the DC's tombstoning and then you're going to have problems.
Build the new server.
Good luck!
The answer is always "PEBKAC!
- Thread starter
- #14
Thanks for your post. I was not worry about the server migration. I can muster a few hours. My problem is after i get it in the production it would be difficult to have any failure. We are running sensitive equipment relying on alerts. The request was to have full redundancy of some sort (after the migration). I would prefer VM HA and agreed with everyone's post above not going to multiple servers and ultimately Microsoft Cluster. I didn't understand which server are not suppose to run on the same host (your DC's or exchange?)
Thanks again for your post. very helpfull.
Thanks again for your post. very helpfull.
He is talking about DC's
Never have two virtual DC's running on the same host at the same time.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
Never have two virtual DC's running on the same host at the same time.
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Senior Network Engineer
Keep IT Simple[/color red] Novell Platinum Partner Microsoft Gold Partner
VMWare Enterprise Partner Citrix Gold Partner
- Status
