XCP-ng

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups

    Failed to start VM

    Compute
    3
    8
    542
    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.
    • K
      kevdog last edited by

      Hi I'm running xcp-ng 8.2 and I've been doing so for a long time. Yesterday I received a notification about missing pool patches (with X0) and I installed chose the option to install the missing pool patches. In addition, I performed package upgrades of all the VMs (either apt for Ubuntu VMs or pacman for Arch VMs). One of my Arch VMs now fails to start and I'm receiving the error:

      vm.start
      {
        "id": "98a8dc5a-66f4-a475-ec2a-3de2df439629",
        "bypassMacAddressesCheck": false,
        "force": false
      }
      {
        "code": "FAILED_TO_START_EMULATOR",
        "params": [
          "OpaqueRef:d091d6c6-168a-4f6a-b365-c54cac642031",
          "domid 28",
          "QMP failure at File \"xc/device.ml\", line 3328, characters 71-78"
        ],
        "call": {
          "method": "VM.start",
          "params": [
            "OpaqueRef:d091d6c6-168a-4f6a-b365-c54cac642031",
            false,
            false
          ]
        },
        "message": "FAILED_TO_START_EMULATOR(OpaqueRef:d091d6c6-168a-4f6a-b365-c54cac642031, domid 28, QMP failure at File \"xc/device.ml\", line 3328, characters 71-78)",
        "name": "XapiError",
        "stack": "XapiError: FAILED_TO_START_EMULATOR(OpaqueRef:d091d6c6-168a-4f6a-b365-c54cac642031, domid 28, QMP failure at File \"xc/device.ml\", line 3328, characters 71-78)
          at Function.wrap (/opt/xen-orchestra/packages/xen-api/src/_XapiError.js:16:12)
          at /opt/xen-orchestra/packages/xen-api/src/transports/json-rpc.js:36:27
          at AsyncResource.runInAsyncScope (node:async_hooks:199:9)
          at cb (/opt/xen-orchestra/node_modules/bluebird/js/release/util.js:355:42)
          at tryCatcher (/opt/xen-orchestra/node_modules/bluebird/js/release/util.js:16:23)
          at Promise._settlePromiseFromHandler (/opt/xen-orchestra/node_modules/bluebird/js/release/promise.js:547:31)
          at Promise._settlePromise (/opt/xen-orchestra/node_modules/bluebird/js/release/promise.js:604:18)
          at Promise._settlePromise0 (/opt/xen-orchestra/node_modules/bluebird/js/release/promise.js:649:10)
          at Promise._settlePromises (/opt/xen-orchestra/node_modules/bluebird/js/release/promise.js:729:18)
          at _drainQueueStep (/opt/xen-orchestra/node_modules/bluebird/js/release/async.js:93:12)
          at _drainQueue (/opt/xen-orchestra/node_modules/bluebird/js/release/async.js:86:9)
          at Async._drainQueues (/opt/xen-orchestra/node_modules/bluebird/js/release/async.js:102:5)
          at Immediate.Async.drainQueues [as _onImmediate] (/opt/xen-orchestra/node_modules/bluebird/js/release/async.js:15:14)
          at processImmediate (node:internal/timers:464:21)
          at process.topLevelDomainCallback (node:domain:152:15)
          at process.callbackTrampoline (node:internal/async_hooks:128:24)"
      }
      

      I actually went through the process of restoring a delta backup of this VM, and the restored delta backup has the exact same error, so I tending to think this is a problem with the hypervisor and not the actual VM. I've seen errors similar to this listed in other posts here on the forum, however it seems invariably there are posts saying -- yea --- this error message really needs to be more specific in exposing the underlying problem. I've tried ejecting v-CDR - xe vm-cd-eject --multiple however this command didn't exactly help. I'm booting via bios.

      1 Reply Last reply Reply Quote 0
      • olivierlambert
        olivierlambert Vates 🪐 Founder & CEO 🦸 last edited by

        Hi,

        Please restart the toolstack on all your hosts, then the VM will boot. After each update, you shouldn't forget to restart the toolstack (at least) OR reboot the host.

        K 1 Reply Last reply Reply Quote 0
        • K
          kevdog @olivierlambert last edited by

          @olivierlambert
          Hey thanks a lot -- that did the trick.

          Just to be clear on my end -- when should a restart the toolstack?

          1 Reply Last reply Reply Quote 0
          • olivierlambert
            olivierlambert Vates 🪐 Founder & CEO 🦸 last edited by

            It's clearly explained in our official doc: https://xcp-ng.org/docs/updates.html#how-to-apply-the-updates

            So I don't want to answer with a simple "RTFM", but well 😄 Sometimes it's really the answer 😄

            K Danp 2 Replies Last reply Reply Quote 0
            • K
              kevdog @olivierlambert last edited by

              @olivierlambert

              I'm ok with RTFM.

              1 Reply Last reply Reply Quote 0
              • olivierlambert
                olivierlambert Vates 🪐 Founder & CEO 🦸 last edited by olivierlambert

                For your defense, if you used the Rolling pool update mechanism, you would have the same issue. We are fixing our algorithm to be sure we update and reboot hosts one by one to avoid this in the future 🙂 So XO code even missed XCP-ng doc of restarting first (host or toolstack) before moving VMs around 😆

                1 Reply Last reply Reply Quote 0
                • Danp
                  Danp Top contributor 💪 @olivierlambert last edited by

                  @olivierlambert said in Failed to start VM:

                  RTFM

                  One of my favorite saying! 😆

                  1 Reply Last reply Reply Quote 0
                  • olivierlambert
                    olivierlambert Vates 🪐 Founder & CEO 🦸 last edited by

                    I don't like to use it often, because it might also be "my fault" (bad UI, bad docs and so on). I always try to understand why you have a problem first, and how we can solve it 🙂

                    So it's not often a lack of reading the doc, but stuff you can improve on your side 🙂 And this is the spirit with XCP-ng/XO: always listen users and try to improve everyday!

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