Moving forward with a bit of a value add article and still tying into the previous article about guest creation in XenServer, this article will approach the concept of Physical to Virtual (P2V) migration within a XenServer environment.
Update: In May 2016, Citrix released the new version of the XenServer 7 platform. For installation follow: Fresh Installation of XenServer 7.
The process of moving a physical server to a virtual server is sadly poorly documented in XenServer. In the past there have been tools that did the work for the administrator but as of XenServer 6.5 those tools appear to no longer be apart of the XenServer installer.
This article will go through the process of taking a disk image with a utility known as Clonezilla, a fantastic open source project for disk/partition imaging. The image of this server will be stored to a Samba server on the network and then a new virtual guest will be created on the XenServer system.
This new guest will obviously not have an operating system and will be setup to PXE boot to Clonezilla so that the image can be pulled from the Samba server and placed on a newly created virtual hard disk (VDI).
- XenServer 6.5
- Clonezilla Live – Imaging software
- PXE boot server with Clonezilla PXE bootable – http://clonezilla.org/livepxe.php
- Samba Server – Enough storage to store the physical guest’s image
This article will focus on the actual migration of a physical server rather than all of the intricate details about how to setup a Samba and PXE boot system and as such it will be assumed that the user already has the ability to PXE boot Clonezilla from a local PXE server.
Imaging the Physical Server
1. The first part of this process is the act of actually imaging the physical server. This will be accomplished by PXE booting Clonezilla Live but can be done using Clonezilla live via a USB or CD-ROM. When Clonezilla finishes booting, the screen will wait to determine what the next step is to Select “Start_Clonezilla”...
2. Selecting ‘Start_Clonezilla’ will prompt for all the necessary configurations rather than a shell environment. The next screen will ask for the imaging mode. For this physical to virtual migration the server’s entire disk is being moved to a virtual system and as such ‘device-image’ needs to be selected.
3. The next screen will ask where to save the image of the server. This article is going to be using a Samba share on another networked server.
4. Continuing to the next screen, Clonezilla will now prompt for the credentials to access the Samba share. Be sure to enter the IP address of the server or if DNS is functioning properly, the fully qualified hostname of the the server can be used instead.
5. The next screen asks for the Samba domain. If one exists enter it here but most systems don’t require it and hitting enter will go to the next screen.
6. The next step is to enter a valid SAMBA user for the particular share. Make sure that this user can log into the share normally. Clonezilla isn’t always clear as to authentication errors and if the user is already a known valid user, it will make troubleshooting simpler.
7. The next step is to specify the name of the SAMBA share. The default share name is “images” but environments vary. Be sure to place the appropriate share name in the following prompt.
8. Clonezilla will now ask for the security mode to use. Select ‘auto’ unless there is specific reason to use ‘ntlm’ in the environment.
9. Finally, Clonezilla will prompt for the Samba user’s password to access the share. The command line will follow normal Linux password entry in regards to not displaying anything while the password is being typed but the password is still being entered.
10. After typing the password for the Samba share, hit enter. Clonezilla will attempt to contact the Samba server and mount the Samba share. If Clonezilla is unsuccessful, it will display an error, otherwise a successful connection will result in the following screen.
If this screen is presented, then Clonezilla has successfully mounted the SAMBA share and the imaging process/configuration can continue. It never hurts to confirm that the SAMBA server also ‘sees’ the connection as well. The following command can be issued on the Samba server to ensure that Clonezilla is indeed connected.
# lsof -i :445 | grep -i established
11. The next process is to configure the imaging of this particular server. Clonezilla has two modes; Beginner and Expert. This guide will simply use ‘Beginner’ as it will provide all the necessary options for the imaging process.
12. The next step asks what Clonezilla should take an image of on this particular system. Since the entire server needs to be virtualized, ‘savedisk’ will be selected to include all partitions on the system.
Note: Ensure that the Samba share has enough space to store the ENTIRE disk! Clonezilla will do some compression but it is better to ensure the space exists BEFORE cloning.
13. Moving forward, the image will need to be given a name on the following menu prompt.
14. Once a name has been provided, Clonezilla will ask which disk (if multiple exist) should be imaged. In this example, Clonezilla will see the particular RAID controller of this server and report the size of the disk. In this case, the reported size is 146GB.
Note: Again, make sure that the Samba share has enough space for the imaging process! Clonezilla will do some compression but better safe than sorry.
15. The next step is something relatively new to Clonezilla and it is the ability to repair filesystems while the imaging is taking place. The filesystems supported by this feature are the same ones normally supported by the Linux ‘fsck’ utility.
This check isn’t mandatory but could help prevent a bad image. Skip the check if this option is not desired.
16. The next screen is used to check to ensure that the image is restorable after the image has been taken. It is suggested that this be done to help ensure a good image the first time through. This will add some time to the imaging process though if the system being imaged is large.
17. After hitting ‘Ok’ to the check saved image prompt, Clonezilla will begin the initial configuration and preparations for imaging. The imaging process hasn’t started yet though! When all the checks are done, Clonezilla will prompt one last time to verify that all parameters are correct and ask to begin the imaging process.
18. After confirming that all the settings are confirmed, Clonezilla will start the imaging process and provide some insight into the status.
19. This screen will gradually fill up with red indicating the progress of the imaging. If instructed, Clonezilla will check the saved image immediately after taking the image. Once Clonezilla has finished, it will provide instructions on how to continue.
This is a great sign that the image was likely taken successfully and should be ready to be moved to the virtual guest within XenServer.
5 thoughts on “XenServer Physical to Virtual Migration – Part 6”
When restoring to Xenserver the message “target partition is smaller than the source” is displayed even when you turn off checking the partition table.
Not even sure how that makes sense when I’m restoring to a larger vDisk in Xenserver than the source Hard drive that was cloned.
XenServer is not an option to migrate PHYSICAL TO VIRTUAL… not while this loooooooong list of steps is required.
Have you seen how to migrate a PHY machine in VMWARE ?
In Oracle VirtualBox you can use vmware procedure and just import results!
This tutorial is lengthy due to the fact that it assumes zero knowledge of the process. If the reader is already familiar with Clonezilla and the processes involved, this article could have been reduced to about 3 paragraphs.
XenServer also has tool known as XenConvert which allows administrators to make quick virtual machines out of Windows physical hosts but again this article was doing a P2V migration on a Linux physical server (XenConvert is a windows only tool).
any possible procedure to monitor xenserver performance in cacti
I don’t have a specific write up for that. I do know that they can be added to Nagios but it is technically considered a non-supported modification according to Citrix. I can add the topic to a list of future articles for this XenServer series!