Just checking if there is any impact in XCP-NG and / or XO that may be impacted by the log4j vulerability? Not sure if some of the API's uses java?

@olivierlambert Perfect, setting the parameter on both the VM and the snapshot resolves the issue. I am able to continue backups Thank you both for helping!

I have a Windows VM that does not want to boot, boots into EUFI settings. In "bios" it shows the Windows Boot Manager so it recognizes something on the disk. I want to insert an ISO but when selecting the ISO, it does not "select" it (the select box resets). Any idea what I can do?

@olivierlambert all the best for 2022!

Not at all, however, the disks are thin provisioned so actual size may differ, but as for the size set of each disk these have not changed at all. Last week we had another VM do the same, however, it fixed itself but this week it seems to be this VM causing the above issue

Morning team, we have a backup job that exports (delta) to remote NFS and also does a CR to a failover server. Out of the 16 VM's (most are small), every now and then we get 1 that fails (normally a large one) at random, which then triggers a full backup on the next backup (as expected). The last couple of days however it has kept failing and I cannot quite determine which of the 3 hosts involved (hypervisor, nfs server or failover server) is at fault.

Here is the output of the most recent failure (just changed the vm name)

vmname.masked (jhb06)  
Snapshot 
Start: Jan 9, 2022, 04:25:59 AM
End: Jan 9, 2022, 04:26:03 AM
Frank 
transfer 
Start: Jan 9, 2022, 04:26:04 AM
End: Jan 9, 2022, 07:05:53 AM
Duration: 3 hours
Error: aborted
Start: Jan 9, 2022, 04:26:03 AM
End: Jan 9, 2022, 07:05:53 AM
Duration: 3 hours
Error: aborted
Local storage (14.3 TiB free - thin) - failover
transfer 
Start: Jan 9, 2022, 04:26:04 AM
End: Jan 9, 2022, 06:10:00 AM
Duration: 2 hours
Error: VDI_IO_ERROR(Device I/O errors)
Start: Jan 9, 2022, 04:26:03 AM
End: Jan 9, 2022, 06:10:00 AM
Duration: 2 hours
Error: VDI_IO_ERROR(Device I/O errors)
Start: Jan 9, 2022, 04:25:40 AM
End: Jan 9, 2022, 07:05:53 AM
Duration: 3 hours
Error: task has already ended
Type: full

From what I can gather, the Device I/O errors could be the fault, however, I also know this can be due to the task ending and the host not receiving further data. It completes all other exports (so out of the 16, only 1 fails).

Any ideas where I can start fiddling? All hosts are XCP-NG

Alright, say I setup a shared SR, how would I get it to that SR from the current local SR?

I have a template on host a (not part of a cluster) which I want to copy to host b, so that I can use that template for new VMs. Currently I create the VM on host A then migrate it to host B.

How do we go about copying a template accross to a different host?

Just checking if there is any impact in XCP-NG and / or XO that may be impacted by the log4j vulerability? Not sure if some of the API's uses java?

@olivierlambert you guys rock, thank you for all your hard work! Noted regarding the warning.

What was strange this time around was we've actually warm migrated another VM to new storage a month or so ago, and after the migration I shutdown the origin VM and attempted to do a last CR to ensure I get all of the data across. I however recalled that the backup did not want to run and I assumed it was probably because a shutdown VM cannot be CR. The backup job however of yesterday did indeed copy across the shutdown VM (or attempted to). Is there such a restriction that does not allow CR on a shutdown VM? We're doing another warm migrate in 2 weeks time and would obviously prefer to ensure all data is copied across as appose to a window period of data loss.

We've converted one of our hypervisors to XCPNG this weekend with new storage. I then setup CR to replicate one of our primary VM's across to the new server. The VM is about 2TB in size. I then followed the following steps:

• I shutdown the virtual server on the origin host
• I renamed the VM on the new server
• I removed the tag that said "continuous replication" - I believe this is added by default when CR is setup
• I started the VM on the new server. I got a warning saying that the VM cannot be started but I opted to force start as the CR is now "complete" and the server was already shutdown on the origin server

What I failed to do however was to delete the backup job, and simply be luck noted this morning the storage is 95% full and it was now busy replicating the shutdown VM accross to the storage I restarted the toolstack on both servers and thankfully the backup jobs stopped and on the new server the "pending" vhd files was deleted and storage is resolved.

If anyone ever uses CR as a method to migrate large VM's from 1 server to another, once migrated, DO NOT FORGET TO DELETE THE BACKUP JOB.

Over to the question, now that I removed the tag, renamed the VM and deleted the backup job, will the warning that that VM cannot start go away automatically or is there another setting that I need to set to tell XO that this is now the active VM?

@olivierlambert thank you Olivier and thank you for your prompt response. In hindsight this was all due to a combination of bad planning. Our full backup interval is set to 20 days, and this then led to full backups being run this week and that along with a 2nd set of backups + malware scanning led to the IO being overloaded and stopping / restarting the service.

To avoid this scenario, and I will be default assume this cannot work out of the box, but is there a way to set a schedule around the full backup interval? We would like to set these backups to never run on weekdays. If not, what can you recommend we do to retain a delta chain but also do full backups over a weekend where the schedule is set to run daily?

Once again thank you for everything you are doing for the community!

@olivierlambert will it also cancel the running backup job or just cancel the current backup? It appears our incremental backups started doing full backups today, and this has now caused a bottleneck on one of our primary servers as it was too busy with a file level backup and I think malware scanning so the IO timed out. Issue now is that I can boot the server but because all of the services are starting up (we have about 250 hosting accounts on it) the same occurs. I want to stop the running tasks but also the backup job so that I can focus on the 1 thing.

I assume restart toolstack on both sending and receoving server (it's a CR) - Should I restart XO as well?