@jmannik said in Unable to enable High Availability - INTERNAL_ERROR(Not_found):
@andriy.sultanov @psafont
https://drive.google.com/file/d/1aJyCYSAuRIBb0X-23gJ6ORtrHSciYH8a/view?usp=sharing
Here is the log file
It's not crystal clear the condition that causes the exception, but I can see some unprotected exception being raised in that path host.ha_join_liveset when trying to recover the host uuid and it's not found. I'll investigate
@jmannik said in Unable to enable High Availability - INTERNAL_ERROR(Not_found):
[18:15 vmhost13 ~]# xe pool-ha-enable heartbeat-sr-uuids=381caeb2-5ad9-8924-365d-4b130c67c064
The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: Not_found
That message is created by an exception. It's commonly raised by List.find and List.assoc, in this case the exception wasn't caught.
It's usually difficult to find out which one, since these functions are frequently used and catching the exception can happen in a caller of the function that uses it.
Could you provide the xenserver.log, as Andriy has asked? Otherwise I don't think we'll be able to find the exact cause.
@jmannik Please upload your /var/log/xensource.log from the time of the error, otherwise it's hard to see what went wrong
When you say retry, did you completely restart the installation process, or did you just go back to the installer screen and retry the step that does the backup?
If you retried the step, you should still have all the logs of the installer on the updated host in /var/log/installer/ in that case, I would suggest checking the dmesg-log, that sounds like a disk error to me.
Having removed the file would not impact the newly upgraded host in anyway, it just means you lack that file in the backup, so that could have an impact in case you were to restore, which I hope you won't need.
Other than that, I would encourage you to check your disk health as this could be a sign of hardware error.
@acebmxer I tried to force it by uploading the same iso twice, and couldn't reproduce the issue. XO shouldn't allow to upload an ISO to an SR with the same name 
@olivierlambert Just tried it, because I don't know what XO does:
It starts with a vdi create on the ISO SR:
Oct 8 17:10:20 vega xapi: [debug||2506617 HTTPS XO_IP->:::80|VDI.create R:ceff14462188|audit] VDI.create: SR = 'ISOs' UUID'; name label = 'ubuntu-24.04.3-live-server-arm64.iso'
then it imports the iso into it:
Oct 8 17:10:20 vega xapi: [ info||2411746 HTTPS XO_IP->:::80|task.create D:355d9ec67664|taskhelper] task [XO] Importing content into VDI ubuntu-24.04.3-live-server-arm64.iso on SR ISOs R:0506cfe68373 (uuid:96ba5dea-ffc5-5131-571d-7545277a7083) created (trackid=df64863568c5db04d470bfd2c5872e20) by task D:355d9ec67664
Oct 8 17:10:21 vega xapi: [debug||2506627 HTTPS XO_IP->:::80|[XO] Importing content into VDI ubuntu-24.04.3-live-server-arm64.iso on SR ISOs R:0506cfe68373|import] import_raw_vdi task_id = OpaqueRef:0506cfe6-8373-7b22-505b-fcc07348bb7b vdi = OpaqueRef:81c1154f-17f4-2114-7c7a-bd74604aff6f; chunked = false; format = raw
I see SM managing a vdi with the name UUID.img, a strange error, but it ends up creating the VDI with the expected name. I'll wait to see if the same thing happens and it's later renamed to the .img. I've refreshed the SR just in case, but I can't reproduce the issue just yet
@panzersrmm I don't think these are saved in the XAPI VM object (that you are querying with xe) - these are tracked by XOA itself.
@panzersrmm said in "Block migraton" option on the VM´s Advanced tab:
Hi! Is there a VM parameter that saves this "Block migration" UI button?
I wasn't able to identify which one it is with command:
xe vm-param-list uuid=<VMuuid>Thank you!
How do you mean? Is the XO option not persistent?
XO sets these parameters:
# xe vm-list uuid=$UUID params=blocked-operations
blocked-operations (MRW) : pool_migrate: true; migrate_send: true
Which you can set like this yourself:
# xe vm-param-set uuid=$UUID blocked-operations:migrate_send=true
# xe vm-param-set uuid=$UUID blocked-operations:pool_migrate=true
@bnerickson
About 1, That's something that I'd like to support in the future, but it will take some time to get there. About 2, currently LLAs are not allowed to be the used as the management IPs, and I wouldn't like them to be used as such: it can lead to hosts not being to connect to one another if they're not in the same physical network. They still could be configured for the interfaces and shown to the user, but not as the only IP for the interface, or the main one for that matter.
@olivierlambert Ideally XCP-ng (xapi) could add this to a queue, and wait for some time before cancelling the task because it took too long. This also needs some kind of feedback that can be given to the user / client, which I think currently is quite undercooked (how to report is waiting on other migrations to the same host when a client asks?). For the time I think XO being aware that it can retry the operation would be simpler, especially because it already has code to do it for other operations
