I think this is important. When the issue appears the replicated VM that auto-starts has the [IMPORTING] prefix as in the image below. [image: 130e1c45-ad28-4b6c-a4d7-202b552ab723-image.png]

Question for you @florent

@pdonias Hi, On Master, as of yesterday, I see this only when I am logged in using an IP address on the URL instead of the hostname. Either way it is SSL with trusted certificate. There are no console errors Browser is Microsoft Edge on Windows No difference in behaviour between incognito mode and normal. Yes I see all the VMs There is an improvement - now if I am creating a new VM only the selected network is reverting back to default when it refreshes, the other things like number of cores and ram is remaining when I set it, whereas previously these also were wiped back to default every 20 seconds or so. Thanks Alex

@rauly94 Hello everyone. Anyone can help me on this issue. Now it started happening on 2 vm's instead of 1 vm. It is happening on the backup replication. Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Start: Jul 5, 2023, 09:03:18 AM End: Jul 5, 2023, 09:44:46 AM Duration: 41 minutes Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Start: Jul 5, 2023, 09:03:09 AM End: Jul 5, 2023, 09:45:12 AM Duration: 42 minutes Error: VDI_IO_ERROR(Device I/O errors)This is a XenServer/XCP-ng error Type: delta

Yeah for doing a fresh start it's easiest to just nuke the backup directory you were using and start over, have done it before and it's quick and easy vs trying to manually remove them all within XOA.

Not that I am aware of.

@ronivay, I resolved my problem with orchestra which did not want to make backup with NFS. Orchestra wrote errors like: Command failed with exit code 1: mount -o -t nfs 192.168.11.53:/backups/xo /run/xo-server/mounts/0e5e9511-8912-48d4-96ad-532979533332 mount: only root can use "--options" option In general, orchestra tried to use mount option "--options" but mount command rejected this option. When I mount my NFS-shares manually everything was ok - mount works, read-write too, umount also. I did simplest process. I removed at all "--options" from mount command. (As far as I understand, *BSD mount will not work without this option but my Ubuntu works). Background: xcp-ng server (centos 8.2) as NFS server ubuntu server 16.04 where orchestra is going to be placed Orchestra installed 10 days ago from sources according to https://xen-orchestra.com/docs/installation.html#from-the-sources I complete followed document before chapter "Installing dependencies". I made yarn Then, before "yarn build", I manually edited file: /opt/xen-orchestra/@xen-orchestra/fs/src/_mount.js at string 68 I replaced await this.#execa('mount', ['-o', options, '-t', type, device, realPath], { with await this.#execa('mount', ['-t', type, device, realPath], { I then proceeded to follow the instructions: yarn build a so on... Now "patched" orchestra fine makes any kind of backup with NFS. At least, I solved this problem. Yet another question appeared as backup works What kind of Backup should I use to make full copy which enough for restoring (Heaven forbid)? I tried simply "Backup". It SUCCESSFULLY (!) created several files with 56 kbytes (no giga, no mega but kilo). I suppose it abnormal. My VM has got 20 Gb of disk space and about one half is already used (ubuntu server, postgres etc). As far as I understand (https://xcp-ng.org/forum/topic/7034/backup-with-local-usb-hdd-attached-sr_operation_not_supported/5?_=1688120707451) my version of xcp-ng (8.2.1) does not support "Snapshots" with local disks. Now I copy imagine of my VM with cron as temporary option but may be there is some more correct backup option?

@sumansaha Hello Team, The issue has resolved after applying xe-toolstack-restart. Thanks.

@sumansaha that is a good news yes, the replication go through the XO VM, the faster the link the better the performances

@AtaxyaNetwork Thanks

@olivierlambert Thanks

@julien-f @julien-f All I have done is let ronivay's script do the builds daily on schedule if there is a new commit on the master branch. His script has not changed. There have been no new patches to the hosts. I don't have an explanation.

XO saved the day

@Danp Yes but unfortunately before of this incident audit is disabled

No problem! Did you manage to do what you need?

Toggling it back and forth seems to have worked, thanks.

The fix is now merged on master and will be part of the next release.

That's great, we'll be watching the space.

I don't have experience with something like this, but I can do a mini lab with something like this, to test the steps below . What would I do. 0. Do you have metadata backup for XCP-ng? If YES 1.1. I would reinstall the server from scratch, before make a backup with Clonezilla with the boot disk of XCP-ng ; 1.2. I would reconnect iSCSI, without formatting it - reinitialize, only reconnecting (to not delete the data on it); 1.3. I would restore the metadata; 1.4. The result should be all the info about the VM that was on XPC-ng, and hopefully it also attaches the iSCSI disks. If NO 2.2. I would reinstall the server from scratch, before make a backup with Clonezilla with the boot disk of XCP-ng; 2.2. I would reconnect iSCSI, without formatting it - reinitialize, only reconnecting (to not delete the data on it); 2.3. I would redone the VMs from scratch and start attaching the disks to identify which and to which VMs they were attached before; 2.4. The result should be functional VMs In principle, if you have the disks intact, the data is there, you just have to restore the VMs (RAM, CPU, attached the correct disks, etc.) This is the menu for XCP-ng metadata backup, Backup/New. [image: cf7e9ec4-0d85-4ab6-9a1a-1061cd40a685-image.png] [image: 129ea089-e38b-4cf6-aa04-f7b3020b23a3-image.png]