Lik`s forum

[lik]

Minimum Requirements

* There should be a separate node for each entity of hyperVM such as for Master hyperVM Node a corresponding FluidVM Management Node, for a slave openvz/xen node in hyperVM a corresponding openvz/xen compute node ....
* The target FluidVM node/server should be of almost equal or greater hardware configuration.
* Free Hard disk space for the new openvz/xen node is required to be greater than that of the filesystem space occupied by the root filesystem of all the Virtual Machines present in the old hypervm node.
* Tools like ssh, tar should be installed in both hyperVM and fluidVM nodes.
* Root access to both management as well as openvz/xen nodes.
* Permission to *reset* the password of root user of the mysql database to blank. Without this permission we can't proceed anymore for migration. You can change password to your choice after migration.

Installation

Installation is as simple as copying script files, which is provided as a single tar file named migrate.tar, to any directory of your choice(say ~/fvm_migrate/) in your hyperVM master node.

Code: Select all

[hypervm-master-node]# tar -xf migrate.tar -C ~/fvm_migrate

Since FluidVM provides support for Xen and OpenVZ the script required for the migration of those nodes requires separate scripts. So after extraction to the directory while listing you will be having at least the below specific files: mgmt_migration.py, xen_migration.py, openvz_migration.py. Do this step in all hyperVM nodes which you are going to migrate.

Steps before migration

All the scripts must be run as 'root' user unless otherwise specified. Also no virtual machines(that need to be migrated), services(run on openvz/xen compute nodes by fluidvm) or any modules/services of hypervm should be running during the process of migration. Search if any of the services are running and if so stop/kill them . For hypervm

Code: Select all

[hypervm-node-1]# ps ax | grep hypervm.httpd

For FluidVM

Code: Select all

[fluidvm-node-1]# /etc/init.d/fluidvm-agent-updater stop

Now check if the management server is set to listen from all nodes not just from localhost. For that check the file '/etc/pyles/app_fluidvm/pylesSettings.py' and confirm that the 'listen_address' value is '0.0.0.0'. Set port number too if you plan a different from than the default which is 8090. After migration its recommended to change back the 'listen_address' value to '127.0.0.1' to prevent any outsider attempt to exploit the open port access.

{
'xml_rpc_port':8090,
'listen_address': '0.0.0.0'
}

You'll need to restart the FluidVM Management Server for this change to take effect

Code: Select all

/etc/init.d/vkarma stop
/etc/init.d/vkarma start

The management program needs to be running in the management server all the time during the process of migration. Please confirm that it is running before proceeding any further.

Code: Select all

[fluidvm-mgmt-node]# ps ax | grep start-pyles

Setting up public key authorization for all hyperVM nodes to fluidVM nodes

Before executing any of the scripts we extracted to ~/fvm_migrate, we have to make sure that we would be able to secure copy files from the hyperVM nodes(both types ie master and slave) to their corresponding fluidvm nodes using public key avoiding any hassle of entering password manually. For that first we need to generate a public key in the source node(a hypervm node say hypervm-node-1). Only if you don't have a public key do the commands below. Just press enter for having default values when asked for inputting any value.

Code: Select all

[hypervm-node-1]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
d6:03:89:f0:6e:bc:ec:4c:2b:ec:92:9e:08:a5:7d:c8 root@hypervm-node-1

So we have created a public key(/root/.ssh/id_rsa.pub) for secure shell operation. Now we need to add this public key to the destination node(a fluidvm node say fluidvm-node-1) for secure shell authorization through public keys.

Code: Select all

[hypervm-node-1]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@fluidvm-node-1

[lik]

In-Place Migration

Introduction

If the hyperVM slave node(source) and FluidVM node(target) are the same(ie same slave nodes for running the hypervm's and migrated FluidVM's virtual servers), the migration is termed In-place migration. People try this kind of migration either due to lack of resource availability or for a fast testing with least hassle. One bright side is you would be able to manage the migrated node using both hyperVM and FluidVM. However it is recommended that you should be using FluidVM for managing the node after migration is complete successfully. Before proceeding you should go through HyperVM Migration.

For In-place migration, only mgmt-migration.py script need to be run, that too on master node of hyperVM.

Migration on Master Node

By the below script we would be resetting the root password of MySQL database, migrating the database entries & local management files like templates... from the master node of hyperVM to the FluidVM management node. Its however *important* that the FluidVM management node should be running the FluidVM management program throughout the migration process as mentioned earlier. So now we will run the script 'mgmt-migration.py', kept in the directory '~/fvm_migrate/' of hypervm master node which we have extracted from the 'migrate.tar' tar file, as 'root' user:

Code: Select all

[hypervm-master-node]# mkdir -p ~/fvm_migrate
[hypervm-master-node]# cd ~/fvm_migrate/
[hypervm-master-node]# tar -xf migrate.tar -C ~/fvm_migrate
[hypervm-master-node]# python mgmt-migration.py
FluidVM admin's password(Warning: Password input not hidden)[admin]:
Enter the hostname/ip of fluidvm mgmt node[]: 10.10.10.41
Are you planning in-node migration(slave/compute nodes are migrated to themselves)(y/[N]): y
Do you want to change above data([Y]/n):
n

As you see, you will be asked to provide the password of FluidVM admin password, hostname or ip address of the FluidVM management node where you are migrating the hyperVM master node to, asking if you want In-place migration or not and at the end if any error in input a chance to change them. Remember that in the remote node you must be running the management program of FluidVM. After entering the ip/hostname the script will be transferring all the necessary data to the FluidVM management node. What all processes are going on will be displayed in the screen. Normally no error will happen during this procedure. As the process involves transferring root filesystem through network, the procedure take a fairly large amount of time. So be patient. If any error occurs, which would normally be displayed, fix it and start the above procedure again.

Exodus Migration


Introduction

If the hyperVM slave node(source) and fluidVM node(target) are different physical machines, the migration is termed Exodus migration. People try this kind of migration for a full fledged usage of fluidvm which would be giving maximum accessibilty and control on the node and virtual servers within. On bright side there would be no incompatibility issue as both fluidVM and hyperVM are on different systems/nodes. However the usage of seperate system demands more resources. Now before proceeding you should go through HyperVM Migration.

As said for Exodus migration, migration script(mgmt-migration.py) need to be run on master node of hyperVM as first step. Later, on all the slave nodes, execute either the openvz-migration.py or xen-migration.py depending on the hypervisor running there.

Migration on Master Node

This is the first part of the migration procedure and the rest of the migration procedure should be continued only if this executes without any exceptions/errors. By this procedure we would be resetting the root password of MySQL database, migrating the database entries & local management files like templates... from the master node of hyperVM to the fluidVM management node. It is however *important* that the fluidVM management node should be running the fluidVM management program throughout the migration process as mentioned earlier. Also the 'services' script of fluidvm should not be running in the slave/compute node having hyperVM vms from which we are migrating, though usually it won't be necessary as we won't be using same node for hyperVM and fluidVM in Exodus Migration.

Code: Select all

[fluidvm-management-node]# /etc/init.d/vkarma start
[hypervm-slave-node]# /etc/init.d/fluidvm-agent-updater stop

So now we will run the script 'mgmt-migration.py', kept in the directory '~/fvm_migrate/' of hypervm master node which we have extracted from the 'migrate.tar' tar file, as 'root' user.

Code: Select all

[hypervm-master-node]# mkdir -p ~/fvm_migrate
[hypervm-master-node]# cd ~/fvm_migrate/
[hypervm-master-node]# tar -xf migrate.tar -C ~/fvm_migrate
[hypervm-master-node]# python mgmt-migration.py
FluidVM admin's password(Warning: Password input not hidden)[admin]:
Enter the hostname/ip of fluidvm mgmt node[]: 10.10.10.42
Do you want to change above data([Y]/n):
n

As you see, you will be asked to provide the password of fluidVM admin password, hostname or ip address of the fluidVM management node where you are migrating the hyperVM master node to, asking if you want in-node migration or not and at the end if any error in input a chance to change them. Remember that in the remote node you must be running the management program of fluidVM. After entering the ip/hostname the script will be transferring all the necessary data to the fluidvm management node. What all processes are going on will be displayed in the screen. Normally no error will happen during this procedure. As the process involves transferring root filesystem through network, the procedure take a fairly large amount of time. So be patient. If any error occurs, which would normally be displayed, fix it and start the above procedure again.

Migration on Slave Nodes

This is the second and last part of the migration procedure where we will be running the hyperVM's node specific scripts depending on whether the node is xen or openvz. Though the scripts run are different the type of input required for both are the same. But before proceeding make sure the "services" script, which fluidVM wants each associated node to execute, is running in the remote/target node. This need to be done for both openvz and xen nodes.

Code: Select all

[fluidvm-node-1]# /etc/init.d/fluidvm-agent-updater start

Now after starting the "services" we need to wait for sometime so that fluidvm gathers all the required information from the node to the management node.

Migration on OpenVZ Slave Nodes

The procedure starts by executing openvz-migration.py.

Code: Select all

[hypervm-ovz-node-1]# mkdir -p ~/fvm_migrate
[hypervm-ovz-node-1]# cd ~/fvm_migrate/
[hypervm-ovz-node-1]# tar -xf migrate.tar -C ~/fvm_migrate
[hypervm-ovz-node-1]# python openvz-migration.py
FluidVM admin's password(Warning: Password input not hidden)[admin]:
Enter the ip of fluidvm mgmt node[]: 10.10.10.42
Enter the ip of the ovz-node to which to migrate[]: 10.10.20.85
Enter the ip of the local-node used in hyperVM[]: 10.10.20.82
Do you want to change above data([Y]/n):
n

Here the fluidvm management node ip/hostname is where the fluidvm management is running which was earlier(Part 1) migrated. The local-node ip/hostname is the node on which we will be executing the script having all the hyperVM's openvz VMs. The ovz-node ip/hostname represent the node to which we will be migrating all the openVZ VMs of the local node. Please note the hostname/ip provided for the slave node of hypervm(here local-node) is the same as you see in the "IP Or Hostname" field in "servers" section of HyperVM.

Migration on Xen Slave Nodes

Since xen vms are using lvm for root and swap disks the migration is a little complex compared to that of openvz vms and thereby would take more time though that also depends on the count of VMs. Before execution of the script make sure that the "services" scripts, which fluidVM wants each node to execute, is running in the remote/target node as mentioned earlier. The migration script, xen-migration.py interface remains the same as that of OpenVZ. Please note the hostname/ip provided for the slave node of hypervm(here local-node) is the same as you see in the "IP Or Hostname" field in "servers" section of HyperVM.

Code: Select all

[hypervm-xen-node-1]# mkdir -p ~/fvm_migrate
[hypervm-xen-node-1]# cd ~/fvm_migrate/
[hypervm-xen-node-1]# tar -xf migrate.tar -C ~/fvm_migrate
[hypervm-xen-node-1]# python xen-migration.py
FluidVM admin's password(Warning: Password input not hidden)[admin]:
Enter the ip of fluidvm mgmt node[]: 10.10.10.42
Enter the ip of the xen-node to which to migrate[]: 10.10.20.91
Enter the ip of the local-node used in hyperVM[]: 10.10.20.84
Do you want to change above data([Y]/n):
n

[lik]

http://community.fluidvm.com/index.php?topic=76.0