[Solved] Windows XP host/guest with raw physical disk access

[Undertow]

Ok,

Normally I use VirtualBox to run a guest XP when I'm booted into OpenSolaris but have recently installed on an XP host.

What I want to do is to perform a repair installation of Windows XP on a real physical raw disk that already has an NTFS file system with a currently unbootable XP but I'm worried about the host XP also accessing the drive at the same time. Is it enough to deallocate drive letters (and/or path) in XP disk management or do I need to do more to make sure the host XP and the guest XP don't try to access the drive at the same time?

I already have the raw disk configured in VirtualBox and if I boot an install CD image it correctly indentifies the old XP and offers to repair it. Before I go ahead I just need to be sure the host XP won't screw something up or crash if it notices the drive changing.

[Undertow]

In case the above is needlessly complicated all I am asking really is, if anyone is using an XP host with a raw physical disk attached in VB booting a Windows XP guest, how do you make sure the host XP doesn't access the guest XP disk?

Note: I know the raw disk access is listed as experimental/use-at-own-risk etc but I'm interested to hear if anyone uses it with XP-host/XP-guest and their experiences positive or negative.

[Sasquatch]

If you remove the drive letter assignment for a partition/drive, then Windows will no longer have it mounted and won't use nor see the data on it. That's the only way to use RAW Disk 'safely'.

Now, with the repair, you might get some problems with it after the repair itself, because the environment, hardware wise, is totally different. It's quite possible that the XP you're fixing will boot in the VM, but won't boot on your own system because of hardware differences (like SATA drivers and all). I'm not saying that it will happen, only that it can happen.

[Undertow]

Thanks for the reply. I'm not worried about the repaired XP not booting if put back in the machine it came from because that machine is dead for good. What I'm trying to create is a virtual version of the previous PC running under a new system.

I'll go ahead and give it a try with the drive letters deassigned (have backups of anything important).

[Sasquatch]

If you needed to activate that installation, it most likely need to be reactivated due to the hardware changes. MS might not like that, because the license is bound to hardware configuration.

[Undertow]

A repair installation will require me to re-enter the key anyway - which I have - a legit XP Pro Retail Key (ie not one I just found on the net ) not hardware locked so I should be ok. It won't be the same key on the host and the guest either.

[Sasquatch]

With retail, your fine . If MS starts to cry that it's no longer a legitimate key, call them and they should be able to fix it. That's the only thing about MS that works, their support line .

[Undertow]

Ok with the drives dismounted on the host, I booted the guest into XP recovery console - did a few basic commands to check everything looked ok (and it did). However on every subsequent reboot the host XP ran an automatic CHKDSK on the partition but said it found nothing wrong. Even though the partition is not mounted by the host XP (no drive or path assigned) it seems it will check the volumes on boot anyway (referring to it by some hex indentifier rather than a drive letter) and even though CHKDSK said it found no error it left the volume "dirty" flag set (as seen by DOS command "fsutil dirty query x:" ). Reassigning a drive letter and executing a DOS chkdsk /f fixed it.

Just to repeat there was no actual data corruption but the dirty bit got stuck set on. Have you (or anyone else) seen this before with VB and raw disk?

[vbox4me2]

To kill the check: http://www.google.nl/search?hl=nl&q=win ... tion&meta=

[Undertow]

To kill the check: http://www.google.nl/search?hl=nl&q=win ... tion&meta=

Unfortunately I don't wont to disable autochk on all drives and I'm not sure I can use the CHKNTFS /X x: (to exclude individual drives) in this case as I no longer have a drive letter assigned at the point CHKDSK is running. Possibly I can say CHKNTFS /X \\?\{blah-blah-blah...} (the same ID CHKDSK uses when it scans it) to exclude the partition but as this writes the value to a critical system registry entry used at boot I'm not sure I want to try it unless someone knows it works. The Microsoft documentation suggests only a drive letter is accepted but it could be misleading.

[Undertow]

Ok I decided to play it safe(r) and make a copy of the windows boot partition on the exisiting raw drive as a virtual drive on the host file system and try a repair on that. So I booted the VM into Clonezilla and began a local partition to partition copy. This ran fine for several minutes at approx 1GByte/minute then Clonzilla started churning out a series of disk read errors on the source RAW drive intermingled with "IDE reset succcess" messages. Until it hit a limit and gave up.

Is Clonezilla even expected to work under VB with a source RAW disk or am I in unsupported territory again?

[Sasquatch]

It should work just fine. The errors you get do indicate the reason of the continuous checks, something is wrong with the partition/hard drive. Try to do the same on the Host directly (create an image file).

[Undertow]

Do you mean I can clone the physical drive to an image file usable by VB directly on the host then? How would I go about that if possible?

[Sasquatch]

No, I mean burn the CZ ISO to a rewritable disc (if possible, it saves a normal CD/DVD) and boot the computer with it, create an image of the faulty partition and see if you get the same errors. If you do, the partition is messed up and maybe the hard drive broken.

[Undertow]

No, I mean burn the CZ ISO to a rewritable disc (if possible, it saves a normal CD/DVD) and boot the computer with it, create an image of the faulty partition and see if you get the same errors. If you do, the partition is messed up and maybe the hard drive broken.

Ok, I'll give it a go but I don't think there is a real physical drive problem but I might as well find out...