virtualbox.org

Hi,
This my very first virtualization experience isn't successful

I've taken Disk2vhd (v2.01) to convert my whole 10yrs old Dell laptop disk (with XP Pro SP2 32bit) into a file SILVER.VHD. The Dell system boots and works perfectly (except for speed). Its disk is partitioned as follows: Then I've tried to boot VirtualBox (v5.0.12) with SILVER.VHD as IDE Primary Master, on Win7 64bit with SSD 250 GB (190 GB free).
This resulted in UNMOUNTABLE_BOOT_VOLUME; cf. attached VBox_BSOD.png.
When retrying with Boot Logging enabled I get logs There were no new hardware or software (except VBox) installed recently on the Host.

1. Do you think that non-usual partitioning (separated System & Boot volumes) of the original Guest disk can cause the problem?
2. What else should I check?

Kind regards,
JK

First, migration of an existing physical system to virtual (P2V) is not guaranteed to work. That said, I've done it with XP several times with no problems. It helps to have read the XP migration FAQ - though you should ignore the quaint advice about using dd - your Disk2VHD route is superior.

It is essential to run MergeIDE prior to the P2V imaging process, otherwise XP will be unable to identify the system drive on boot. I would also take the other steps (deleted intelppm.sys and agp400.sys) without waiting to find out if they actually cause trouble.

Are you absolutely sure you imaged the entire source drive, i.e. including boot sector? If so then I imagine that failure to run MergeIDE is your problem.

The next problem people encounter with an XP P2V is a black screen on boot. If that happens then go into the VM settings and toggle the "IO APIC" setting. There is no correct value for this, it simply has to match what your XP image needs - so don't do anything unless you have the problem.

Final note: P2V is not a substitute for having a full setup CD: assuming you get XP to boot then it will go nuts with all the hardware changes, and it will need the setup CD to get drivers for hardware that wasn't present when it was first installed. Oh, and it will want to be reactivated, which usually isn't a problem provided it wasn't a branded OEM install (e.g. Dell or HP).

Thank you for the answer.
I appreciate your appeal to take precautions.
I am afraid that 2 programs running on the XP system I would like to virtualize, cannot be reinstalled from scratch on another hardware. In reality, this is the main reason of my virtualization attempt.

In

...P2V is not a substitute for having a full setup CD: assuming you get XP to boot then it will go nuts with all the hardware changes, and it will need the setup CD to get drivers for hardware that wasn't present when it was first installed. Oh, and it will want to be reactivated, which usually isn't a problem provided it wasn't a branded OEM install (e.g. Dell or HP)

by "assuming you get XP to boot", do you mean booting of physical XP or booting of its clone within VirtualBox?
BTW, my XP system is a Dell Inspiron delivered with setup CDs.

I must confess that I am worried by the fact that MergeIDE overwrites drivers-related Registry entries.
Your own words

... (P2V) is not guaranteed to work. That said, I've done it with XP several times with no problems

suggest that you are confident but not sure.
I would be much more assured if the MergeIDE functionality were incorporated in Disk2Vhd as an XP-specific option. In that case, no changes would be imposed on the source (physical) XP system.

Question 1. What would you recommend to do before irreversible action of MergeIDE, to assure future bootability of the physical XP system?
Question 2. Could you be more specific concerning activation of the already virtualized XP system? Do you "foresee" any issues?

Kind regards,
JK

jkomorowski wrote: by "assuming you get XP to boot", do you mean booting of physical XP or booting of its clone within VirtualBox?
BTW, my XP system is a Dell Inspiron delivered with setup CDs.

This is the VirtualBox forum, and we are not discussing your physical PC.

jkomorowski wrote: I must confess that I am worried by the fact that MergeIDE overwrites drivers-related Registry entries.

No, it adds new entries for more IDE controllers. This makes the image more portable to new hosts, and has no effect on the existing host. In any case, if you are concerned about the original XP PC then back it up with Acronis first. You can read about MergeIDE here: https://support.microsoft.com/en-us/kb/822052.

jkomorowski wrote: Question 2. Could you be more specific concerning activation of the already virtualized XP system? Do you "foresee" any issues?

Well, I forsee one issue, which is the VM refusing to activate. Dell images in particular were often node locked to the Dell BIOS - which you won't find in any VM. You can only try it and see if it works: and bear in mind that if it does then you are obliged to stop using the same license on the original PC. If you want to continue using both then you'd need to install a new CD key in the VM (Google for info on that).

This is exactly what I am trying to do. The only difference is that I will running in a Win10 host.

I want to convert the old computer to a Linux machine but would like to be able to run the apps on the old machine "just in case".

thanks for the help!

Happy New Year mpack.

Thank you very much for the link
https://support.microsoft.com/en-us/kb/822052.
I suppose it could be appreciated by readers of the section Hard Disk Support on the page
https://www.virtualbox.org/wiki/Migrate ... rWindowsXP.

I've applied MergeIDE.bat to my physical XP system and, with Disk2Vhd, I've regenerated SILVER.VHD.
Should I "convert it from raw" and, if "yes", should this be done as BTW, if I boot VM directly from SILVER.VHD I get BSOD as before.

Kind regards,
JK

jkomorowski wrote:Should I "convert [the VHD] from raw" and, if "yes", should this be done as

Code: Select all

VBoxManage convertfromraw SILVER.VHD SILVER.VDI

VHD is directly usable in VirtualBox, so there's no requirement that you convert anything (and if there was: VHD is not RAW). OTOH VHD is a crappy format - prone to failure and not fully supported for all functions in VirtualBox. I would suggest converting to VDI before use, using CloneVDI.

jkomorowski wrote:BTW, if I boot VM directly from SILVER.VHD I get BSOD as before.

After you're done converting the VHD to VDI, it would be useful if you examined the partition map of the VDI using CloneVDI, and posted a screenshot of the result here.

Using CloneVDI, I've converted SILVER.VHD to SILVER.VDI (with option "Keep UUID" to substitute SILVER.VDI in VM created several days ago for SILVER.VHD).
BTW, CloneVDI's Source Drive Information / File System showed "FAT16,Unknown (Of)" that I don't understand but associate with the first partition of my physical XP system, which is FAT16.

Please, find attached CloneVDI's Partition Infos of SILVER.VHD and of SILVER.VDI, which hopefully correspond to "partition map" you mention in your post.
Finally, in the VM, I've declared SILVER.VDI as IDE controler of Primary Master.
Then I tried to boot; it failed with BSOD (0xED).

Kind regards,
JK

There's no need to show partition maps from both files. The VDI is a clone, so naturally it has the same content as the VHD.

"FAT16, Unknown(0f)" explains your problem. Neither CloneVDI, nor apparantly the boot code in your VM, understands the contents of that second partition. I assume you're using a boot manager that's attemption to locate the system partition by a <device-id><part-number> address, and it isn't finding <device-id>.

Also, didn't you say there was 3 partitions? So I assume that your second partition is an extended paritition containing a further partition map in the first sector. You should be able to view sector 1028160 in CloneVDI and "View as MBR" to see the secondary "logical" partitions (of which there should again be two): in fact I'd appreciate if you posted a picture of that since I haven't seen logical partitions being used since DOS days.

Can you explain to me why this XP image had a separate boot partition? That isn't a typical layout for an XP system disk, because XP doesn't typically expose a separate boot manager. What was inside the boot partition? ISTM if you knew enough to configure XP to use a boot manager, you should know how to reconfig the boot manager to use a new disk.

One thing that might be worth trying is hacking the primary partition map to flatten out the partition structure: replace the extended partitions with primary partitions, bypass and ignore the FAT16 partition. But, I'll need to see that extended partition map.

Thank you for so kind attitude.

I attach SILVER.VDI's sector 1028160 both in its raw and MBR aspects.
In the very initial post I mention a non-typical layout of my physical disk; cf. a screen copy of disk layout and the 1st question at the en of the post.
According to my understanding of the layout, the 1st partition boots and loads (it contains NTDETECT.COM and NTLDR) the System carried by the 2nd partition (it contains WINDOWS, Document and Settings, Program Files). The 3rd partition contains stuff irrelevant for OS functioning but relevant for "data backup".

... in fact I'd appreciate if you posted a picture of that since I haven't seen logical partitions being used since DOS days.

I attach more complete layout info. Does it correspond to your idea of picture?

Can you explain to me why this XP image had a separate boot partition?

Such "strange" layout, I've had set it in 2001 for Win2K and - being satisfied by (rather weak ) assurance it gave me against system failures - I reproduced it in 2005 for WinXP. It wasn't my invention but inspired by a Web-aquainted Windows deployment expert.
As far as I can remember, the disk was "FDISK'ed" into 2 very unequal partitions, the 1st (tiny) formatted as FAT16 (at the time felt by me as more reliable than NTFS) and the 2nd (huge) as NTFS, splitted into 2 logical drives.
Then XP install was done without any boot manager. How? I don't remember well but I suppose: the install started on the 1st volume (drive C:) - putting there NTDETECT.COM, NTLDR, AUTOEXEC.BAT, CONFIG.SYS, IO.SYS, MSDOS.SYS - and then, since (probably) there were not enough space for WinXp, the whole system was installed on the 2nd volume (drive D:).
The expected advantage of such layout was the following:
If the system refuses full OS boot but I can
- boot to DOS, and
- have DOS access to all other volumes
then I have a reliable (because of FAT16 ) volume with specialized batches ready to produce the emergency backups of anything precious on any volume.
Today such "strategy" seems to me very immature. Fortunately, I had never real occasion to benefit from it. My present interest in VBox is related, among others, with my will to improve the situation.

It's very important for me to avoid any "tinkering" on the physical XP system. As I wrote before: "I am afraid that 2 programs running on the XP system I would like to virtualize, cannot be reinstalled from scratch on another hardware."

Kind regards,
JK

Hmm. "Reliable" and "FAT" aren't two words that I associate strongly with each other, but never mind that.

Well, I'm afraid that I have no direct knowledge of the contents of your disk so I can't give definite instructions, I can only suggest things to try. In this case I suspect that if you were to dump the extended partition to a raw file then convert the raw file to a VDI then you'd almost have a bootable disk: you'd just need to attach it to a VM and run fixmbr. CloneVDI has a feature that lets you dump a portion of a VDI as a raw file, and can make it a VDI again.

If this worked you would end up with a disk containing two primary partitions: just about every Linux has that, so I know for a fact that VirtualBox supports it.

I'm not suggesting that you tinker with your physical XP system, I'm not sure why you mention that. There is nothing prevent you from tinkering with a VM. Just don't activate until you are sure you never want to go back to the original PC.

p.s. Have you considered using Acronis to transfer your XP image to a new host PC? The MergeIDE trick made all kinds of migration easier, whether the target is virtual or physical.

I'm afraid that I have no direct knowledge of the contents of your disk so I can't give definite instructions

What could I do to let you have that "direct knowledge"?

jkomorowski wrote:What could I do to let you have that "direct knowledge"?

Obviously, I could only have direct knowledge if I had the files in front of me for analysis. Unfortunately, even if you were agreeable, I am not willing to donate that amount of my time. However, I've now suggested three possible things you can try yourself. And I'll add a fourth: would the app in question work if the executable folder was simply copied to a new XP installation? Many will, though you may have to manually set up file associations etc.