virtualbox.org

I have been using Virtualbox on an Ubuntu 12.04 (64bit) host for several years now with no problems. One of the VMs I created was Windows XP Pro (32bit) which I keep some older applications on. I had to wipe out Ubuntu 12.04 and install Windows 8.1 (64bit) on the laptop, and soon afterward installed Virtualbox on it. I had a Windows 7 VM guest (32bit) as well I was using on my Ubuntu host and I was able to add it fine, and boot it up in the Windows 8.1 Virtualbox. However, after adding the Windows XP Pro VM to the Windows 81 Virtualbox it shows the .vmdk as (Normal, Inaccessible). If I then try to boot it up it throws an IProgress error and fails to boot. If I try to clone it it gives an error saying there is an inconsistency between the grain table and backup grain table and fails. I tried this with all the other Windows XP Pro VM backups I had and the same thing happens to all of them, which leads me to believe there is probably something wrong with Virtualbox on Windows 8.1 host as this was working fine on the Ubuntu 12.04 host just last week. At this point I dont have another Ubuntu 12.04 host to try to load the VMs on to try and I cant wipe out my Windows 8.1 installation. Anyone have any idea what is causing this? It's the same laptop - just different OS for the host. Thanks

VM log of error session please. Right click the VM in the GUI. Select "Show Log". Save "VBox.log" to a file. Compress that file and attach it to a message here. Make sure the VM is fully shut down before taking a log.

mpack wrote:VM log of error session please. Right click the VM in the GUI. Select "Show Log". Save "VBox.log" to a file. Compress that file and attach it to a message here. Make sure the VM is fully shut down before taking a log.

Thanks. VBox.log attached.

Well, not your fault but that log is totally useless - it's only a dozen or so lines and says nothing useful that I can see.

There's another log in the folder called "VBoxStartup.log". COMPRESS THAT FILE PLEASE and then attach the zip here.

Incidentally, how are you transferring and using those VMDKs? Why are they VMDKs in the first place, rather than the normal VDI?

mpack wrote:Well, not your fault but that log is totally useless - it's only a dozen or so lines and says nothing useful that I can see.

There's another log in the folder called "VBoxStartup.log". COMPRESS THAT FILE PLEASE and then attach the zip here.

Incidentally, how are you transferring and using those VMDKs? Why are they VMDKs in the first place, rather than the normal VDI?

Good question. To be honest, I've had this VM for many years (at least 5 or 6, and maybe more) and can't recall the reason why it was vmdk. All the other VMs I have are vdi now that you mention it. I have attached the log you requested in zip format.

Weird. The startup log shows that the VM started up perfectly - no errors. This essentially covers the period that in a physical PC starts when power is switched on, and ends when the PC starts to read the disk and boot the OS.

But, it clearly must terminate right after that - presumably when it attempts to mount the guest's disk.

The error message about "grain table inconsistencies" on the face of it means that the file is corrupted (*), but I was hoping that was a false positive due to something else I'd see in a log file. That seems not to be the case. Do you have a backup of this VMDK?

You might learn more if you tried to clone this VMDK using CloneVDI. If it also tells you that the grain table has problems then you can pretty much believe it.

(*) "Grain" is the term used in the VMDK specification for the unit of allocation in a dynamic image, i.e. blocks allocated as the file grows. The grain table tracks where the blocks are in the file (same as the block table in a VDI). An "inconsistent grain table" means that the grain table is saying something that can't be true, e.g. that block N can be found somewhere beyond the end of file. You might get this corruption e.g. if you truncated a VMDK by incorrectly downloading it, or by transporting it on FATx media (which has a 4GB file size limit).

Awesome! That CloneVDI did the trick. I was able to convert the vmdk to vdi with no problem and then was able to boot the new vdi disk. My hat's off to you for a superb program!

Hmm. I was expecting it to put up more of a fight than that - but I'm happy for you!