TopoLVM is quite aggressive at grabbing storage and this should be more explicitly advertised/configurable

[ElCoyote27]

Hi all,
Was playing with SNO and Assisted Installer over the weekend and I got bitten a little by TopoLVM. I wonder if it could be made a little less 'aggressive' or if perhaps its behaviour could be a little more advertised.

Here's what happened.. I am turning an unused MacOS Intel Mac Pro into a single node openshift. Since I wanted to keep dual-booting the machine, I proceeded that way:

1. install macOS on the Apple SSD.
2. remove that SSD and add two more SSDs (one for OCP and one for TopoLVM).
3. use Assisted Installer and the discovery ISO to install OCP + TopoLVM with it.
4. put the Apple SSD Back.

At this point, I had a working Mac Pro with:

• SSD0 : MacOS (shows up as /dev/sda)
• SSD1 (2Tb): TopoLVM 'vg1', shows up as /dev/nvme0n1
• SSD2 (1Tb): OCP 4.12, shows up as /dev/nvme1n1

Then things went downhill from there:

• I wasn't happy with the naming ('vg1') so I edited lvmclusters/lvmcluster-sample with a new name ('datavg').
  As a result, TopoLVM grabbed /dev/sda2, wiped MacOS and added 'datavg' with a /dev/sda2 PV.

seeing that, I edited lvmclusters/lvmcluster-sample and removed the 'datavg' section. Then I proceeded to re-image /dev/sda with the BM backup I had taken a few hours earlier.

When I booted back into RHCOS, TopoLVM woke up again, carved a PV out of /dev/sda2 and added it to 'vg1', then it extended the thinpool onto /dev/sda2.

For the next 30 minutes, I tried to take /dev/sda2 out of the LVM2 config (thin pools cannot be shrunk, unfortunately) so I ended up uninstalling the operator and tried to get rid of the "nvme0n1+/dev/sda2" 'vg1'.

In the end, I ended up destroyin my SNO install, restored /dev/sda (MacOS) and installed a fresh SNO node with 4.12 and ToopoLVM (I will not try to change the name of the vg, this time...)

That's only my 2c but the overall experience was that TopoLVM was quite aggressive and not too configurable:

• it grabbed the MacOS disk without asking, even though there were valid partitions there.
• I am now worried that for whatever reason TopoLVM might wake up and nuke MacOS again (is there a way to blacklist /dev/sda?).

I would love to see if:

• the name of the original vg (vg1) can be changed using custom manifests in the discovery ISO for an SNO node.
• if some disks can be added to an 'exclude' list so that TopoLVM always ignores them.

[toshipp]

Hi @ElCoyote27
I assume you used lvm-operator. If so, could you report this issue to Red Hat?
TopoLVM organization and project are NOT maintained by Red Hat. They developed lvm-operator and added topolvm to their suites solely.

[ElCoyote27]

Thank you for your feedback.
I opened https://issues.redhat.com/browse/OCPBUGS-14856
Arigato