A possibly obvious question I can't find the answer to anywhere—how does ovirt allocate VM disk images when a storage domain has multiple LUNs? Are these allocated one per LUN, so if e.g. a LUN runs out of space the disks on that LUN (only) will be unable to write? Or are these distributed across LUNs, so if a LUN fails due to storage failure etc the entire storage domain can be affected?
A storage domain is exactly one LVM Volume Group (VG). Disks are created from volume, which are LVM Logical Volume (LV). Each time you create a snapshot oVirt creates a new volume. So a disk may have one or more LVs in the VG.
The volumes may be extended as more space is needed. Up to 4.5, oVirt extended the volumes in chunks of 1g. Since 4.5, it uses chunks of 2.5g.
So every disk may contain multiple chunks in different size, and these may be allocated anywhere in the VG logical
space, so they may be on any PV.
To understand how the chunks are allocated, you can inspect the each LV like this:
# lvdisplay -m --devicesfile= bafd0f16-9aba-4f9f-ba90-46d3b8a29157/51de2d8b-b67e-4a91-bc68-a2c922bc7398
--- Logical volume ---
LV Path /dev/bafd0f16-9aba-4f9f-ba90-46d3b8a29157/51de2d8b-b67e-4a91-bc68-a2c922bc7398
LV Name 51de2d8b-b67e-4a91-bc68-a2c922bc7398
VG Name bafd0f16-9aba-4f9f-ba90-46d3b8a29157
LV UUID W0FAvX-EUDc-v7QR-4A2A-3aSX-yGC5-2jREeV
LV Write Access read/write
LV Creation host, time host4, 2022-12-04 01:43:17 +0200
LV Status NOT available
LV Size 200.00 GiB
Current LE 1600
Segments 3
Allocation inherit
Read ahead sectors auto
--- Segments ---
Logical extents 0 to 796:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-02
Physical extents 0 to 796
Logical extents 797 to 1593:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-03
Physical extents 0 to 796
Logical extents 1594 to 1599:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 49 to 54
Note that oVirt uses lvm devices files to prevent unwanted access of volumes by lvm
commands. To disable the devices file temporarily you can use --devicesfile=.
After extending this disk by 10g:
# lvdisplay -m --devicesfile= bafd0f16-9aba-4f9f-ba90-46d3b8a29157/51de2d8b-b67e-4a91-bc68-a2c922bc7398
--- Logical volume ---
LV Path /dev/bafd0f16-9aba-4f9f-ba90-46d3b8a29157/51de2d8b-b67e-4a91-bc68-a2c922bc7398
LV Name 51de2d8b-b67e-4a91-bc68-a2c922bc7398
VG Name bafd0f16-9aba-4f9f-ba90-46d3b8a29157
LV UUID W0FAvX-EUDc-v7QR-4A2A-3aSX-yGC5-2jREeV
LV Write Access read/write
LV Creation host, time host4, 2022-12-04 01:43:17 +0200
LV Status NOT available
LV Size 210.00 GiB
Current LE 1680
Segments 7
Allocation inherit
Read ahead sectors auto
--- Segments ---
Logical extents 0 to 796:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-02
Physical extents 0 to 796
Logical extents 797 to 1593:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-03
Physical extents 0 to 796
Logical extents 1594 to 1613:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 49 to 68
Logical extents 1614 to 1616:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 244 to 246
Logical extents 1617 to 1619:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 154 to 156
Logical extents 1620 to 1648:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 177 to 205
Logical extents 1649 to 1679:
Type linear
Physical volume /dev/mapper/0QEMU_QEMU_HARDDISK_data-fc-01
Physical extents 531 to 561
I hope it helps.
Nir