@acebmxer Thank you for the reply! I will give it a try installing a new VM and restoring the config from the current VM. Thanx again!

@Pilow Thanks. I am using that script (Ronivay) but proxy is broken at the moment. Backups complete but the status is failed due to some piece of code that checks for license and returns "Fetch failed". I would like to use a documented albeit unsuported version of xo-proxy without having to comment license checks and the likes.

Still there is no documented way to deploy a proxy from sources. Is there any plan to document a wy to deploy proxy from sources. I am using a "hacky" version installed from sources but there are constant licensing checks that break functionality and would like to use an installation that is as close to the intented way of functioning as possible.
Also congratulations on an awesome progect!

I think this is important. When the issue appears the replicated VM that auto-starts has the [IMPORTING] prefix as in the image below.

It somehow relateable to https://xcp-ng.org/forum/topic/4791/disaster-recovery-backup-auto-starting-vms-but-shouldn-t

I have seen this pop up from time to time and add my own experience here. It has been my experience in at least two separate cases that if the host gets rebooted during the transfer phase of a CR job the replicated VM loses the blocked-operations parameter start which causes the VM to start alongside the source VM - which as you might suspect causes a lot of havoc.
It is very rare for this to happen at the right time but it does (as I am now in the process of manually copying rows from the database of the replicated VM to the main VM - fun stuff)
I am not a JS expert but taking a look at @xen-orchestra/backups/_runners/_writers/IncrementalXapiWriter.js it makes me think that the blocked-operations parameter is set after the transfer phase of the changes which it never gets to if the transfer is interrupted. If someone more JS-savvy can take a look and provide a solution it would be great.

Indeed, @olivierlambert, that was the issue and it works now. So for whoever has the same issue. First go to the local IP address of the host (NOT to the domain name), accept the certificate and then go to /xolite.html and it will work both with the ip address and the domain name in the address field.
Thanx again for clearing things up!

@olivierlambert I am currently on 8.2. I will upgrade and try later. Thank you!
@pdonias The certificates are already accepted. I will check back after I update to 8.2.1 as suggested by @olivierlambert but thank you very much for your suggestion!

High level overview feedback:
So a bit of feedback from me too.

1. The layout looks great!
2. I believe it has just enough to get one started with using the hypervisor (taking into account the existing labels and the placeholder buttons) or to help you in a pinch.

Current issue found that I assume should work at this time based on other messages is that the console seems to have been implemented but is not working. Chrome inspector console shows: WebSocket connection to 'wss://<my local ip address>/console?uuid=e4cd9c61-d399-a3fa-33f7-5699c920d523&session_id=OpaqueRef%3A927fa4fe-74c2-456a-bfd8-d84e98c3bf42' failed. After that there is a line with "Failed when connecting: Connection closed (code: 1006)".

The interface looks very clean and oriented on functionality. Congratulations and keep up the good work!

@olivierlambert Looking forward to it!

@olivierlambert Is this still the standing method of testing XO Lite? It still works but seems to be pretty much at the same stage it was 1 year ago. I was hoping to see some of the new UI from the recent blog posts.