@dinhngtu You rock - thank you!

@kratos said: This may not be best practice. in a two hosts pool, if your replicated VMs live on the Master, and it's gone, you won't be able to start the replicated VMs you will first need to transition slave to master indeed CR is better to another pool

But thank you for your time all the same.

@olivierlambert Can you provide insights? Is nested virtualization as in running Hyper-V inside a XCP-ng VM expected to work?

Found issue in my script all seems to be working now for me just no vmware vm to test import on

@rzr Hi. Thank you very much. I will be setting up a new server within the next 2 weeks and will definitely test it. Then I will give you feedback! Thank you again for picking it up!

@gduperrey Worked swell, thanks

@TeddyAstie That's more like it. I'm not finding the com2tcp though. I at least have something to search for. Once configured, is this persistent or do I need to create some sort of start up script that runs/loads a config on machine boot? Thanks!!

@Dezerd you just have to start-copy the Replica VM it permits the original job to keep replicating on the VM. there is no failover/failback mecanism AFAIK if you work on replica started VM, you will have to put up in place a replica going to original hosts

Thank you all for your answers—now it's clear.

Regarding the restore thing, it's clearly sub optimal, can you submit an improvement feedback directly to https://feedback.vates.tech?

@kruess I'm unsure why you are encountering this error. Did you eject all ISOs as shown in the documentation -- Eject CDs from your VMs before upgrading to avoid issues: xe vm-cd-eject --multiple

@User-cxs si ici :[image: 1774010356739-c9d11a94-06d8-4a3c-b191-f95b2e2ef6f7-image.jpeg] tu DISABLE le serveur. tu nous confirme que c'est "comme" le probleme que tu constates ? un XOA tout vide en page d'accueil ? tu re ENABLE, et ça reviens ok ? tu n'as pas de probleme réseau / micro coupures / host distant au XOA (ipsec/openvpn?) ? la déco/reco que tu as me fait penser a un simple probleme réseau (si ça reviens tout seul et aucun autre impact...)

@anthoineb thanks very much! Definitely has us sharpening our cli skills in the meantime….

@yann Item Opened on Gitlab.

@dinhngtu Yeah, I suspected that as well. So I inspected the SR and it showed connected to both hosts (at least in the XO UI - I didn't drop to the CLI to really confirm). By altering my workflow a bit and slowing down, I seem to have found the right "sweet spot" of delay and the issue hasn't resurfaced. Here's what I'm doing now, when I need to revert the snapshots of all three VMs: In the XO VM list, I select the three VMs and power them off at the same time. I then start with VM1 and eject the ISO, VM2 and eject the ISO, then VM3 and eject the ISO. By the time I circle back to VM1 for the next step, about 10-15 secs have elapsed. I then start with VM1 and revert the snapshot, and repeat the same on VM2 and VM3. By the time I circle back to VM1 for the next step, another 10-15 secs have elapsed. I re-attach the ISO to all three VMs in sequence. Another 10-15 secs elapse. I then start with VM1 and power all three VMs sequentially. The entire workflow takes about 30-45 secs, and I'm finding that by doing this, the issue hasn't resurfaced.

@nikade more beautiful than scary, it goes in an usual place where no one lives as you can see on satellite view it's an effusive éruption, not explosive, i was barely 100m when taking photos and you can also poke lava with a stick if you want (but need appropriate masks because of harming gazes like sulfur) not the first time it goes to the sea, the island expands slowly no casualties except from some fishes

@User-cxs You are probably experiencing this issue. Just a guess because you didn't actually ask a question.