Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    F
    @andriy.sultanov Thanks I ran that second script on the master and it did indeed find entries: ./snapshot-fixer.py rewrite INFO:root:Check HA... INFO:root:Shutting down xapi... INFO:root:Regenerating database... INFO:root:The VM d6befe36-fea7-04f3-25f1-feada684702b has Ref:9 as its "snapshot_of" value, changing to null. INFO:root:The VM e013d9ed-63b1-9c9f-a228-d48a6047688c has Ref:89 as its "snapshot_of" value, changing to null. INFO:root:The VM 060df7ee-8af4-4c93-8265-bfa3024ccacd has Ref:1 as its "snapshot_of" value, changing to null. INFO:root:The VM da7b6ff6-d722-2120-7cc4-a1e0038a216e has Ref:307 as its "snapshot_of" value, changing to null. INFO:root:The VM 4178b057-efee-427e-bcad-67323419ac7a has Ref:9 as its "snapshot_of" value, changing to null. INFO:root:The VM 8d624e49-ca99-4af6-b17c-38cad0646194 has Ref:1 as its "snapshot_of" value, changing to null. INFO:root:The VM dc72da43-f144-3343-5ee5-a0dbffd209f6 has Ref:251 as its "snapshot_of" value, changing to null. INFO:root:The VM e8c6376b-49e1-422b-551a-35420f70af2a has Ref:8 as its "snapshot_of" value, changing to null. INFO:root:The VM 25eb14ab-e943-0d18-2137-c681e1191346 has Ref:11 as its "snapshot_of" value, changing to null. INFO:root:The VM 6f819166-b008-4a03-a692-fcbd75018be9 has Ref:1 as its "snapshot_of" value, changing to null. INFO:root:The VM 9d1a57e8-3531-4b55-9682-f775215866df has Ref:1 as its "snapshot_of" value, changing to null. INFO:root:The VM 0ac88f7c-d79b-281e-cf1f-a2392ba594ed has Ref:29 as its "snapshot_of" value, changing to null. INFO:root:The VM 1f3541c4-8c81-4959-9cbe-edbec9481220 has Ref:1 as its "snapshot_of" value, changing to null. INFO:root:Writing database to /var/lib/xcp/state.db INFO:root:Starting up xapi... after which it shows clean now: ./snapshot-fixer.py dry-run INFO:root:Regenerating database... However i am still getting the same error when trying to run leaked_vbs: ./leaked_vbds Traceback (most recent call last): File "./leaked_vbds", 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:29']

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    henri9813H
    Hello. Problem Solved. My case: i have a pool of many hypervisors with only local storage, no shared SR ( yes it's not recommanded, i stopped doing this and i'm currently migrating everything to pool with Shared storage ). Yesterday, i removed two hosts ( host 3 & host 4 ) whith local storages SR attached ( LVM ). In XCP-NG, i "forgot" Host 3 & host 4, the hosts from the pool, but it doesn't forge the associated SR ! But Live migrating a VM from host 1 to host 2 ( of the same pool ) bot with local SR, FAIL because there is no SR plugin attached of Local Storage 4 ( hosts 4 ) neither Local storage 3 ( host 3 ). So, i also forget theses 2 SRs and now it's ok. i don't understand why SR not connected to anyone can prevent migration about vm from other to other sr.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    K
    @poddingue Bug report filed as requested — https://github.com/xcp-ng/xcp/issues/825 — and tagging @Team-Storage per your suggestion. Full evidence bundle is attached to the issue (versions, sweep output, vhd-util vs xe comparison, SMlog). Summary of what I found: One correction to the mechanism, and I think it matters. The recap describes is-a-snapshot being flipped to true. On my system that isn't what's happening — is-a-snapshot is false on every affected VDI. The field being wrongly written is snapshot-of, which is getting populated on base disks that aren't snapshots at all. XO's disappearing-disks symptom is consistent with either (it filters on a non-empty snapshot-of), but if the storage team is hunting for a bad is-a-snapshot write, that may be the wrong field. Every affected VDI here looks like: is-a-snapshot: false <-- correct snapshot-of: <populated with an unrelated VDI's UUID> <-- wrong A VDI that is a snapshot of itself. The clearest single artifact: uuid: 806f7f42-083f-4a40-b3f1-0700d00bab5a name-label: WinSrv2022SHB_Disk1_Data is-a-snapshot: false snapshot-of: 806f7f42-083f-4a40-b3f1-0700d00bab5a <-- itself snapshot-time: 20260709T11:19:15Z sm-config: vhd-parent: c86e3247-... <-- bears no relation to the snapshot-of value No valid code path produces snapshot-of = self. Whatever writes this field isn't validating the target. It's still actively corrupting new VDIs — this is not just legacy damage. That self-referential VDI was created 2026-07-09, a week after my patch + reboot. Sweeps 9 days apart went from ~180 → 191 affected VDIs on one SR, and a fourth anchor UUID appeared that didn't exist in the first sweep. Newly created VHDs keep landing in the affected set. So "stop it happening again" is the urgent half of the two-part fix, at least in my case. The bogus targets cluster onto a tiny anchor set, and the anchors point at each other: Count Anchor 97 937c3945 (→ a893fdb4) 50 a893fdb4 (→ ea150883) 37 ea150883 7 806f7f42 (→ itself, new since Jul 9) That looks less like corrupted lineage and more like the field being filled from an incorrect/uninitialised source. On-disk VHDs are completely healthy. vhd-util check says valid, parent locators are consistent, GC reports no work. The two VDIs the DB calls parent/child are, on disk, siblings under a common parent. The corruption is purely in the XAPI database — which is good news for recoverability. The VDI_IN_USE is not a real lock. current-operations is empty, xe task-list is empty, no tapdisk holds it. VM.start fails because it's walking a snapshot relationship that doesn't exist on disk. Reproduces from xe on the pool master with XO entirely out of the path — which is why I filed against xcp-ng/xcp rather than the XO tracker. Versions: XCP-ng 8.3.0, xapi 26.1.11 (xapi-core-26.1.11-1.2), sm-3.2.12-17.9, sm-fairlock-3.2.12-17.9, blktap 3.55.5-9.1, build 20260618. I have not attempted to bulk-clear the fields — on-disk data is intact and I'd rather not do a mass write against the XAPI DB on a live SR without guidance. Backing store snapshotted as a safety net. Happy to run whatever diagnostics would help. And +1 to the hand-grenade feeling — the affected set growing on its own is the part that worries me. kismetgerald created this issue in xcp-ng/xcp open XAPI DB corruption: base VDIs mass-stamped with invalid `snapshot-of` (incl. a VDI that is a snapshot of *itself*), blocking `VM.start` with VDI_IN_USE — and still ongoing #825

  • 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