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

    lost access to vm

    Scheduled Pinned Locked Moved Compute
    3 Posts 2 Posters 301 Views 2 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.
    • B Online
      bigdweeb
      last edited by

      I have 3 NUCs in a pool, and a TrueNAS system serving NFS for a couple VMs. One of those VMs is my XOA server. I recently applied an available patch for TrueNAS but forgot to power down the XOA server beforehand. Afterwards I saw the filesystem on the Debian guest was read-only and realized what had happened.

      I tried to resolve this by powering down the VM, but I was only able to do this by forcing the power off. I brought the VM back up and I can no longer ping it. I've tried everything I can think of, including restarting one of the hosts in the pool and restarting the XOA VM on that host in case the issue was the host NFS mount. None of this has worked. Any ideas on how to get this back up and running?

      AtaxyaNetworkA 1 Reply Last reply Reply Quote 0
      • AtaxyaNetworkA Online
        AtaxyaNetwork Ambassador @bigdweeb
        last edited by

        @bigdweeb Hi !

        I think the quicker way to be back on your feet it's to redeploy a XOA from scratch, and then import your XO config backup in setting -> XO config

        1 Reply Last reply Reply Quote 0
        • B Online
          bigdweeb
          last edited by

          Ok, I was able to fix this. I migrated it to the pool master on the cli. I don't think this was necessary in hindsight but I just wanted to be sure I knew where it was running. I then brought up xo-lite in Chrome on the pool master. At that point I could view the VM in the embedded console. It turned out that the root partition had errors on it and was stuck in Initramfs waiting for fsck to be run. Once I repaired the errors with fsck, the VM booted and I'm back in business.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post