Minimize downtime while migrating to 4.1

Discussion in 'Proxmox VE: Installation and configuration' started by datenimperator, Dec 16, 2015.

Tags:
  1. datenimperator

    Proxmox Subscriber

    Joined:
    Jun 6, 2011
    Messages:
    42
    Likes Received:
    1
    Hi,

    I'm about to migrate a Proxmox VE 3.4 host to 4.1. I'm starting with a fresh 4.1 install on separate hardware. What's the best way to migrate OpenVZ hosts with minimal downtime? I understand containers need to be stopped. So downtime needed for the migration sums up to
    1. shut down the hosts
    2. perform a full backup, writing backup data to a NFS share (5-10 GB per host)
    3. restore from that NFS share on the new host
    4. start container
    Is there a way to further reduce downtime? Regards

    Christian
     
  2. Richard

    Richard Proxmox Staff Member
    Staff Member

    Joined:
    Mar 6, 2015
    Messages:
    577
    Likes Received:
    19
    You wrote "host" - but you mean containers here, don't you?

    If so: no, that's the minimum for downtime.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Q-wulf

    Q-wulf Active Member

    Joined:
    Mar 3, 2013
    Messages:
    593
    Likes Received:
    28
    the minimum will always be the time it takes you to write a backup to shared storage and to read said backup from shared storage. There is no way around it. (unless you e.g. use HotSwapable disks and are talking a couple TB of storage that is. )

    ps.: Are you migrating openVz to LXC CT's by any chance ? I assume you did some dry runs for your different OpenVz configs ? since pve4.x release there consistently have been threads regarding "how to migrate with X exotic config"
     
  4. datenimperator

    Proxmox Subscriber

    Joined:
    Jun 6, 2011
    Messages:
    42
    Likes Received:
    1
    Yes, containers, not hosts. Sorry, my bad.
     
  5. datenimperator

    Proxmox Subscriber

    Joined:
    Jun 6, 2011
    Messages:
    42
    Likes Received:
    1
    Due to lack of appropriate testing hardware, I migrated one container to see if importing a backup works, which it did. I did not start intensive functional testing beforehand, because I assumed that Proxmox tested its release software better than I did. In particular I expected LXC to work basically like OpenVZ does: Share a kernel to have lightweight Linux containers.

    As I described in a thread named Permission error w/ sockets inside CT since migration to PVE 4.1 things turned out rather bad. In short: AppArmor and/or LXC lets UNIX sockets be created inside a container with permissions very different than before. As a result, daemons on the same container cant connect to each other, rendering services unusable. I've learned that this is a known effect (wasn't clear to me, I'm no expert in LXC no AppArmor), which I find completely unacceptable for a 4.1 release of a software product like Proxmox VE.
     
  6. Q-wulf

    Q-wulf Active Member

    Joined:
    Mar 3, 2013
    Messages:
    593
    Likes Received:
    28
    We've got a Proxmox-labCluster at work and i got a single proxmox-node at home for those pesky mandatory home office days and my personal enjoyment. I always dry-run everything that i have not at least done once as a best practice and see if it works. And i do not just mean proxmox. Especially if it has anything business critical on it. Sounds like you are (client-service equals business critical in my book). If it does not work, then you don't upgrade to a new version until you are sure it works or have a working; its that simple.

    What is acceptable or not is not for me to say, its a very very subjective topic. In any case, when ever there are some major features dropped anywhere in IT/Software, there is bound to be some rough edges and features that are different or not supported at all anymore. It's just the nature of the beast.

    I only run KVM on our servers, so i can not judge LXC/openvz migration process, sry to hear its causing issues.
     
    #6 Q-wulf, Dec 21, 2015
    Last edited: Dec 21, 2015
  7. datenimperator

    Proxmox Subscriber

    Joined:
    Jun 6, 2011
    Messages:
    42
    Likes Received:
    1
    I assume there were good reasons for Proxmox staff to drop OpenVZ in favor of LXC in PVE 4.0. Being able to run a fairly standard kernel instead of a heavily patched OpenVZ kernel might be one, I guess.

    That being said, I learned that I manually need to add a custom parameter lxc.aa_profile: unconfined to every LXC configuration in /etc/pve/lxc/*.conf because LXC conflicts with AppArmor. It's not because we're doing anything fancy here, this seems to be needed for basic services like postfix, mysql and probably anything that chroots or uses sockets. Which is most of'em, I guess.

    Bottom line(s)
    1. This should not have been like this in the first place.
    2. Then again: It should have been documented somewhere.
    3. Given that there's no UI for that: It should be.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice