Migrating openVZ containers

From Notes_Wiki
Revision as of 07:45, 25 March 2013 by Saurabh (talk | contribs) (Created page with "<yambe:breadcrumb>OpenvZ|OpenvZ</yambe:breadcrumb> =Migrating openVZ containers= Migrating openVZ containers is very convenient. First a public-key based authentication for ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

<yambe:breadcrumb>OpenvZ|OpenvZ</yambe:breadcrumb>

Migrating openVZ containers

Migrating openVZ containers is very convenient. First a public-key based authentication for root access from one machine to another should be established. Then following syntax can be used to migrate containers live from one base machine to another

vzmigrate -v --live <target-machine> <CID>

where:

  • <target-machine> is the machine where container should be migrated from current machine
  • <CID> is the ID of the container to be migrated.

Note that if container uses bridged networking instead of usual venet interfaces then the container interface (veth<CID>.<n>) has to be added on appropriate bridge on destination as soon as migration is complete.

-v option prints various informative messages including time-stamps. Live migration of one 3.1GB container over 1000mbps network generated following statistics:

One way:

        Suspend + Dump:   1.14
        Copy dump file:   1.34
          Second rsync:   3.91
       2nd level quota:   0.41
       Undump + Resume:   0.89
                        ------
  Total suspended time:   7.69

Other way:

        Suspend + Dump:   0.62
        Copy dump file:   1.08
          Second rsync:   3.48
       2nd level quota:   0.82
       Undump + Resume:   0.69
                        ------
  Total suspended time:   6.69

A continuous ping was kept to container being migrated live. It was verified that only 7/8 ping packets were dropped during migration. All the services were running fine after migrating container twice (both times live) from one machine to another.


vzmigrate also has important switches like -r to indicate whether local data should be removed after successful migration. Further it also has switches like --keep-dest to indicate not to remove target folders in case of unsuccessful migrations. This allows future migrations tries to work quickly as rsync finishes faster. Refer to 'man vzmigrate' for more details.


<yambe:breadcrumb>OpenvZ|OpenvZ</yambe:breadcrumb>