Any known problems with .VHD / vhd snaps / win2003 / sata?

[940607]

solved.
Found in windows logs: device did not respond within the timeout period
The rest was easy to find
https://communities.vmware.com/message/838888#838888

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk]
"TimeOutValue"=dword:0000003c

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\symmpi\Parameters]
"DisableDisconnects"=dword:00000001
"MaximumSGList"=dword:000000ff

Having many snapshots and/or "host i/o cache" checkbox cleared increases the chance to get this error on win2003.

=====================
filesystem and or files get corrupted randomly when installing huge applications
I use VHDs to later attach them to host. VHDs created on host with Windows tools, not VBoxManage

vbox: 4.3.14
host: win7 pro
guest: win2003 sp2 x86

sata driver: Intel Matrix Storage Driver: http://downloadmirror.intel.com/15449/e ... 70_enu.exe

disks:
win2003.vdi + snapshots, IDE, normal, autoextend, NTFS, C:\
wccache.vhd, SATA port 0, writethrough, fixed, NTFS , C:\wccache
ibm.vhd + snapshots, SATA, port 1, normal, autoextend, NTFS , C:\ibm

[mpack]

Moved to "Windows Guests".

I don't see a coherent question in there. Please try to explain more clearly what your problem is.

As to known problems:

• Snapshots are inherently dangerous and non-portable. A non-expert copying a snapshot chain from another VM platform will always result in a corrupted disk, but the corruption is far from random - all later data writes are lost.
• VHDs do have a known problem - they put their "header" at the end of the file, meaning it gets overwritten as the file grows. If you have any kind of software or hardware failure then the VHD is effectively destroyed along with all contents.
• Fixed size virtual disks are a poor choice. The temptation is to make them too small - or too big. One causes congestion and poor performance in the guest, the other causes the same problem in the host. The advantage of "dynamic" (with a high enough ceiling) is that the disk finds its own optimal working size.

[940607]

The problem is filesystem corruption. I'm trying to narrow the list of candidates. Most likely it's the Intel SATA driver, because right now I reattached the vhd to IDE and the installation goes further.

[940607]

Upgrade to iata82_enu.exe didn't help. Checked twice: with SATA installation fails, with IDE it succeeds

[940607]

I've heard some drivers don't like big RAM. Maybe it's my case: I have 4096Mb RAM on guest

[mpack]

Why are you using a SATA driver in the guest at all?

[940607]

Because IDE has a limit of 4 devices, doesn't it?

[940607]

Reducing RAM didn't help.

[mpack]

Because IDE has a limit of 4 devices, doesn't it?

Per controller, that's correct. And Win2K3 will only support one controller using the default chipset. Why is that an issue? As far as I can see you only have 3 hdds plus (I assume) the CD/DVD.

RAM should be irrelevant to a device driver. It gets whatever RAM the OS allocates to it. It wouldn't even know how much more RAM the PC had, so how could it be affected? I suggest that you avoid reading BS advice - and avoid flopping around like a landed fish! I'm still waiting for that clear description of the problem. "Filesystem corruption" doesn't mean much.

[940607]

For example, the installer says: can't open foo.zip. When I navigate to it and open in a viewer, there's no "PK" header. When I revert to the last snapshot, the file is OK

[mpack]

Have you tried running a filesystem check inside the guest? In fact it would do no harm to check the host as well.

[aeichner]

Can you check whether the VHD metadata is corrupt? You can do this with

Code: Select all

VBoxManage.exe internalcommands repairhd -dry-run -format VHD <path to VHD image>

[940607]

Have you tried running a filesystem check inside the guest? In fact it would do no harm to check the host as well.

I did that several times. Once, when a folder became inaccessible during the installation, it fixed the error. But more often the file contents get corrupted. In that case chkdsk prints no error

[940607]

RAM should be irrelevant to a device driver.

There's a known bug in Win2003 AMD network card driver, preventing it from starting with 5Gb RAM, just saying.

[940607]

Install fails in the same place with SCSI controller. What the hell? Maybe it's because "cache io ops" checkbox cleared by default?