This was ultimately traced to a currupted metadata on the VHD and to a stuck tapdisk process on the host where the VM was running.
Solved thanks to a very persistent member of support. Thanks Jon!
This was ultimately traced to a currupted metadata on the VHD and to a stuck tapdisk process on the host where the VM was running.
Solved thanks to a very persistent member of support. Thanks Jon!
@Danp Mmmm no. Just checked. It's not there though.
Hi,
Was migrating one of our important VMs from a problematic pool to a new "clean" one. However, it failed half way through. I believe this is the correct log entry:
vm.migrate
{
"vm": "b60762de-c222-2911-e18b-488c56e21646",
"mapVifsNetworks": {
"bc94ab3c-20ed-b188-5010-a4a9ea7c9196": "c0bd86ce-faaa-4fd9-a702-c093c3f5c326"
},
"migrationNetwork": "c0bd86ce-faaa-4fd9-a702-c093c3f5c326",
"sr": "cb379d8c-0226-49aa-327f-00d12f63f43e",
"targetHost": "cebfed0d-8a78-4d69-8817-2b9a4c81c59b"
}
{
"code": 21,
"data": {
"objectId": "b60762de-c222-2911-e18b-488c56e21646",
"code": "MIRROR_FAILED"
},
"message": "operation failed",
"name": "XoError",
"stack": "XoError: operation failed
at operationFailed (/usr/local/lib/node_modules/xo-server/node_modules/xo-common/src/api-errors.js:21:32)
at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:561:15
at Xo.migrate (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:547:3)
at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:401:20)"
}
After that, VM locked up and I restarted it, but it failed to boot with the error below:
vm.start
{
"id": "b60762de-c222-2911-e18b-488c56e21646",
"bypassMacAddressesCheck": false,
"force": false
}
{
"code": "SR_BACKEND_FAILURE_46",
"params": [
"",
"The VDI is not available [opterr=VDI 28aaf3f0-447c-44a2-ad8e-e7c159b41ef8 not detached cleanly]",
""
],
"call": {
"method": "VM.start",
"params": [
"OpaqueRef:aee5c672-049e-4533-81a2-7ac0163d818c",
false,
false
]
},
"message": "SR_BACKEND_FAILURE_46(, The VDI is not available [opterr=VDI 28aaf3f0-447c-44a2-ad8e-e7c159b41ef8 not detached cleanly], )",
"name": "XapiError",
"stack": "XapiError: SR_BACKEND_FAILURE_46(, The VDI is not available [opterr=VDI 28aaf3f0-447c-44a2-ad8e-e7c159b41ef8 not detached cleanly], )
at Function.wrap (/usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/_XapiError.js:16:12)
at /usr/local/lib/node_modules/xo-server/node_modules/xen-api/src/transports/json-rpc.js:35:21"
}
XOA still lists the disk as present along with the other two.
I found this post, but don't want to make everything worse: https://xcp-ng.org/forum/topic/4614/help-with-vdi-cant-start-a-vm-the-vdi-is-not-available-not-detached-cleanly/5?_=1684488720911
VM details:
[11:34 xcp-ng-hv04 ~]# xe vm-list name-label=VM-Navision
uuid ( RO) : b60762de-c222-2911-e18b-488c56e21646
name-label ( RW): VM-Navision
power-state ( RO): running
[11:35 xcp-ng-hv04 ~]# xe vdi-list uuid=28aaf3f0-447c-44a2-ad8e-e7c159b41ef8
uuid ( RO) : 28aaf3f0-447c-44a2-ad8e-e7c159b41ef8
name-label ( RW): VM-Navision-CVA - OS
name-description ( RW):
sr-uuid ( RO): 4da984e7-8c03-875a-0990-30a29863ee0a
virtual-size ( RO): 161061273600
sharable ( RO): false
read-only ( RO): false
Was considering the below:
xe vdi-forget uuid=28aaf3f0-447c-44a2-ad8e-e7c159b41ef8 force=true
xe sr-scan uuid=4da984e7-8c03-875a-0990-30a29863ee0a
xe vbd-create device=0 vm-uuid=b60762de-c222-2911-e18b-488c56e21646 vdi-uuid=28aaf3f0-447c-44a2-ad8e-e7c159b41ef8
xe sr-scan uuid=4da984e7-8c03-875a-0990-30a29863ee0a
Latest version of XOA/XCP-NG. (xo-server 5.111.1, xo-web 5.114.0, XCP-ng 8.2.1)
Edit: Forgot to mention that the disk UUID should be the snapshot of the last backup as it's only a few hundred MB large.
Thanks
@olivierlambert Thanks. I suspected that, but thought it was me being dumb and haven't found anything on it
Thanks
Hi,
I'm trying to add a new host to an existing cluster with HA enabled, but I am getting the error below:
pool.mergeInto
{
"sources": [
"f42c2b0d-9090-8a71-29ea-08860c618e2a"
],
"target": "1242d5b9-c1f7-4fcf-ef1a-21b1967fb6cf",
"force": true
}
{
"code": "HA_IS_ENABLED",
"params": [],
"call": {
"method": "pool.join_force",
"params": [
"192.168.99.109",
"root",
"* obfuscated *"
]
},
"message": "HA_IS_ENABLED()",
"name": "XapiError",
"stack": "XapiError: HA_IS_ENABLED()
at Function.wrap (/opt/xo/xo-builds/xen-orchestra-202303290507/packages/xen-api/src/_XapiError.js:16:12)
at /opt/xo/xo-builds/xen-orchestra-202303290507/packages/xen-api/src/transports/json-rpc.js:35:21"
}
Worked fine before enabling HA on the shared storage. HA is working fine as far as I can tell and I do have the cloud icon with the green "very good" on the pool. Not sure what I'm doing wrong.
This is on fully updated XCP-NG servers and XO from source commit 53e0f.
Appreciate any pointers.
Thanks
Just had time to check the new conversion, and it worked using the latest Virtualbox command I pasted, copied it directly to the repository, and it was recognised and booted ok after attaching to a VM.
Many thanks for the help and apologies for the hassle!
@olivierlambert I did try that before trying the import, but when I do a rescan, I get the error below:
Rescan all disks
SR_BACKEND_FAILURE_40(, The SR scan failed [opterr=uuid=b2394f60-1235-41ed-85ab-63809d57e484], )
I installed Virtualbox and used the command below to convert from a vhdx to a vhd file:
vboxmanage clonemedium source.vhdx destination.vhd --format VHD
This worked for the VHD that was smaller in size. So did the same thing with the larger VHD. I tried originally from Hyper-V, but I had some issues if I remember correctly or maybe I did not find an option to change from vhdx to vhd. I am trying to convert again, but specifying "--variant standard" just in case. As I understand, this explicitly specifies image type as dynamic.
I just tried that command, but still stuck unfortunately.
[07:49 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]# vhd-util read -p -n b2394f60-1235-41ed-85ab-63809d57e484.vhd
Failed to get bat for b2394f60-1235-41ed-85ab-63809d57e484.vhd: -22
Googled the error, but did all results I got were Windows-related.
@goreandor said in Error importing large vhd file:
@olivierlambert I was not running an old build, but I updated earlier this week or late last I think just in case. Just running an update again. My updater script says "Updating Xen Orchestra from 'c2e0c97d9' to '53e0f17c5'".
I just tried to import the VHD again from a VHD that is already on an SR on version 53e0f. Log below:
[07:19 xcp-ng-r550 ~]# cd /run/sr-mount/558efc11-bec3-7618-651a-bca4c90ceaba
[07:19 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]# ls
4f8e366c-ab9c-4043-98cd-aded4389dffa.vhd filelog.txt
[07:20 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]# uuidgen -r
b2394f60-1235-41ed-85ab-63809d57e484
[07:20 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]# mv 4f8e366c-ab9c-4043-98cd-aded4389dffa.vhd b2394f60-1235-41ed-85ab-63809d57e484.vhd
[07:20 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]# xe vdi-import filename=/run/sr-mount/558efc11-bec3-7618-651a-bca4c90ceaba/b2394f60-1235-41ed-85ab-63809d57e484.vhd uuid=b2394f60-1235-41ed-85ab-63809d57e484
The uuid you supplied was invalid.
type: VDI
uuid: b2394f60-1235-41ed-85ab-63809d57e484
[07:21 xcp-ng-r550 558efc11-bec3-7618-651a-bca4c90ceaba]#
I still have the uuid issue
@olivierlambert I was not running an old build, but I updated earlier this week or late last I think just in case. Just running an update again. My updater script says "Updating Xen Orchestra from 'c2e0c97d9' to '53e0f17c5'".
@planedrop Yes, I'm trying to import using Xen Orchestra. I tried importing from the command line after copying the vhd manually to a storage repository, but I can't get over the invalid uuid error I tried running uuidgen from my Linux machine and also on a XCP-ng server just in case there was something different. From what I've seen, it should be just a "uuidgen -r" to get a compatible uuid.
Maybe I'm missing something really stupid and basic. I will try to go through the Lawrence Systems videos and find that one maybe there is something that helps. Today I'm expecting have work outside for most of the day I think, so there might be a delay in my replies.
Thanks
@olivierlambert Hi Olivier. Apologies for that. I said XO CE. I meant the community edition. i.e. compiled from source.
Hi,
I have been having issues importing large vhd files (This one is 127GB) using the latest XO CE and a fully updated XCP-ng server. Usually the error I get is "Uncaught TypeError: NetworkError when attempting to fetch resource". At least in Firefox. In chromium, I get "Failed to fetch":
Uncaught TypeError: Failed to fetch
at r.post (fetch.js:7:3)
at index.js:1805:24
at Generator.next (<anonymous>)
at le (index.js:3265:63)
at i (index.js:3265:63)
I tried mounting the NFS share manually on the server, copying the file over and then using something like "xe vdi-import filename=./4f8e366c-ab9c-4043-98cd-aded4389dffa.vhd uuid=4f8e366c-ab9c-4043-98cd-aded4389dffa". I couldn't import without the uuid, and when I tried "uuidgen -r" or -t for that matter, I get that uuid is not valid. Then I tried creating a new disk, copied its uuid and deleted it, and used that uuid, but still couldn't import it . Same error:
# xe vdi-import filename=./4f8e366c-ab9c-4043-98cd-aded4389dffa.vhd uuid=4f8e366c-ab9c-4043-98cd-aded4389dffa
The uuid you supplied was invalid.
type: VDI
uuid: 4f8e366c-ab9c-4043-98cd-aded4389dffa
I don't know what to try anymore. I was really hoping of moving our small setup from standalone Hyper-V servers to XCP-ng, but I'm at a loss now. A smaller file, around 40GB imports without issues.
Anything obvious that I am missing? Any pointers would be greatly appreciated.
Thanks