Online
Hi,
This is the expected behavior. The oldest backup will always be a full (key) backup, and newer incremental backups will be merged into this backup as you exceed the retention schedule. When you take the full backup on Saturdays, that doesn't eliminate the need for this prior full backup. Thus you end up with two full backups for a period of time.
@Nevering Have you check here? https://docs.xcp-ng.org/project/ecosystem/#-hosting
@MW6 You may be able to copy the VDI to another location so that you can access it via another VM.
Have you searched the internet for similar issues? Here's one that I found that may help you.
@coolsport00 Please stick with the documented method to be safe. 
@coolsport00 These are two different features. The XCP one involves renaming the physical NICs. Any changes you make in XO doesn't rename the physical NIC.
From the error message, I would guess that there is some corruption in the XVA file. Have you tried importing it back into the original system, or maybe exporting to XVA again and then retest?
@RaHu Your are correct. To delete an individual snapshot, change /vms/ to /vm-snapshots/.
What about using a web hook to vm.create and vm.delete?
Hi Yusuf,
I extended your trial period.
Regards,
Dan
@fdhabhar You may want to review our VMware migration checklist.
From the VMFS6 section --
- Uninstall VMware tools before migration.
- Remove all snapshots attached to the VM.
- Be sure you don't have any ISO mounted to the VM.
- Shutdown the VM.
- take a fresh snapshot.
- Start migration.
Any locks should be automatically removed once the migration is complete as long as you follow these steps. To manually release the lock, you can restart the xo-server server in XO.
@john.c IDK about hundreds /thousands, but the V2V process will allow you to import multiple VMs simultaneously.
Is there a reason that you can't simply look up this information in the XO web interface?
Hi,
When you get an SR_202 error, it means the iscsi daemon has logged out from those storages. it's usually fixable by scanning that storage IP for all iscsi targets it presents, then telling iscsi daemon to login to all of them --
iscsiadm -m discovery -t sendtargets -p <Target_IP>
#then login
iscsiadm -m node --loginall=all
Then rescan the SRs, they should start working and not throw a 202 error anymore.
To get that IP to scan, just go to the sr in xoa, then hosts tab, it'll show a target field.
Regards,
Dan
@irtaza9 You should be able to login with the default credentials after you restart the xo-server service with systemctl restart xo-server.service.
@yzgulec You will likely need to install the fix given in the following post for XOA to function correctly on vSphere --
@DevilDan Are you using the Load Balancer plugin to manage the load on your pool?
Check to see if the VM is running in PV mode -- https://xcp-ng.org/blog/2022/01/17/removing-support-for-32-bit-pv-guests/
What type of storage are you using? FYI, shared storage is only accessible by hosts within the same pool. You can't safely share the same SR with multiple pools.
From your description, it sounds like the warm migration was proceeding as expected. The VMs will crash if you live migrate them because of the difference in supported operations between the different CPUs.
Yes, it should work correctly if you use fields. Also, I think uuid need to be lower case.