Simultaneous I/O timeout on both virtual disks (sda + sdb) causing read-only filesystem in Linux VM

Simultaneous I/O timeout on both virtual disks (sda + sdb) causing read-only filesystem in Linux VM
Parallels Desktop version: 26.3.1 (57396) Host: MacBook Pro M1 Max VM storage: Samsung T7 external SSD (USB 3.2 Gen 2), 35 GB free Guest OS: Ubuntu (GNOME), kernel reports EXT4 on /home (sdb1) Virtual disks:Fixed-size (not expanding), two virtual disks -- sda (boot/EFI), sdb (/home)

Problem
While running a Linux VM under normal workload (PyCharm, terminal), both virtual disks simultaneously hit I/O timeouts, causing the EXT4 journal on /home to abort and the kernel to remount the filesystem read-only. This has happened twice since updating to Parallels 26.3.1 (57396) It never occurred before this update

The fact that both sda and sdb fail at the same second rules out guest-side filesystem corruption -- this is a host-side or hypervisor-level I/O stall.

Kernel log (journalctl -b, relevant lines only)
Apr 27 09:57:36 kernel: sd 2:0:0:0: [sdb] tag#21 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=31s
Apr 27 09:57:36 kernel: sd 2:0:0:0: [sdb] tag#21 CDB: Write(10) 2a 00 07 50 1f 98 00 00 60 00
Apr 27 09:57:36 kernel: I/O error, dev sdb, sector 122691480 op 0x1WRITE) flags 0x9800 phys_seg 12 prio class 2
Apr 27 09:57:36 kernel: Aborting journal on device sdb1-8.
Apr 27 09:57:36 kernel: EXT4-fs error (device sdb1): ext4_journal_check_start:87: Detected aborted journal
Apr 27 09:57:36 kernel: EXT4-fs error (device sdb1) in ext4_reserve_inode_write:6347: Journal has aborted
Apr 27 09:57:37 kernel: EXT4-fs error (device sdb1) in ext4_dirty_inode:6552: Journal has aborted
Apr 27 09:57:37 kernel: EXT4-fs error (device sdb1): ext4_journal_check_start:87: Detected aborted journal
Apr 27 09:57:37 kernel: EXT4-fs (sdb1): Remounting filesystem read-only
Apr 27 09:57:37 kernel: sd 0:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=30s
Apr 27 09:57:37 kernel: I/O error, dev sda, sector 5914640 op 0x0READ) flags 0x80700 phys_seg 1 prio class 2
Apr 27 09:57:37 kernel: I/O error, dev sda, sector 5914656 op 0x0READ) flags 0x80700 phys_seg 3 prio class 2
Apr 27 09:57:37 kernel: I/O error, dev sda, sector 5914736 op 0x0READ) flags 0x80700 phys_seg 18 prio class 2
Apr 27 09:57:37 kernel: I/O error, dev sda, sector 5914880 op 0x0READ) flags 0x80700 phys_seg 2 prio class 2

Impact

• /home (sdb1) becomes read-only, all applications fail (PyCharm, GNOME settings, etc.)
• Recovery requires VM restart + manual e2fsck from recovery mode
• Potential data loss from corrupted orphan inodes (e2fsck had to repair)

Steps to reproduce
Not deterministic -- happens during normal workload, no heavy disk I/O on the guest side. External SSD had 35 GB free, no heavy macOS I/O at the time. The same setup worked without any I/O issues on earlier Parallels versions.

Expected behavior
Virtual disk I/O should not time out under normal guest workload with sufficient host resources.

 

I have had a very similar experience, here's my agent's workup:

Parallels Linux Guest Virtual Disk Timeout Resulting in Filesystem I/O Errors

I am investigating what appears to be a virtual disk I/O timeout issue affecting a Linux guest running under Parallels.

### Environment

- Host: Apple Silicon Mac
- Hypervisor: Parallels Desktop
- Guest: Debian Linux
- Storage: VM located on an external SSD (needing two images to get around the 2TB image limit)
- Guest configured with multiple virtual disks

### Observed Behaviour

The Linux guest was running normally under sustained write activity when the following errors appeared:

text FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK I/O error, dev sdb, WRITE Buffer I/O error on device sdb1 EXT4-fs warning (device sdb1): potential data loss

The affected device was the second virtual disk (sdb).

The guest itself remained operational, however the application performing the writes received fatal I/O errors and terminated.

### Additional Observations

- No guest OOM condition was present at the time.
- No host reboot occurred.
- No obvious SSD disconnect or eject event was observed.
- APFS verification of the external SSD completed successfully.
- The guest filesystem did not appear to be permanently remounted read-only.
- Subsequent simple write tests to the filesystem succeeded after the event.

### Similarity to Existing Reports

The failure signature appears very similar to reports describing:

text hostbyte=DID_TIME_OUT I/O error on virtual disk EXT4 warnings or journal issues

occurring inside Linux guests running under Parallels.

### Questions

1. Are there known issues involving virtual disk timeouts under sustained write workloads?
2. Are there known differences between single-disk and multi-disk Linux guest configurations?
3. Are there recommended Parallels settings for Linux guests performing heavy fsync/synchronous write activity?
4. Are there host-side logs or diagnostics that can help determine whether the timeout originated in the virtual disk layer, storage layer, or guest layer?
5. Can we run VMs direct from full SSD, avoiding APFS & image files & size restrictions?

Thanks