I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original.
Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one.
But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate.
So I remembered DRBD was supposed to be used for replication.
But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too.
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
on 6/8/2012 9:33 AM Emmanuel Noobadmin spake the following:
I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original.
Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one.
But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate.
So I remembered DRBD was supposed to be used for replication.
But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too.
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
You could always rsync the old server to the new one... a few runs will get 99% of the files, and a quick run after the shutdown can get the rest... Have a tar file ready of the needed config changes ready and untar it and start up the new system...
On Fri, Jun 8, 2012 at 12:04 PM, Scott Silva ssilva@sgvwater.com wrote:
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
You could always rsync the old server to the new one... a few runs will get 99% of the files, and a quick run after the shutdown can get the rest... Have a tar file ready of the needed config changes ready and untar it and start up the new system...
An interesting variation on this is to use 'ReaR' to back up and restore the machine, essentially cloning it but give the copy a different IP address as you bring it up. Then when the clone is close to ready to take over, shut down your apps for the time it takes a final rsync to fix up the differences (in the data areas only - avoid /etc/, (etc.), then switch the IP.
ReaR is in active development now and is very usable. It is a set of shell scripts designed to run live backups that are capable of restoring to bare metal. It makes a new boot iso with tools from the running system to reconstruct the filesystem (including lvm/raid, etc.) and restore on top of that. Several backup methods are supported but tar to an nfs location is probably the easiest to set up. With a small amount of extra work you can tweak the filesystem layout, etc. if you don't want an exact clone. With hardware differences you might need to tweak modules and build a new initrd, too. ReaR is packaged in EPEL as rear.
On 08/06/2012 17:33, Emmanuel Noobadmin wrote:
I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original.
Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one.
But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate.
So I remembered DRBD was supposed to be used for replication.
But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too.
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
You don't say what virtualisation platform you are using is, but if it's VMware, then you can use VMware converter to do the migration. This can, if you want, clone the physical computer into VMware, shut down the physical computer and bring up the new virtual instance. All whilst the physical remained up. I've used it for a few Linux boxes, where I've wanted a quick dev version of an existing server and its been fine.
I guess, you could try pulling it into an ESXi host, and then exporting that in a format whatever virtualisation program it is you use supports...
Regards,
Tris
************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation *************************************************************
I'm using KVM so didn't have the tool.
While Les' suggestion looked like it was going to be pretty useful for a variety of backup/restore situations, I didn't know if I had the time to go through the docs and get things working in time.
So in the end I went with the repeated rSync method Scott mentioned. The advantage is, I also went and made the new system C6 first, then rsync the necessary data files instead of leaving it still on C5.
Thankfully nothing broke, well, except SSL certs for some reason but that was easily fixed once people started complaining.
On 6/13/12, Tris Hoar trishoar@bgfl.org wrote:
On 08/06/2012 17:33, Emmanuel Noobadmin wrote:
I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original.
Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one.
But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate.
So I remembered DRBD was supposed to be used for replication.
But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too.
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
You don't say what virtualisation platform you are using is, but if it's VMware, then you can use VMware converter to do the migration. This can, if you want, clone the physical computer into VMware, shut down the physical computer and bring up the new virtual instance. All whilst the physical remained up. I've used it for a few Linux boxes, where I've wanted a quick dev version of an existing server and its been fine.
I guess, you could try pulling it into an ESXi host, and then exporting that in a format whatever virtualisation program it is you use supports...
Regards,
Tris
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
How about using one of the backup tools to image the server? We use Symantec System Recovery and image all the disks. We then have the option of restoring to different hardware (physical or virtual) which works very well. There's a 60-day evaluation period. http://www.symantec.com/products/trialware.jsp?pcid=pcat_business_cont&p...
--Russell
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Emmanuel Noobadmin Sent: Thursday, 14 June 2012 2:36 a.m. To: CentOS mailing list Subject: Re: [CentOS] Best way to duplicate a live Centos 5 server?
I'm using KVM so didn't have the tool.
While Les' suggestion looked like it was going to be pretty useful for a variety of backup/restore situations, I didn't know if I had the time to go through the docs and get things working in time.
So in the end I went with the repeated rSync method Scott mentioned. The advantage is, I also went and made the new system C6 first, then rsync the necessary data files instead of leaving it still on C5.
Thankfully nothing broke, well, except SSL certs for some reason but that was easily fixed once people started complaining.
On 6/13/12, Tris Hoar trishoar@bgfl.org wrote:
On 08/06/2012 17:33, Emmanuel Noobadmin wrote:
I've got a CentOS 5 server that I want to migrate over into a virtualized instance. The problem is I need to minimize downtime so was trying to figure out a way to "live" clone the original.
Initially, I thought I could do this via exporting an iSCSI target from the virtual host, create a MD raid 1 array on the C5 server, wait for it to sync, then shutdown the physical server and switch to the virtual one.
But after getting iSCSI working... I realize I could not create a md device on a mounted disk. Unfortunately this old C5 wasn't setup with md raid 1 originally so I can't just add a the iSCSI target as an additional member for a triplicate.
So I remembered DRBD was supposed to be used for replication.
But after getting things set up, running the drbd-admin create-md command gave me this scary warning it will destroy data on the disk. Apparently because drbd writes meta data to the drive. So that appears to be a no go too.
Am I missing something glaringly obvious here, or is the only way I'm going be able to migrate is to shutdown the C5 server for a few hours while duping the old drives? Would greatly appreciate any pointers how best to do this.
You don't say what virtualisation platform you are using is, but if it's VMware, then you can use VMware converter to do the migration. This can, if you want, clone the physical computer into VMware, shut down the physical computer and bring up the new virtual instance. All whilst the physical remained up. I've used it for a few Linux boxes, where I've wanted a quick dev version of an existing server and its been fine.
I guess, you could try pulling it into an ESXi host, and then exporting that in a format whatever virtualisation program it is you use supports...
Regards,
Tris
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster@bgfl.org
The views expressed within this email are those of the individual, and not necessarily those of the organisation
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================
On 6/14/12, Smithies, Russell Russell.Smithies@agresearch.co.nz wrote:
How about using one of the backup tools to image the server? We use Symantec System Recovery and image all the disks. We then have the option of restoring to different hardware (physical or virtual) which works very well. There's a 60-day evaluation period. http://www.symantec.com/products/trialware.jsp?pcid=pcat_business_cont&p...
Not an option for me unfortunately, the only Windows systems on location are at best Win7 Home Premium and SSR requires a Win Server OS according to their page.
On Thu, Jun 14, 2012 at 2:32 AM, Emmanuel Noobadmin centos.admin@gmail.com wrote:
On 6/14/12, Smithies, Russell Russell.Smithies@agresearch.co.nz wrote:
How about using one of the backup tools to image the server? We use Symantec System Recovery and image all the disks. We then have the option of restoring to different hardware (physical or virtual) which works very well. There's a 60-day evaluation period. http://www.symantec.com/products/trialware.jsp?pcid=pcat_business_cont&p...
Not an option for me unfortunately, the only Windows systems on location are at best Win7 Home Premium and SSR requires a Win Server OS according to their page.
Clonezilla-live is good for straight image copies, but you have to shut down the source while taking the copy and it doesn't do raid. It does handle most filesystems including windows and knows enough to only copy the used blocks.
ReaR will make the copy with the source running and handles most linux disk layouts. There is not much documentation at this point and there are a lot of options, but if you have an NFS share to hold the intermediate backup copy it only takes a couple of lines in a conf file to set it up. However, since it is designed for backup/restore, the default is for the restore iso to use the same IP as the source which is awkward for live cloning. You can work around that but should probably try a test system first. It is definitely worth looking at as a simple backup solution in any case. If the target hardware is different, both clonezilla and rear may require you to build a new initrd with appropriate disk drivers included.
Using the VMware converter tool (free) might work. I've done it with windows, but so far it has not worked with the disk layouts on the linux systems I have tried. When it works, it works very well - and you could probably do additional conversions from the vmware image.
-
Emmanuel Noobadmin -
Les Mikesell -
Scott Silva -
Smithies, Russell -
Tris Hoar