Virtualize a Server with Minimal Downtime
After Knoppix boots, you need to partition, format and mount the new partitions for this virtual machine. Use fdisk or cfdisk from the command line to create your partitions to match your physical server. Again, you don't have to match the partition sizes exactly, as long as there is plenty of room to store all the files from the physical server. For this example, I will have a physical server with a single SCSI drive (/dev/sda) with three partitions: /dev/sda1 for root, /dev/sda2 for swap and /dev/sda3 for /home. After you create the same partitions on the virtual machine, format them with the same filesystems you use on the physical machine, create mountpoints for them and then mount them:
$ sudo mkfs -t ext3 /dev/sda1 $ sudo mkfs -t ext3 /dev/sda3 $ sudo mkswap /dev/sda2 $ sudo mkdir -p /mnt/sda1 /mnt/sda3 $ sudo mount /dev/sda1 /mnt/sda1 $ sudo mount /dev/sda3 /mnt/sda3
Now that you have created and mounted the partitions, you are ready for the first synchronization. For this to work, your virtual machine must have network access, and specifically, it needs to be able to access SSH on the physical machine. By default, Knoppix will attempt to get a DHCP lease if available, but otherwise, if your rescue disc is not able to get on the network, you need to make the necessary changes so that it can. This virtualization procedure reduces downtime by synchronizing the files twice—once while the physical server is running and once after it is off-line. The idea here is that a majority of files on most servers stay the same, at least over one or two days. If you perform the bulk of the file synchronization while the server is on-line, when you take it off-line, the final synchronization can occur much faster.
I use rsync for the synchronization, and for it to work, you need to allow (at least temporarily) for root SSH logins to occur on the physical machine. If it is disabled, edit /etc/ssh/sshd_config and change PermitRootLogin no to PermitRootLogin yes, and restart sshd. Otherwise, it will be difficult for rsync to copy all the files on the system. You will run an rsync command for each partition on the physical server, so in this example, that makes two rsync commands:
$ sudo rsync -avx --numeric-ids ↪--progress physicalhost:/ /mnt/sda1/ $ sudo rsync -avx --numeric-ids ↪--progress physicalhost:/home/ /mnt/sda3/
The rsync options I use here are chosen very deliberately, so it's worth understanding what each of them does. The -a option sets “archive mode”, which essentially turns on a number of rsync options that preserve file ownership and permissions and other settings. The -v option makes rsync provide more output about what it is doing, and the --progress argument displays a progress meter so you can keep up with how long rsync will take. The other two arguments are rather important, and if you don't use rsync regularly, you might not come across them much. The -x argument tells rsync to stick to one filesystem. This is important particularly when you back up the / partition; otherwise, rsync happily will traverse into /home or any other partitions you have and copy them all into your local /mnt/sda1 mountpoint, which probably will not have enough space to hold everything. The --numeric-ids argument sets file permissions on the destination files based on their numeric ID and not the matching user or group name. This is important as the Knoppix CD very likely has different user and group ID mappings than your server.
After these rsync commands complete, you are ready to take your physical server off-line. If you did need to schedule a maintenance window for the physical server, just leave the virtual machine running in its current state, and proceed to the next step when you are ready to take the physical machine off-line. If a number of days will pass until your maintenance window, you might want to run the above rsync commands again once you are close to the maintenance window, just so the final off-line rsync will happen more quickly.
On the Physical Server:
The last synchronization happens when the physical server is completely off-line, so you can make sure that no other files change on you. To do this, simply take a Knoppix CD (or your preferred rescue CD) to the physical machine and boot from it. All the commands you run will be from the command line, so you can boot in to Knoppix's terminal-only mode here as well. As Knoppix boots, it should detect your partitions automatically and create mountpoints under /mnt for them, but if it doesn't, just use the mkdir command to create them manually. Knoppix will not mount partitions automatically at boot, so you need to do that manually. In the case of this example, my physical server has two partitions to mount:
$ sudo mount /dev/sda1 /mnt/sda1 $ sudo mount /dev/sda3 /mnt/sda3
Now I need to set a password for the root Knoppix user and then start the SSH server on this machine so I can run the rsync:
$ sudo passwd $ sudo /etc/init.d/ssh start
Keep in mind that because I booted this machine into Knoppix, it most likely has gotten a different IP address via DHCP. Type /sbin/ifconfig to check which IP address the machine currently has, as you will need it for the final rsync.
On the Virtual Server:
You now can start the final synchronization from the virtual server. The commands are very similar to what you used before, except this time, I add the --delete option so that rsync will remove any files on the virtual machine that were deleted from the physical machine since the last time I synced. Also notice that because the physical server is now booted in to Knoppix, I have to change the directory paths and the IP address for the remote host, as they changed since I booted in to Knoppix:
$ sudo rsync -avx --numeric-ids --progress ↪--delete 192.168.1.150:/mnt/sda1/ /mnt/sda1/ $ sudo rsync -avx --numeric-ids --progress ↪--delete 192.168.1.150:/mnt/sda3/ /mnt/sda3/
These commands could take a long time or a short time, depending on how many files have changed since the last time you ran rsync. Once it completes, you are ready to perform the final finishing touches on your virtual machine before bringing it into service.
Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.
|Alice, the Turtle of the Modern Age||Mar 07, 2014|
|Using Django and MongoDB to Build a Blog||Mar 05, 2014|
|What virtualization solution do you use/manage at work?||Mar 04, 2014|
|Our Assignment||Mar 04, 2014|
|March 2014 Issue of Linux Journal: 20 Years of Linux Journal||Mar 03, 2014|
|Have Resume - Will Travel||Feb 28, 2014|
- New Storage Solution is Music to the Ears of Fast-Growing Digital Music Company
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Using Django and MongoDB to Build a Blog
- Sign Up to Win a Silicon Mechanics Swag Pack!
- New Products
- Zato—Agile ESB, SOA, REST and Cloud Integrations in Python
- You have to be careful there
2 weeks 22 hours ago
- Wonder when LJ is going to
2 weeks 1 day ago
- Puerto Rico Free Software
2 weeks 2 days ago
2 weeks 3 days ago
- I hate voice commands
2 weeks 4 days ago
- usabilty --- AGAIN with this nonsense
2 weeks 4 days ago
- Don't make excuses
2 weeks 4 days ago
- Sorry to let you know, but
2 weeks 4 days ago
- Ridiculous statement. Not a
2 weeks 5 days ago
2 weeks 5 days ago