@olivierlambert Thanks for the quick fix - update worked fine when I tried again, right after I wrote my post

@DustinB I advise you not to decide for others what they should do. I'm tired.

@BSmithITGuy Thanks for your information. The temporary workaround now is put Xen Orchestra to the same XCP-ng management network. Update 1: Diving deeper, I discovered that the API was changed the host management address (where the VM is located) to the backup address: https://github.com/vatesfr/xen-orchestra/blob/92932dd54645838db58ecfdd872895c5ad461608/packages/xen-api/index.mjs#L1010 async _setHostAddressInUrl(url, host) { ... url.hostname = await this._getHostBackupAddress(host) }

This message shouldn't appear if the license is properly activated. Since you have an active XOA trial, you should open an official ticket through the support portal and we can take a look at this for you.

Still, I remember we had a dedicated CLI tool to test it

@bleader said in Created a new bond interface and lost management connectivity to hosts: The original problem could be a known issue when creating bond including the management interface that we have to investigate. Although the emergency network reset should have fixed that, so maybe it is a mix of the bond creation issue and MTU issue. In the reinstalled pool, did you create the bonds already? If so I would think changing the MTU should be fine, especially as it worked on other PIF, but with MTU issue it is often quite sneaky, so I would not make any promises either. Yes I have recreated them, but I am not game enough yet to change the management interfaces to MTU 9000, though I have done on bridge interfaces for VMs, because I was losing ssh sessions, and this solved the issue. Also, the bonded storage interface is MTU 9000 no problem.

@ph7 Thanks for the tip! Appreciate it.

@olivierlambert we are thinking about implementing a relationnal DB in the future. Maybe it could offer to stock snapshots as "archived"... I don't know for now. I understand that it could be risky to delete old snapshots, and maybe the responsability of setting the snaspshots retention can be an ACL subject... There are plenty of avenues of work on this topic, and more generally on the retention of information about objects, tasks, and other actions. It's a real in-depth topic.

@Danp Sorry, due to the host being added and me continuing on with my other tasks, it is not. I could have made that more clear.

@Tomcatter It's from Citrix: https://www.xenserver.com/downloads

@MathieuRA For this issue, fix-server-connect works for me. Thanks.

@Forza I don't know, I guess that's part of what I am trying to find out. How to get the metrics of the physical cpu usage. I thought that's what I would get with activating Netdata (Advanced Telemetry) from XenOrchestra.

Not a problem, something to be done correctly, and not implemented at all in the current XCP-ng API. In other words, it's not trivial You can create an issue in XO repo with all the details (and the screenshot), this at least needs some serious work to find what would be the best approach (and then sorted from our backlog)

@nathanael-h Alright...will take a look

@astrugatch At this point, I'd submit your ova to the Vates team as they requested to have them look inside it to verify you're exporting what is needed to be able to import into XO

@Andrew Gggrrr...you know what's funny about your response?...I was actually just in the Advanced tab and glossed right over that! hahaha Thanks Andrew

So it looks like it was a browser cache problem, solved by deleting it.

@TeddyAstie Thanks for confirming it's not supported, that saves me some head scratching! I'd based the assumption of it working post boot on the stats for memory usage being low and free -m showing < 48 GiB but guess I just misunderstood. Do you know if this is a fixed limitation or is it a feature that can be added in the future?

@AlexQuorum Nice to hear it In the meantime I've made a bugfix which will soon be available so you can edit the monitors instead of recreating them.