Grace period for migrated containers

Discussion in 'General Questions' started by SteveITS, Feb 12, 2016.

  1. SteveITS

    SteveITS Mega Poster

    Messages:
    211
    We were adding RAM to some hardware nodes today and I started by migrating the containers to a different node. One migrated and the rest failed, with individual messages:

    Operation with the Container "containername" is finished with errors: Can not migrate: exec vzmsrc failed [7680] : locking 3405136 Shared disk detected /vz/private/3405136/root.hdd The destination node license does not allow to increase the number of Containers: limit=4, use=4 License check failed: The destination node license does not allow to increase the number of Containers: limit=4, use=4 Can't move/copy CT#3405136 -> CT#3405136, [], [] : License check failed: The destination node license does not allow to increase the number of Containers: limit=4, use=4 Connection to destination node (74.122.194.5) is successfully established Moving/copying CT#3405136 -> CT#3405136, [], [] ... Checking bindmounts Check cluster ID Source and target CT private resides on the same shared partition Checking license restrictions .

    I thought there was a grace period to allow for this? Or is that just for migrations that happen via shaman, if a hardware node fails?

    I upgraded our node's license, and can downgrade when we're done, but I was a bit confused.
     
  2. Pavel

    Pavel A.I. Auto-Responder Odin Team

    Messages:
    416
    Hello Steve,

    There is a built-in check in vzmigrate which should stop people form making this mistake accidentally.
    However, you can always skip this "check" if you know what you're doing.
    Take a look at the following option of vzmigrate (snippet taken from man vzmigrate):
    Code:
           -f,         --nodeps[=[all][,cpu_check][,disk_space][,technologies][,license][,rate][,bindmount][,template_area_sync][,cpt_image_version][,capabili-
           ties][,kernel_modules]]
                  Ignore an absence of required package sets on destination node.  To prevent CT against errors in filesystem due to absent template files,  it
                  will not be started on destination node after migration and must be started manually.
                  Additional parameters:
                  all - as is -f.
                  cpu_check - to pass check of the cpu capabilities.
                  disk_space - to pass check of the disk usage.
                  technologies - to pass check of the used technologies.
                  license - to pass check of the license.
                  rate - to pass check of the RATE config parameters.
                  bindmount - to pass check of the external bind mounts in config.
    
    Thus, using "--nodeps=license" option for vzmigrate you can avoid this.
     
  3. SteveITS

    SteveITS Mega Poster

    Messages:
    211
    OK, thanks. In PVA is that the option, "Force the migration. Ignore possible conflicts in IP addresses or applications."? It didn't specifically mention licenses but sounds a lot like "-f". :)
     
  4. Pavel

    Pavel A.I. Auto-Responder Odin Team

    Messages:
    416
    Yes, it is :)
    vzmigrate might take "-f" to ignore all check pre-checks, and "--nodeps=..." if you want to omit some specifically.
    To my knowledge PVA only allows "-f" unfortunately.
     

Share This Page