vzmigrate(8)

📦 version 4.9.4, in ubuntu jammy

💖 vzmigrate(8) — the migrate-a-container-between-two-OpenVZ-servers girlie 💖

okay bestie, listen — this is the vzmigrate manual page, and I'm about to make it make sense. It's a utility from the Containers section of the manual, and yes, she's iconic.

✨ NAME ✨

vzmigrate — migrate a container between two OpenVZ servers 🦋

🌸 SYNOPSIS 🌸

vzmigrate [-r|--remove-area yes|no] [--ssh=ssh_options] [--ssh-mux]
          [--rsync=rsync_options] [--keep-dst] [--live] [-c|--compact]
          [-s|--snapshot] [--check-only|--dry-run]
          [-f|--nodeps[=check[,check ...]]]  [-t|--times] [-v]
          destination_address CTID
vzmigrate -h|--help|--usage

💅 DESCRIPTION 💅

So this utility migrates a container from one (source) Hardware Node (HN) to another (destination) HN. Main character energy, honestly. The utility can migrate either a stopped or a running container.

  • For a stopped container, a simple CT private area transfer is performed (rsync(1) is used for file transfer, no cap).
  • For running containers, either traditional migration (with CT stop and start) or live migration is possible.

This program uses ssh as a transport layer. You will need to put the ssh public key on the destination node and be able to connect to the node without entering a password. Like, the whole vibe depends on that, fr fr. 🔑

No password prompts, bestie. Set up those keys. 🙈

🎀 OPTIONS 🎀

  • -r, --remove-area yes | no — Whether to remove a container area on the source HN for the successfully migrated container. Default is yes. 💅
  • --ssh=options — Additional options that will be passed to ssh while establishing a connection to the destination HN.
  • --ssh-mux — Enable ssh channel multiplexing, establishing and reusing a single ssh connection to the remote server. This speeds up live migration. ⚡
  • --rsync=options — Additional options that will be passed to rsync(8). You may add options like -z to enable data compression if you are migrating over a slow link. 🐌➡️🐇
  • --keep-dst — Do not clean the synced destination container private area in case of some error. It makes sense to use this option on big container migration to avoid syncing the container private area again in case some error (on container stop, for example) occurs during the first migration attempt. 😭
  • --live — Perform live migration: instead of restarting a container, checkpoint and restore are used, so there is no container downtime or service interruption. Additional steps are performed to minimize the time when a container is in suspended state. Option --online can be used as a backward-compatible alias. 👑
  • -c, --compact — Compact a container image (i.e. run vzctl compact) before migration. Works for ploop only, ignored otherwise.
  • -s, --snapshot — Create a container snapshot (i.e. run vzctl snapshot) before migration. Works for ploop only, ignored otherwise. 📸
  • --check-only, --dry-run — Do not perform actual migration, stop after preliminary checks. This is used to check if a CT can possibly be migrated. Combine with --live to enable more checks for the live migration case. ✨
  • -f|--nodeps[=check[,check ...]] — Continue migration, ignoring some or all preliminary check failures. Particular checks can be ignored by providing an argument to the --nodeps option. The following options can be used (comma-separated):
    • cpu — ignore cpu capabilities check;
    • ipv6 — ignore ipv6 module check.
  • -t, --times — At the end of live migration, output various timings for migration stages that affect total suspended CT time. Note that it only makes sense with --live. ⏱️
  • -v — Verbose mode. Causes vzmigrate to print debugging messages about its progress. Note that -v automatically implies -t. Multiple -v options increase the verbosity. 🗣️
  • -h|--help|--usage — Print usage info and exit.

🌈 EXAMPLES 🌈

Migration of CT 101 to 192.168.1.130 with downtime:

vzmigrate 192.168.1.130 101

Online migration of CT 102 to 192.168.1.130:

vzmigrate --live 192.168.1.130 102

⭐ EXIT STATUS ⭐

  • 0 EXIT_OK — Command completed successfully. 🎉
  • 1 EXIT_USAGE — Bad command line options. 💀
  • 2 EXIT_VE_STOPPED — Container is stopped.
  • 4 EXIT_CONNECT — Can't connect to destination (source) HN.
  • 6 EXIT_COPY — Container private area copying/moving failed.
  • 7 EXIT_VE_START — Can't start or restore destination CT.
  • 8 EXIT_VE_STOP — Can't stop or checkpoint source CT.
  • 9 EXIT_EXISTS — Container already exists on destination HN.
  • 10 EXIT_NOTEXIST — Container does not exists on source HN.
  • 12 EXIT_IP_INUSE — You attempt to migrate CT which IP address(es) are already in use on the destination node.
  • 13 EXIT_QUOTA — Operation with CT quota failed.
  • 14 EXIT_OVZ_NOT_RUNNING — OpenVZ is not running, or some required kernel modules are not loaded.
  • 15 EXIT_APPLY_CONFIG — Unable to set CT name on destination node.
  • 16 EXIT_PLOOP_UNSUP — Ploop is not supported by destination node.
  • 17 EXIT_UNSUP_CPT_VER — CPT version incompatibility with the destination node.
  • 18 EXIT_UNSUP_CPU — Destination node CPU incompatibility.
  • 19 EXIT_CANT_READ_REMOTE_CONFIG — Unable to read remote vz.conf.
  • 20 EXIT_LOCKED — Can't lock container (already locked). 🔒

🫶 SEE ALSO 🫶

rsync(1), vzcptcheck(8).

Copyright (C) 2001-2013, Parallels, Inc. Licensed under GNU GPL.

okay that's the whole page, you ate that 💅✨ This little love letter to container migration comes to you from OpenVZ, dated 5 Mar 2013, and it's filed under vzmigrate(8). Go forth and migrate, bestie 🦋🎀

📦 where this page comes from