@dinhngtu

I am not sure what i am missing but the VM is stuck in drive not booting pass the BIOs or UEFI mode as if it don't know what to do...

• I convert qcow2 to vhd on windows with the cmd you provide after downloading it from https://cdimage.debian.org/images/cloud/trixie/20260129-2372/
• Import the converted VHD into XO
• Attach to empty Debian VM, set to boot from hard drive and convert to template (UEFI mode)(I also try BIOs)

I think I am missing something. Do you have a complete "#cloud-config" I can paste in and check to make sure it's working. I would expect the console to display something during boot up. I never done cloud-init before... so really curious.

I tried debian 12 and 13 both getting stuck on same place.
In UEFI below (BIOs stuck similar case but different screen):

Hello All,

This issue seem to completely go away on a older branch/tag if i build it from below for XO:
xo-lite-v0.17.0

So the issue I would think is coming from the newer version of XO. Not sure best way to test this. So I am going back to an older commit.

If anyone has any suggestion I can try helping as its an annoying issue.

@Pilow my is SMB too but it saw the issue. I use windows to login and drag all iso into a new created folder in the iso folder and drag it back out delete the newly created folder and all my iso is back to normal. It was a quick thing.

@Pilow Check the iso does it have a snapshot icon in the drive?

Next it show up fine until u want to create a vm in the new vm pg it think they are snapshots and you cant select the ISOs. This is when the problem arise.

Yep the dev here are super reaponsive. Have been a long term user and here and love their support . I mostly just been playing with things and learn so much by tinkering

@Pilow now that you mention that everything is seen as snapshot i remember all my ISO are seen as snapshots too... so most iso cannot be mounted until i drag them in a folder then put them back in same folder so XO could reprocess all the iso correctly. This might be a related issue to all the snapshots for the VMs.

@Pilow Lol glad I was able to help. Its only if you have a few VMs having hundreds will be a nightmare... giod luck to those that has that issue. In the meantime I will use the method I mention for now.

@Pilow Does disk show up after you do the snapshot? If it is able to do the snapshot there is a high chance it can boot up. So try booting up (and check for disk) and shut it down and do the snapshot at that time if the disk show up.

It helps to boot up on the old v5 commit and check from that side too if you have both copy before the commit update.

Yep I can confirm that snapshot doesn't always work. But using the older v5 that used to work before the update does get it showing up on the newer v5 commit if I go through whole snapshot, revert, etc. one of those case work.

It will be a nightmare if I have to do all 286 VMs...

slowing verifying if its going down the countdown... luckily most of them are related so it's not too bad.

Hello All,

Found some roundabout solutions you may want to try:
https://xcp-ng.org/forum/post/101370

So far a few solutions for me has been:

• Revert the SNAPSHOT and it magically find the disk...
• Create a new SNAPSHOT and it magically find the disk... (esp. if you don't have a snapshot on some VMs like me)
• SNAPSHOT sometime works but still missing disk so boot it up and disk show up
• Some claim migrating the VM works... (migration fail for me as it can't find the disk lol...)

There should be better solutions as sometime I want to keep old snapshots. Still testing other methods... as my old XO still finds everything... even though its loaded with the same CONFIG FILES and same XCP-ng machine metadata.

@Pilow Ok I can confirm that this is extremely like this issue with the disks disappearing but still boot up and run fine lol

No disk on XO v5

Disk show up on v6

Fixed it by REVERTING the SNAPSHOT....

Seem others was able to migrate the VM out and back in to fix it as well which seem ridiculously time consuming lol . I might try that for those that have no snapshot as its a lost cost...

I think I am going to try wiping out everything and do a clean install and see what happen but will take a bit of time and report back...

@anthoineb Seem it was never installed as far as i can tell as i tried running it and nothing processed:

Don't even have a /etc/yum.repos.d but do have a yum directory.

@anthoineb Is there a cmd to check on the xcp-ng to see if "qcow2" was ever installed? Likely I either never did or installed and forgot about it but I did ready about it previously but don't remember if I acted on it or not.

Really appreciate your help !

This is the SMlog on one of the machine. I cannot rule out qcow2 but I definitely upgrade it from back in the early release of 8.3a and 8.3b. If I did use qcow2 I probably install and forgot about it... but its definitely affecting every VMs on the XO (commit b89c2)

SMlog.txt
SMlog2.txt

I have also notice that all the VMs on the XO (commit b89c2) run on debian 12 all have missing disks.

FROM:
Xen Orchestra, commit 0a28a (Pre Update on XO disk available still as long as I use the old GUI)

TO:
Xen Orchestra, commit b89c2 (Post Update on XO missing Disks)
Surprisingly the VM still loads and run without the disks but extremely confusing...

Snapshots on it fail for both XO commit version with the following error might be a related issue too which I just notice now:

vm.revert
{
  "snapshot": "d0734350-87a4-97f8-97dc-9d9ac5c24b5d"
}
{
  "code": "INVALID_VALUE",
  "params": [
    "snapshot_metadata:HVM__boot_policy",
    "null"
  ],
  "task": {
    "uuid": "058f49ac-82cc-a49b-eaaf-d20e4a319432",
    "name_label": "Async.VM.revert",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20260106T02:19:26Z",
    "finished": "20260106T02:19:26Z",
    "status": "failure",
    "resident_on": "OpaqueRef:ea86afa1-6562-0eac-79fc-75be4ce1cb2a",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "INVALID_VALUE",
      "snapshot_metadata:HVM__boot_policy",
      "null"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 432))((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 428))((process xapi)(filename ocaml/xapi/xapi_vm_snapshot.ml)(line 471))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2334))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2292))((process xapi)(filename ocaml/xapi/rbac.ml)(line 188))((process xapi)(filename ocaml/xapi/rbac.ml)(line 197))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 77)))"
  },
  "message": "INVALID_VALUE(snapshot_metadata:HVM__boot_policy, null)",
  "name": "XapiError",
  "stack": "XapiError: INVALID_VALUE(snapshot_metadata:HVM__boot_policy, null)
    at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/index.mjs:1078:24)
    at file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/index.mjs:1112:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/index.mjs:1102:12)
    at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202512260040/packages/xen-api/index.mjs:1275:14)"
}

Version:
XO:
From:
Xen Orchestra, commit 0a28a
To:
Xen Orchestra, commit b89c2

XCP-ng:
From:
8.3 loaded from ISO: xcp-ng-8.3.0-rc1.iso
To:
8.3 loaded from ISO: xcp-ng-8.3.0-20250606.iso
and haven't update it since until there is a major version release.

Issue:
Orphan VDIs in XO show health problem for my "base copy" snapshots as it can't find the VDIs anymore for some reason?
Note: I have clone of before the XO update and have both XO commit 0a28a and commit b89c2 running that's why I was able to take snapshots below so not everything is all lost and done for...

From: (before update)

To: (after update)

Is it ok to delete it seem like I can't delete it... in fear of breaking all my VMs.

@DustinB Totally in line with you but in the meantime since i figure this cli out too now i am totally ok with what i have currently and its not too pressing.

@olivierlambert
I think JanP is on point here. I just test it for auto power on and it works like a charm.

To close the loop if your team use the toggle for Auto power on to show and hide a new added feature called "Auto power on delay (seconds)" on this gui this will satisfy many people trying to find the "Auto power on delay (seconds)" a new feature request. Many people have been getting confused with "Start delay (seconds)" for "Auto power on delay (seconds)". So adding this will be a huge delight and since this is an existing cli in xcp-ng hopefully its simple enough.

// This will update delay to 30 sec
xe vm-param-set other-config:auto_poweron_delay=30 uuid=<VM_UUID>
// This will turn off the delay
xe vm-param-set other-config:auto_poweron_delay= uuid=<VM_UUID>
// This will leave delay ON but set time to 0 sec. Do NOTE that "0" set delay to 0 while a blank "" like above remove auto power on delay.
xe vm-param-set other-config:auto_poweron_delay= uuid=<VM_UUID>

I just expecting the "Auto power on delay (seconds)" to look like "Start delay (seconds)" gui wise but just under the "Auto power on" to make it obvious enough for people hopefully. Til this day never really understand the "Start delay (seconds)" lol even after using XCP-ng for testing for the last 2 years at least.

Thanks all! Please like this if it helps anyone else as it's a backup cli solution until the gui is hopefully updated with this feature.

@Vinylrider Lol i like this getting stuff done customized haha! Great pictures.