Closed bobafetthotmail closed 3 years ago
Hi,
Can you walk me through the exact steps to reproduce this. Which version of XCP-ng you're running, is this a fresh installation and doesn't have any other VM's running? What kind of hardware you're running on? Are you able to deploy any other VM's without issues? Did you perform any actions in Xen Orchestra UI after appliance was imported?
Template image doesn't have anything set in blocked-operations params and there shouldn't be any reason why import procedure would add any of those. I'm also not able to reproduce this issue by importing the image with same method as described in readme.
fresh installation of XCP-ng 8.1 and of the VM on a different system I used for testing, then left like that for a month or so and now moved the disks over to this system (I didn't want to redo the ZFS storage setup).
Since it was still trying to use the other system's ethernet controller it was inaccessible
I've installed another VM and had a look in the Xen Orchestra interface, In the VM page, Advanced tab it shows "Protect from accidental deletion" and "Protect from accidental shutdown" enabled (green switch).
I disabled them, the blocked-operations
was removed and now I can delete it from both command line and Xen Orchestra.
I don't remember setting them but it's possible I did it and forgot, so this is my own problem. Closing
Ah, right. That makes sense. Good that you figured it out.
I asked some questions in the forum, and the right command to actually remove the block from SSH/CLI is
xe vm-param-cleaner uuid=<vm_uuid> param-name=blocked-operations
Yup, it’s more XCP-ng management thingy rather than related to this script/appliance. Of course if you can verify that those parameters were added during import, then there’s something i need to check and fix.
It was just to give closure to the question in case someone else finds it when searching a solution for the same problem in the future. As I said I don't believe this is your problem anymore.
I recently had a similar issue where I couldn't hard reboot my accidental-shutdown-protected VM running XOCE. I kept getting "You attempted an operation that was explicitly blocked (see the blocked_operations field of the given object)." I was able to fix it by constructing these commands in the CLI over SSH:
View present state of blocked operations
xe vm-param-get uuid=X param-name=blocked-operations
_(unknown operation): true; suspend: true; pause: true; hard_shutdown: true; hard_reboot: true; clean_shutdown: true; cleanreboot: true; destroy: true
Unblocking takes two steps.
xe vm-param-set uuid=X blocked-operations:hard_reboot=false blocked-operations:clean_reboot=false blocked-operations:hard_shutdown=false blocked-operations:clean_shutdown=false
That set the fields to false, but they are still there - we must clear them out.
xe vm-param-clear uuid=X param-name=blocked-operations
_The value given is invalid field: blockedoperation value: (unknown operation)
An error is reported for the placeholder entry "(unknown operation)", but the fields which were marked as false are now removed.
Another check on the state of blocked-operations returns this: (unknown operation): true; suspend: true; pause: true; destroy: true
Now you can reboot the VM
xe vm-reboot uuid=X
Hoping this helps someone with a stuck VM...
I have imported the Debian appliance using the script as mentioned at the end of the README, but I can't delete the VM nor shut it down nor do anything else from the XCP-ng console
it fails with
You attempted an operation that was explicitly blocked (see the blocked_operations field of the given object).
which is caused by this setting of the VM
blocked-operations (MRW): (unknown operation): true; suspend: true; hard_shutdown: true; hard_reboot: true; clean_reboot: true; pause: true; clean_shutdown: true; destroy: true
I've tried editing that with
xe vm-param-set
but even if I set all of them as false I can't shut down the VM or delete it and still complains with the same error message as above.So, how can I delete the VM?