Guest VM Enters Paused State Unexpectedly

[Flash828]

Hopefully someone can shed a bit of light on this strange problem...

Brief Description: An mkv video file is played via a network streaming device. The video file apparently has some form of corruption to it (which appears to be relevant). The file server is a VM, and at predictable points within the corrupt mkv file the VM will enter "PAUSED" state. This only occurs when this one video file is played, and it occurs whether the video is played via a desktop directly grabbing the file from the file server, or via a network streaming device (which interacts with an intermediary). In no case is any transcoding occurring, nor should any processing be done on the video file what-so-ever.

Environment:
aquarius - Physical, Core i5, Debian 6.0 Host with 8GB Physical Memory on an SSD, Virtualbox 4.0.12
Aurora - Windows 2008, File Server, VM on aquarius. Storage pools are accessed via iSCSI, presented as a device by virtualbox, on a seperate filer (orbone)
vodlx - Debian 6, Front-End to Media Streaming Devices (HTTP), VM on aquarius. File are accessed via CIFS to Aurora
streamer - Syabas Media streaming device

I can't think of a reason in the world why this corrupt video file will cause the file server VM to enter paused state *every* time at *exactly* the same positioning within the file (there are two corrupt segments). Neither of the VM's which serve the file up do any sort of processing on the video file (it is not being transcoded), and it's the file server (and only the file server VM) which enters this paused state. My guess is that somehow a bunch of retries are being generated, which is somehow tickling a bug in VirtualBox. I'm not quite sure where to take it from here though. A packet trace would probably be useful, and I'll start hunting down the exchange that I believe is causing this, however in the meantime, does anyone have any suggestions on where to take this?

The logical network paths for both scenarios look like this:
Streamer (Syabas) -> Vodlx (HTTP/VM) -> Aurora (CIFS/VM) -> Orbone (iSCSI/NAS)
Desktop (Windows) -> Aurora (CIFS/VM) -> Orbone (iSCSI/NAS)

[Sasquatch]

One reason I can think of: Host runs out of disk space or RAM. Those are reasons for a VM to pause without intervention. You will know for sure when you check the logs. Right click the VM, then you can view it's log.

[Flash828]

After doing a bit more digging in the logfiles it looks like the iSCSI connection was lost for some still unknown reason to me. There are several issues here though:

1) Other devices using targets on the same array were unaffected
2) Upon resuming the VM, reads were working okay, but writes were simply not happening. On accessing a random CIFS exported folder, I received an error saying the folder was corrupt. I was unable to do a scandisk (for whatever reason), and was forced to poweroff the VM. Upon restart, I started a scandisk which DID NOT reveal any corruption. Additionally there were writes that I know happened which apparently did not get committed to the disk at all. That sounds suspiciously like a bug, which did not gracefully handle the VM restarting.

Log file (with bogus iSCSI credentials) attached.

[Sasquatch]

Sounds like a bug in the iSCSI initiator. Since you use iSCSI with VB directly, I suggest you open a bug report (check if one exists first to avoid duplicates) in the Bugtracker (separate account needed) and attach the log.

[Flash828]

Many thanks Sasquatch. I'll see if I can reproduce the issue in some sane manner, and if so, I'll post the bug report.