Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    A
    @rzr Updates installed and running. I also run the snapshot-fixer.py and xapi_leaked_vbds.py scripts... The fixer found/fixed lots on many pools... @andriy.sultanov I have the same error... On one pool, I ran snapshot-fixer.py and it fixed about 50 of them, but xapi_leaked_vbds.py still returns an error (before and after fix): Traceback (most recent call last): File "./xapi_leaked_vbds.py", line 23, in <module> snap = xapi.VM.get_parent(snap) File "/usr/lib/python3.6/site-packages/XenAPI.py", line 317, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.6/site-packages/XenAPI.py", line 198, in xenapi_request result = _parse_result(getattr(self, methodname)(*full_params)) File "/usr/lib/python3.6/site-packages/XenAPI.py", line 292, in _parse_result raise Failure(result['ErrorDescription']) XenAPI.Failure: ['HANDLE_INVALID', 'VM', 'Ref:119']

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    Thanks for coming back and writing up what fixed it. I don't know why a disconnected SR blocks a migration between two other SRs. My guess, and it's only a guess, is that VM.migrate_send runs an SR.scan across every SR in the pool rather than just the source and the target, so one leftover SR with no plugin attached is enough to kill the whole prepare step. There is a troubleshooting entry with your symptom at https://docs.xcp-ng.org/troubleshooting/common-problems#unable-to-live-migrate-vdi-between-srs, but it only lists the empty xapi-pool-ca-bundle.pem cause, not orphaned SRs left behind after a host-forget. So it wouldn't have helped you anyway. Might be worth a mention to @Team-Storage, both to confirm the mechanism and maybe to get your case added to that page.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    poddingueP
    I had a look at your screenshots. The Topology dropdown is greyed out with a tooltip saying Requires admin permissions, so this looks deliberate rather than broken: the field seems gated on being a full XO admin, not on being admin of your own resource set. I couldn't find an existing report asking for it to respect resource-set admin instead, so feedback.vates.tech is probably the right place to raise it. It would carry more weight coming from you, with those screenshots, than from me. I don't know whether the ACL rework changes any of this, so I wouldn't count on it until someone who works on it says so. Might be worth a mention to @Team-XO-Backend, since where that permission gate lives is really their call.

  • Our hyperconverged storage solution

    49 Topics
    764 Posts
    J
    OK so that resource was a pain and did not want to give up, so I restarted the host. Migration is running good now.

  • Non-English speakers

    36 Topics
    117 Posts
    B
    Merci beaucoup pour vos retours ! @nathanael-h : C'est l'étape suivante !!! J'ai découvert cluster API le mois dernier et j'ai déja testé sur d'autres plateforme ! ça déchire !!! Je ne savais pas qu'il y avait un support de XCP-ng ! Je finis ma série d'article pour une installation classique et je bascule sur cluster API ! @ataxyanetwork Merci pour ton repo. Je vais regarder ça