First of I'm fairly new to xen vm technology so sorry in advance if I use the wrong vocabulary. So what happened is I took a snapshot from my vm, after a while a cronjob tried to create a second snapshot which failed since the LVM partion had not enough space. I deleted the manual snapshot from with the XCP-ng Center. But the space was not released.

I used lvs and this is what I get (formatted for better readability) :

LV VG Attr LSize ...
MGT VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe -wi-a----- 4.00m
VHD-9f6e2f19-1d88-4c26-8de8-9da27c9a99c6 VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe -ri-ao---- 346.50g
VHD-f0e775ff-5b43-497d-acbb-419874db1bb1 VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe -wi-ao---- 350.69g
0983d936-77c9-f18a-0014-89b326963425 XSLocalEXT-0983d936-77c9-f18a-0014-89b326963425 -wi-ao---- <5.46t

The dots columns are Pool Origin Data% Meta% Move Log Cpy%Sync Convert those are all empty. I'm fairly certain that VHD-9f6e2f19-1d88-4c26-8de8-9da27c9a99c6 is the LV which needs to be removed.

I used xe vdi-list and found the vdi corresponding to that LV. This vdi has no vbd assigned and sr-uuid was <not in database>, and name-label was base-copy. I tried xe vdi-destroy uuid=$th_uuid. But it failed with the message: "Can not remove vdi because it is not manged by the system" (I'm not sure this was the exact wording) I also tried to directly remove the LV but it failed due being in use.

I then did xe vdi-forget uuid=$the_uuid hoping that would free the resources / unblock th LV. The VDI is now gone but the LV remains.

I tried lvremove -f /dev/VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe/VHD-9f6e2f19-1d88-4c26-8de8-9da27c9a99c6 --config global{metadata_read_only=0}

But it still fails for being used. When I do lsof /dev/VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe/VHD-9f6e2f19-1d88-4c26-8de8-9da27c9a99c6 It returns (again formatted)

tapdisk 28534 root 18r BLK 253,3 0t4218880 39811683 /dev/mapper/VG_XenStorage--9f728af0--0817--f908--63ae--5a06ce6914fe-VHD--9f6e2f19--1d88--4c26--8de8--9da27c9a99c6

When I do an lsof /dev/VG_XenStorage-9f728af0-0817-f908-63ae-5a06ce6914fe/VHD-f0e775ff-5b43-497d-acbb-419874db1bb1 (the LV I don't whant to touch) it shows:

tapdisk 28534 root 17u BLK 253,2 0t4327936 39810421 /dev/mapper/VG_XenStorage--9f728af0--0817--f908--63ae--5a06ce6914fe-VHD--f0e775ff--5b43--497d--acbb--419874db1bb1

Note the same PID, which makes me thing I should not just kill that process.

So any advice on how to deal with that Situation is highly appreciated and if you need more information just let me know.

1 Answer 1


I'm not sure how Xen would work(I'm also new to this kind of thing), I used to remove a logical volume, for example the swap partition:

I would do the following:

# lvremove /dev/mapper/vg0-swap

but in case it is some other volume I guess you should do the following first:

first, umount the logical volume:

# umount /dev/mapper/vg0-var

and then:

# lvremove /dev/mapper/vg0-var
  • 1
    Unfortunately umount reports the device as not mounted. Also normally the -f parameter should remove the lv even when mounted. But thanks for your input.
    – bluefish
    Feb 13, 2022 at 19:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .