@olivierlambert said in XOCE - ISO upload is renamed after upload to ISO SR:
I think we discussed it internally, IIRC it's not XO doing any renaming, but the toolstack. Adding @andriy.sultanov or @psafont in the loop
I'm not sure about that, xapi is quite conscious it cannot rename these ISOs, in the few places I've seen it mentioned. I did not see any place in xapi that could have renamed these, nor reproduce it in my system.
I see at least on a couple of instances that the pool join is being forced. Please don't do this unless you understand the checks being ignored.
What's the result of a pool join without the force option?
Do both hosts have tls verification enabled?
If not, run xe pool-enable-tls-verification. This will set up the certificates for pool communication correctly for the hosts in that pool and turn on TLS verification for pool communication.
If yes, run xe host-list --minimal | xargs -I _ xe host-param-get uuid=_ param-name=name-label | xargs -I _ xe host-refresh-server-certificate host=_. This will reset the certificates for all the hosts in the pool.
Try running the normal join command after doing these steps, and report whether it went well, or report the error.
@jmannik ah, indeed. Do you know which server / interface holds the IP 192.168.30.13? I suspect is still VMHost13, but a different interface.
Until the members have configured their master as 192.168.30.13, you'll have this error. This can be done by a call, but since it's a delicate operation, it's better if there are no operations running on the pool. SSH into the VMHost13, and run
xe host-list name-label=VMHost13 --minimal | xargs -I _ xe pool-designate-new-master host-uuid=_
This should write the new IP to the files of all the pool members and stop blocking this issue from enabling HA
@jmannik The IPs match, and now I don't have an explanation on why is this happening, I'll take another look at the codepath, but that'll have to take a while, as work is piling up
@jmannik Could you collect the file contents of /etc/xensource/pool.conf from all the other hosts? The command is failing in one of them, not on the master host.
So we probably need to tell XO team the "right way" to enable HA because there's no way to know from "outside it's not meant to, xapi makes the call automatically.
I don't think so, it's xapi's responsibility to make that call
@olivierlambert The call is indeed hidden from the docs, and only callable from inside a pool... it's called as part as Pool.enable_ha
