[2.9.2] Commissioning does not collect correct storage information

[Sandor Zeestraten]

MAAS version 2.9.2

When commissioning servers with different storage types (SSDs in a virtual disk behind RAID controller, NVMes and HDDs), but everything shows up tagged as SSD.

The commissioning step 50-maas-01-commissioning is generating _incorrect_ storage info such as a random serial and it’s missing the rpm for the virtual disk (behind RAID controller) and the HDDs.

The commissioning step maas-lshw generates the correct info, but is not used.

I have added screenshot of storage after commission and outputs from both 50-maas-01-commissioning and maas-lshw here: https://discourse.maas.io/t/how-to-work-with-storage-tags/4344/3?u=szeestraten

See https://discourse.maas.io/t/how-to-work-with-storage-tags/4344 for conversation

[Lee Trager (ltrager)]

MAAS collects all hardware information from LXD. MAAS knows that a disk is an SSD if RPM is 0. lshw is only used to automatically generate tags.

Could you check if this is fixed in the latest version of LXD? You can do that in a deployed environment or ephemeral with the following

sudo snap refresh --channel=latest/edge lxd
sudo apt-get install -y jq
curl -G --unix-socket "/var/snap/lxd/common/lxd/unix.socket" "lxd/1.0/resources" 2>/dev/null | jq

If RPM or any other information is incorrect in the latest version please report it as a bug to the LXD team at https://github.com/lxc/lxd/issues/new

[Sandor Zeestraten (szeestraten)]

@ltrager, thanks for the info. It seems that latest version of LXD is also not working. I have added bug upstream here so the MAAS team can follow up: https://github.com/lxc/lxd/issues/8718

In the mean time, how will this be fixed in MAAS? Default LXD version I got when commissioning with 20.04 was 4.0.5. Will the upstream fix be applied to 4.0/stable of LXD?

[Sandor Zeestraten (szeestraten)]

@ltrager, see response from @stgraber that it looks like udev/systemd issue: https://github.com/lxc/lxd/issues/8718#issuecomment-828479580

How would you like to proceed with this bug?

[Sandor Zeestraten (szeestraten)]

Update: I tried deploying Ubuntu 21.04 which is running systemd 247 (247.3-3ubuntu3) and the issue remains.

udevadm info /dev/sdm : https://paste.ubuntu.com/p/HSfv3JJjpf/

lxc query /1.0/resources | jq .storage.disks[-1]
{
  "block_size": 4096,
  "device": "8:192",
  "device_id": "wwn-0x5000c500c3098e65",
  "device_path": "pci-0000:3b:00.0-sas-exp0x500304801eed80ff-phy11-lun-0",
  "firmware_version": "SN02",
  "id": "sdm",
  "model": "ST16000NM001G-2K",
  "numa_node": 0,
  "partitions": [],
  "read_only": false,
  "removable": false,
  "rpm": 0,
  "serial": "5000c500c3098e65",
  "size": 16000900661248,
  "type": "scsi"
}

[Lee Trager (ltrager)]

I've added systemd to the bug. They will have to fix it on their side so MAAS can get the correct data.

[Sandor Zeestraten (szeestraten)]

@ltrager, apologies if I'm wrong, but https://bugs.launchpad.net/systemd says it tracks bugs on Github. Did you mean to add https://bugs.launchpad.net/ubuntu/+source/systemd instead?

[Dan Streetman (ddstreet)]

systemd doesn't report any 'E:ID_ATA_ROTATION_RATE_RPM' value for the SCSI drive, because it's a SCSI drive, not an ATA drive.

[Sandor Zeestraten (szeestraten)]

1. The disks are not SCSI (Model: ST16000NM001G, see https://www.seagate.com/gb/en/enterprise-storage/exos-drives/exos-x-drives/exos-x16/), but I suspect they are identified as such due to the HBA?
2. The bug watcher has wrongly identified that LXD has releases a fix. Please remove that.
2. It sounds like MAAS needs to fix the way it identifies and determines the type of disk.

[Dan Streetman (ddstreet)]

> The disks are not SCSI, but I suspect they are identified as such due to the HBA?

yes, your system sees the disks as scsi:

> "type": "scsi"