Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    semarieS
    @flakpyro yes. thanks for your test and to reporting the problem anyway. it is helping us to see what kind of problems users could have.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    That's the flag then, not XAPI refusing. Which is the easier of the two to get out of. Nothing showed up in Advanced because XO only lights that toggle when all seven of its stop operations are blocked: clean_reboot, clean_shutdown, hard_reboot, hard_shutdown, pause, suspend and shutdown. Yours has four of them, so the toggle already reads as off and there's nothing to switch off. Turning it on and then straight back off does clear them, though. I tried that on a test VM here, on XO 5.205.2. The first click set all seven, the second removed all seven, and suspend was back in allowed-operations. Your destroy entry is the separate "Protect from accidental deletion" toggle just above it, and that one will show as on. Turning the shutdown one on and off leaves it alone, so keep it if you want it. If you'd rather not touch the others, this removes just the one key: xe vm-param-remove uuid=<vm-uuid> param-name=blocked-operations param-key=suspend I ran that one too, on 8.3, and suspend came back in allowed-operations straight away with the VM still running. What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell?

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    acebmxerA
    @dsauce To test your theory out on my issue i just tried to disable CBT on XOA side and one vm gave me this error... vdi.set { "id": "11286a97-b773-4ec4-a0b7-464ab87254ca", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "a52fe4ab-edc2-4975-a118-f6db84435379" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "a52fe4ab-edc2-4975-a118-f6db84435379" ] }, "message": "UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" } Another vm.. vdi.set { "id": "966fe072-4865-48a2-867a-0eb59b23dcc7", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ] }, "message": "UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" }

  • Our hyperconverged storage solution

    50 Topics
    796 Posts
    olivierlambertO
    Great, thanks for the feedback!

  • Non-English speakers

    37 Topics
    135 Posts
    AtaxyaNetworkA
    Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça. Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution. Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks). Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à : 2 disques + 2 CD ou 3 disques + 1 CD + HTTP (Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique). Je vais fouiller encore un peu, mais sans certitude d'un contournement possible. (et je regarde pour ajouter le CDlabel)