TrueNAS Pool Import Crashing VM After Windows Update (SCSI Write Errors)

TrueNAS General
,
1

Hi everyone,

I am running into a major issue with my TrueNAS 13.0-U6.2 (for consistency) installation and I am hoping someone here has seen this before.

My setup is TrueNAS running as a VM inside VMware Workstation Pro on a Windows 10 host. Everything was working perfectly until a Windows update hit my host machine. Now, I cannot get my pool back online without the entire VM crashing.

Hardware/Setup Details**:** I am passing through several physical drives to the VM (not partitions, the entire disks).

  • 1x 2TB Seagate (ST2000LM015)

  • 2x 5TB Seagate (ST5000LM000)

  • 2x 4TB Seagate (ST4000LM024)

  • The OS is on a separate Samsung 860 PRO SSD.

After the update, I first got errors saying the physical drives were locked. I tried to re-add the storage drives to the VM config. When I boot into TrueNAS and try to import my pool (named “Main Pool”), the VM completely crashes.

I get a VMware popup saying: “The operation on file \.\PhysicalDrive1 (2/3/4/5) failed.”

What I have tried so far**:**

  1. I checked the shell and ran zpool import. It actually sees the pool and says it is ONLINE.

  2. When I try a normal import command, the console spits out a bunch of SCSI status errors and “MEDIUM ERROR (Write error)” for the drives (specifically da2).

  3. I have tried a read-only import using zpool import -o readonly=on -f -R /mnt "Main Pool". This seems to get the pool to mount without crashing the VM.

  4. When I run ls /mnt/"Main Pool", it just shows the pool name again but I am having trouble seeing my actual data folders or datasets.

  5. On the Windows host side, I have set the disks to Offline in Disk Management and used diskpart to clear the readonly attributes, but the “Operation failed” error keeps coming back as soon as the VM tries to write anything.

It feels like Windows is fighting VMware for control of the drives and ZFS is panicking when the write is rejected. Since it is happening on multiple hypervisors on this machine, I am stuck.

2

Its always like that, until its suddenly not anymore.

Passing through disks instead of the controller is a receipe for data loss.

So is using VMware workststion as a hypervisor.

It has been mentioned here and on the old forum dozens of times.

I hope you get your pool back. If you do I would change your setup ASAP.

Or destroy and recreate from backup.

1 Like
3

Thank you,

I hope that’s not a bad omen for whats about to come :frowning:

4

Unfortunately, I can’t help with the issue of the crashing VM itself. However, I would first try to determine whether this incident actually destroyed your data, or if it is “only” the VM that no longer starts.
Ideally, if you have a backup of the configuration, you could try installing TrueNAS on another system (bare metal) and check whether your pools and data are still accessible and functional.

5

Pool is healthly, there appears to be a drive in the mix with “linux data” and one corrupt listed drive

6

The fact that this is something you’re needing to do is a big red flag to me. If it actually is “doing that by itself" so to speak, that usually indicates something has gone wrong so badly that Windows itself doesn’t think it should tell the drive to write anything.

I would definitely check if the drives’ SMART data says anything (and I don’t trust drives as-is when passed through into a VM).

You mentioning it this was indicates it is a surprise to find attached a random drive with a Linux partition. Are there other VMs that are also using physical drive pass-through, and do any of them reuse a drive you’ve passed through to the TrueNAS VM? In theory VMware should prevent you from doing that, but you never know…