What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell?
I have no Idea. I had it on "Protect from accidental shutdown" but turned that off again, later. Doing this again (on, off) helped, as you said.
Thank you so much!
xe vm-list is-control-domain=false power-state=running params=name-label,allowed-operations
Great, I think you are onto something here. There is one VM that has
blocked-operations (MRW): suspend: true; pause: true; hard_reboot: true; clean_reboot: true; destroy: true
I looked in XO for the VM's Advanced section, but couldn't see anything that sounded like it could help getting rid of the blocked suspend and possibly the other blocks that don't sound reasonable.
Do you also have an idea how I can help it?
@poddingue the response is "VM_REQUIRES_SR". The VMs are storing their vdisk on a local NVME. This is crucial for this hypervisor as I do not want it to depend on network storage. Can I work around this error in such a scenario, i.e. is a Rolling Pool Update possible under these circumstances?
Does the Smart Reboot require evacuating the VMs? Technically it shouldn't as in XO there will be a warning that can be manually overridden. WHy do I get the warning in case of a Smart Reboot?
@AtaxyaNetwork yes, guest tools installed
When I would like to smart reboot my host using XO button Advanced > Smart Reboot it tells me:
Smart Reboot failed because ... VMs have their Suspend operation blocked. Would you like to force?
At first I thought this is because some VMs had enabled "Protect from accidental shutdown". So I disabled this for all VMs. However, even after a forced smart reboot, and after restarting all VMs I still do get the same message when I initiate a Smart Reboot.
What could be the root cause of this and how can I fix it?
I think is issue is what keeps me from doing a "Rolling Pool Update".
@olivierlambert Thanks that worked. Kind of obvious approach, still didn't try that 
I have the problem that 2 backup jobs are stuck in state "started" - but they are not visibly running any more.
The cause was that the Remote did not provide sufficient space.
The thing is that the scheduling for these jobs doesn't work any more now (I assume due to state "started").
How may I reset the state of a backup job?
@olivierlambert like what ballpark? I used it on 1Gbps.
@olivierlambert said in Migration compression is not available on this pool:
So just to recap, setting it via xe works out of the box right?
Correct.
And now it works again (the toggle in XO) but doesn't change the config when checking via xe ?
No. Toggeling on the UI is also reflected correctly by checking via xe.
After some testing however, no performance difference could be measured between Migration Compression being enabled or disabled.
@olivierlambert there was nothing in the log. I tried setting it per the xe command and using xe I could see that it is on or off, but XO did not show these changes on the UI.
what helped was restarting XO. since then I can toggle it and xe shows the same status.
I cannot enable the Migration Compression on my pool of two 8.3 XCP-ng hosts. The X_O UI says "Migration compression is not available on this pool". Any ideas what could be the reason and how to make it work?
@stephane-m-dev understood. My suggestion regarding the different behavior (does not work with disk share, does work with user share) on unraid would be to put this in a "tip" in the documentation section about setting up Remotes.
@stephane-m-dev well, have you tried this on an unraid server with a disk share? if not, you are still missing my point.
the disk share (there the error occurs):
"/mnt/disk3" -fsid=87,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)
the user share (here it works):
"/mnt/user/backup" -fsid=91,async,no_subtree_check 192.168.100.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)
please also do not overlook the other problem with the full backup mode when encryption is used: "Trying to add data in unsupported state" (see above)
@stephane-m-dev the folder was positively empty, I explicitly removed all files before adding it as remote. Have you read what I wrote about different share types in unRAID?
@stephane-m-dev the path exists but it was empty.
@daniel-grimm definitely not related to cloud in my case!
I am now also seeing the "Trying to add data in unsupported state" problem,
see this thread: https://xcp-ng.org/forum/post/84594
That did never occur when the remote used for this backup was not encrypted.