@dinhngtu Thanks, that helped. Download has started, once it completes, I'll get it installed and retry. I'd also found this - https://gist.github.com/alexrintt/9502728c6d75d27e2885c9cdaab0e550

@olivierlambert can memory size difference being showed as different cpu? tried both commands [image: 1737500112335-screenshot-2025-01-22-005049-resized.png] [image: 1737500122455-screenshot-2025-01-22-005412-resized.png]

@Tristis-Oris Do first verify you have good backups before considering deleting snapshots. You could also just export the snapshots associated with the VMs.. As to the GUI vs. CLI, it should do the same thing, but if it runs, it should show up in the task list.

No change after full xcp (8.2.1) patch and reboot. The VM in question started without issue as well. For reference, I'm using XO commit d044d (currently 11 commits behind) on Master commit 6d34c. I will leave as is since everything is functional to see if the future commit helps. I should be able to revisit at the end of the week to rebuild on the latest XO commit and test.

Updated all my hosts but ended up with a bunch of stuck tasks for API host calls, didn't seem too healthy! It looks like they were stuck, kept seeing a host unhealthy power state repeatedly pop up and disappear. I opted to select all tasks and delete, same with my logs (I monitor externally anyway) which appears to have resolved this for the moment. I no longer see these mdadm logs being generated and everything appears normal.

@olivierlambert Yes we can, however, it's unsettling not knowing the root cause. But seems that restarting the Xen Toolstack may have resolved this issue. I haven't attempted creating a VM yet, so I'll do that when I get in tomorrow.

@olivierlambert Technically, yes, I suppose I could do that. However, that would not mimic what a SysAdmin would have to do, should they run into this trouble in production. Is there no other alternative to get this utility, perhaps as a .deb package that I can manually install on XOA? Lastly, I performed the following testing just now: Created a new VDI on a known working VM and put the VDI on the problematic SR (let's call it NFS-DS1). I then attempted to migrate the newly created VDI to the known good SR (NFS-DS2); it failed with error VM_LACKS_FEATURE. So I crested another VDI, attached to the same VM, but this time I put it on SR NFS-DS2 (the good one) and then attempted to migrate it to SR NFS-DS21; IT WORKED. So I retried migrating it back to NFS-DS2, and it worked as well. Finally, I went back to the original new VDI I started with, and attempted to migrate it from SR NFS-DS21 to NFS-DS2; it worked! SO, it seems the issue remains with the VDIs that seem to have lost their parent. P.S. I haven't noticed the VDIs disappearing from SR NFS-DS1 for over an hour now.

In theory there's no such thing as XO checks. Now for the feature request, I prefer the idea of showing manual leftovers and leave the admin to decide what to do with it

@olivierlambert as i say, now it works. So nvm)

@olivierlambert Thanks for that ill plan for the weekend to do that and see how it goes.

Happy to help!

@olivierlambert thank you. I wish all the best to XCP-ng hence sharing something what is a public knowledge though not necessarily reached you guys - might be worth to attack and tackle thousands of commercial and paying customers leaving VMware soon: https://blogs.idc.com/2024/08/07/vmware-cost-increases-how-broadcom-vmware-product-offerings-are-evolving/ I know first hand businesses moving away soon from renewing VMware and have recommended in talks XCP-ng with commercial support as that's what these companies need.

I just sent a precision upstream with your report @pmcgrail

@DustinB Totally in line with you but in the meantime since i figure this cli out too now i am totally ok with what i have currently and its not too pressing.

https://docs.xen-orchestra.com/advanced#job-manager

ok, thanks. No local storage all shared iscsi storage

(Thanks @nathanael-h , might even worth getting a part of this in our current doc with an example, adding @thomas-dkmt in the loop)

@thomas-dkmt said in "Block migraton" option on the VM´s Advanced tab: @olivierlambert @DustinB Thanks! It's always helpful to have a native speaker's perspective. Happy to help, worth noting that if a setting like this is enabled on a given VM, there should also be some sort of visual indication on the home screen of XO to annotate that these VMs won't move unless this is disabled.

@Danp have now

@flakpyro said in How to migrate XOA itself?: @DustinB Are the any downsides to having two XOA instances pointing at the same pool? Since the config itself is stored at the pool level im guessing theres no downside? IE: Priimary XOA running in core DC and secondary XOA running at your DR site. Is it just a matter of adding the pool on the secondary XOA and it downloads the existing config or did you need to do a full export / import? If you import your configuration, each XO instance will think they should be running the backups as far as I've noticed. If I have two instances running with the same configuration, I simply disable the backup jobs on one of them. The config file is just an XML that contains your existing instance. You can import it to any new XO instance and have the same exact configuration.