too many VDI/VHD per VM, how to get rid of unused ones

[robert wild]

great, seems a bug in XS 7.6 and im running it LOL

https://github.com/xcp-ng/xcp/issues/104

jaroslaw-freus created this issue in xcp-ng/xcp

closed XCP-ng 7.6 /run/lvm/lvmetad.socket: connect failed #104

[stormi]

@robert-wild I'm not sure about that. See this comment https://github.com/xcp-ng/xcp/issues/104#issuecomment-449381556

jaroslaw-freus created this issue in xcp-ng/xcp

closed XCP-ng 7.6 /run/lvm/lvmetad.socket: connect failed #104

[robert wild]

so i know my continous backup replicas arnt happening because it cant do a coalesce any of my VDI's

WARNING: Failed to connect to lvmetad

so if i run this command in my xen server 7.6

vgchange -a y --config global{metadata_read_only=0}

the next time my xen server does an auto coalesce any of my VDI's, will it become good again?

[robert wild]

think i have answered my own question -

https://support.citrix.com/article/CTX207574?_ga=2.182110311.1347118359.1579810336-430666083.1579810336

basically dom0 is protecting the source vdi until vbd operations complete but theres nothing to complete

you think this is worth a shot

[olivierlambert]

This is already something visible in Xen Orchestra, in Dashboard/Health view, we exposed all VDI attached to a control domain, it's one click to solve it.

[robert wild]

haha, i just want to kill myself

vbd.delete
{
  "id": "532ddd91-5bdb-691b-b3f2-e9382c74fde7"
}
{
  "code": "OPERATION_NOT_ALLOWED",
  "params": [
    "VBD '532ddd91-5bdb-691b-b3f2-e9382c74fde7' still attached to '1f927d69-8257-4f23-9335-7d007ed9ab86'"
  ],
  "call": {
    "method": "VBD.destroy",
    "params": [
      "OpaqueRef:1aa11b30-a64a-463a-a83d-c5095c5e9139"
    ]
  },
  "message": "OPERATION_NOT_ALLOWED(VBD '532ddd91-5bdb-691b-b3f2-e9382c74fde7' still attached to '1f927d69-8257-4f23-9335-7d007ed9ab86')",
  "name": "XapiError",
  "stack": "XapiError: OPERATION_NOT_ALLOWED(VBD '532ddd91-5bdb-691b-b3f2-e9382c74fde7' still attached to '1f927d69-8257-4f23-9335-7d007ed9ab86')
    at Function.wrap (/xen-orchestra/packages/xen-api/src/_XapiError.js:16:11)
    at /xen-orchestra/packages/xen-api/src/index.js:630:55
    at Generator.throw (<anonymous>)
    at asyncGeneratorStep (/xen-orchestra/packages/xen-api/dist/index.js:58:103)
    at _throw (/xen-orchestra/packages/xen-api/dist/index.js:60:291)
    at tryCatcher (/xen-orchestra/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/xen-orchestra/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/xen-orchestra/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/xen-orchestra/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/xen-orchestra/node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (/xen-orchestra/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/xen-orchestra/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/xen-orchestra/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues (/xen-orchestra/node_modules/bluebird/js/release/async.js:15:14)
    at runCallback (timers.js:810:20)
    at tryOnImmediate (timers.js:768:5)
    at processImmediate [as _immediateCallback] (timers.js:745:5)"
}

so its still attached to my DOM0 ie xenserver the host itself

[olivierlambert]

You need to unplug before remove it. XO does that automatically.

[robert wild]

thanks Olivier,

i thought while im having this nightmare i mightaswell update my XOA at the same time

so if XOA auto unplugs the vbd to the vdi, why is it throwing errors?

[olivierlambert]

This is a message for XO team, it should do that normally.

[robert wild]

its still there ie the host is still atached to that vdi

im thinking this is the issue why my backups wont run anymore

if not i will do it on the xen server cli, but it would be nice to know why this isnt working