XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Unexpected VM autostart behavior on pool reboot

    Scheduled Pinned Locked Moved Management
    1 Posts 1 Posters 116 Views 1 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C Offline
      CodeMercenary
      last edited by

      I want to make sure it's not my expectations that are off.

      I'm running XO from source and it's up to date, currently commit 0603b.

      I came in on a Sunday because there were 44 patches released for xcp-ng. I did the pool update so it updated all three hosts in my pool (Pool Master, Server A and Server B). Then I shut down all the VMs except the one VM running XO. The VM running XO is not on the Pool Master, it's on Server B. I do not have shared storage so I did not want to do a rolling pool reboot.

      I rebooted Pool Master. When it came back up and the VMs it ran started to come up, I rebooted Server A. Then I switched to an XO instance (also from source and also current) that isn't running on any xcp host and I used it to shut down the XO instance running on Server B. Soon after I did that, two of the VMs on Server B booted back up. Both of those VMs are set to auto-start.

      First question: Did those VMs likely start because the pool master had restarted so it was dutifully restarting the auto-start VMs that weren't running? Or maybe the pool master reboot caused Server B's toolstack to restart which auto-started the VMs?

      Then I shut those auto-started VMs down again then waited for the XO instance on Server B to shut down, it was taking quite a while for some reason. Then using the separate XO instance I rebooted Server B.

      After Server B booted up, none of the three VMs with auto-start set started automatically. I thought maybe there was a delay for some reason so I waited about 5 minutes but those VMs didn't start.

      Second question: Is that expected behavior because the pool master is really in charge of restarting VMs or was it because I had manually shut them down before the reboot so they were trying to maintain that same state?

      In retrospect I think I should have used the non-xcp-hosted instance of XO to do all of this stuff so I could have shut down all the VMs then performed a pool reboot without it trying to manually migrate a VM between machines. The all three hosts would have rebooted at the same time and maybe that would have been better.

      I have a fairly small infrastructure so I manage that kind of stuff manually and a migration for the remaining VM would have taken a long time. I think this is only my second or third time to patch xcp so I'm still learning the best way to handle it.

      1 Reply Last reply Reply Quote 0

      Hello! It looks like you're interested in this conversation, but you don't have an account yet.

      Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

      With your input, this post could be even better 💗

      Register Login
      • First post
        Last post