I had a 2 fold problem. I have since solved the root cause outside of TrueNAS, but I believe the behavior of the 2nd problem should be considered a bug in Scale
First is that a set of 2 virtual disks from ESXi I use as a mirrored boot pool show up without Serial Numbers, By default ESXi generates these without forwarding the SN/UUID to the guest OS. For TrueNAS this means they are now detected as "duplicate". This seems like a bad idea on VMWare's side but the work-around is easy enough, Just adding disk.EnableUUID = “TRUE” to the advanced VM settings will enable it, this is retroactive to any previously created disks. Perhaps this should be added to install documentation virtualization section, or detected/notified during setup so the user can make the quick correction to the VM settings before installing?
Second, is that attempting to add a drive to an existing pool while these disks without SN's are attached prevents it from completing, even if the duplicate/blank SN drive is not part of the pool or the drive being added. I was attempting to add an SSD as a Cache VDEV to one of the existing pools. In my opinion, this action should have been able to complete without error as it was not in any way related to the duplicate SN disks.
Notes:
System is running Scale (22.12.1). It is in a virtual machine on ESXi 6.7 (both recently fully updated, including a migration from TrueNAS Core) 3 HBA's are passed through to the VM with just under 60 Disks in use.
To my knowledge these blank SN disks were always like this, Core up to at least 12 and FreeNAS from which this system was ultimately updated never complained.
I didn't try any add actions in 13 and just stopped there as a migration step to scale
First is that a set of 2 virtual disks from ESXi I use as a mirrored boot pool show up without Serial Numbers, By default ESXi generates these without forwarding the SN/UUID to the guest OS. For TrueNAS this means they are now detected as "duplicate". This seems like a bad idea on VMWare's side but the work-around is easy enough, Just adding disk.EnableUUID = “TRUE” to the advanced VM settings will enable it, this is retroactive to any previously created disks. Perhaps this should be added to install documentation virtualization section, or detected/notified during setup so the user can make the quick correction to the VM settings before installing?
Second, is that attempting to add a drive to an existing pool while these disks without SN's are attached prevents it from completing, even if the duplicate/blank SN drive is not part of the pool or the drive being added. I was attempting to add an SSD as a Cache VDEV to one of the existing pools. In my opinion, this action should have been able to complete without error as it was not in any way related to the duplicate SN disks.
Notes:
System is running Scale (22.12.1). It is in a virtual machine on ESXi 6.7 (both recently fully updated, including a migration from TrueNAS Core) 3 HBA's are passed through to the VM with just under 60 Disks in use.
To my knowledge these blank SN disks were always like this, Core up to at least 12 and FreeNAS from which this system was ultimately updated never complained.
I didn't try any add actions in 13 and just stopped there as a migration step to scale