Convert a physical windows XP disk to parallels without booting first?

V

vamp07@mac.com

Bit poster
I know this has been asked but I'm just hoping there is a simple answer. I have a physical disk from a PC that is no longer working (bad motherboard). I just want to convert this drive to a parallels pvm so I can boot it, install parallel tools and continue working with its apps and data in a virtual environment. Is there no way to do that conversion without booting it first to run the converter? I was hoping to do something like use diskutils to convert the drive to a dmg and then convert that dmg to a pvm. There must be a way...

Thanks
 
You can attach the physical hard disk to the Mac and create a virtual machine that uses the partitions on the disk. Create a Hard Disk that uses the Boot Camp option.

If you want to convert the disk to a virtual hard disk .hdd instead then there's a couple options:

Parallels Desktop 6 has a new feature to import from Boot Camp. I haven't tried it so I don't know how well it works.

You can convert a physical hard disk to an .hdd manually but it's not easy (I haven't tested this fully and only on Parallels Desktop 6):

- First create an .hdd in a new virtual machine. Make it uncompressed and at least the size of your hard disk.
- Attach your hard disk and make sure all the partitions are unmounted (use Disk Utility to unmount the partitions).
- Use diskutil to list all your disks, then use fdisk to examine your hard disk:
diskutil list
sudo fdisk /dev/disk#
- You should see something like Disk: /dev/disk# geometry: cylinders/heads/sectors [total sectors]
- Open the DiskDescriptor.xml file that is located in the .hdd (~/Documents/Parallels/YourNewVM.pvm/YourNewVM-0.hdd/DiskDescriptor.xml)
- In the .xml file, set the Disk_size to total sectors. Make sure that this number + 1 is smaller than the Storage/End number in the same file. If it isn't then you made the .hdd too small.
- Set Heads to heads
- Set Sectors to sectors
- Note the value of Padding (probably 1).
- Make sure the DiskDescripter.xml.Backup has the same changes.
- Use the dd command to copy all the contents of your hard disk to the .hdd like this:
sudo dd bs=512 oseek=1 conv=notrunc if=/dev/disk# of=~/Documents/Parallels/YourNewVM.pvm/YourNewVM-0.hdd/YourNewVM-0.hdd.0.\{########-####-####-####-############\}.hds
The oseek number should match the Padding number.
- The dd command should return with the number of sectors copied which should equal the total sectors that fdisk displayed.

My DiskDescriptor.xml looks like this (after copying a Windows 95 .img to an .hdd and making the changes to the geometry fields):
Code: 
<Parallels_disk_image Version="1.0">
    <Disk_Parameters>
        <Disk_size>526176</Disk_size>
        <Cylinders>522</Cylinders>
        <Heads>16</Heads>
        <Sectors>63</Sectors>
        <Padding>1</Padding>
        <Encryption>
            <Engine>{00000000-0000-0000-0000-000000000000}</Engine>
            <Data></Data>
        </Encryption>
        <Miscellaneous>
            <CompatLevel>level2</CompatLevel>
            <Bootable>1</Bootable>
        </Miscellaneous>
    </Disk_Parameters>
    <StorageData>
        <Storage>
            <Start>0</Start>
            <End>629248</End>
            <Blocksize>512</Blocksize>
            <Image>
                <GUID>{5fbaabe3-6958-40ff-92a7-860e329aab41}</GUID>
                <Type>Plain</Type>
                <File>Windows 95-0.hdd.0.{5fbaabe3-6958-40ff-92a7-860e329aab41}.hds</File>
            </Image>
        </Storage>
    </StorageData>
    <Snapshots>
        <Shot>
            <GUID>{5fbaabe3-6958-40ff-92a7-860e329aab41}</GUID>
            <ParentGUID>{00000000-0000-0000-0000-000000000000}</ParentGUID>
        </Shot>
    </Snapshots>
</Parallels_disk_image>

You should be able to right click the .hdd and use Open with... Parallels Mounter to view the contents of the .hdd in the Finder. I think it should be possible to change the .hdd to a compressed disk image.

The same technique could be used to convert an .hdd to an .img which can be converted by Disk Utility to a compressed disk image .dmg. Disk Utility can mount .img and .dmg files directly so it could be used to examine Linux disks since Parallels Mounter only supported FAT and NTFS disks.
 
The discussion at http://forum.parallels.com/showthread.php?t=105002 concerns solving the problem for a pure Mac scenario. The OP was starting with a Windows XP disk. It's just not clear to me in what circumstances that approach would apply. In my case I'm trying to solve the same problem for a BOOTCAMP partition with Windows 7. I successfully imported that to Parallels 6 using Parallels current BOOTCAMP methods, leaving the BOOTCAMP partition in its original place. Now I'd like to make the BOOTCAMP into a .hdd, or any equivalent solution. A dmg of the bootcamp partition alone would not work since it lacks a partition table. A dmg of the entire disk might work but is several hundred times the size in my case, so no good.

I tried the approach of using Parallels Transporter to import the BOOTCAMP-based VM into a new hdd-based VM, which struck me as an incredibly strained way of converting a BOOTCAMP to an hdd. Strained or not, it did not work, the resulting disk "contains no operating system", although inspecting it superficially from another VM, it looks basically ok. Is there a boot cache that needs to be reset?

FWIW when the Transporter approach failed, I tried it again. Before doing it the second time I uninstalled Parallels Tools on the source machine (using Programs and Features), rebooted, and then started the Transporter agent again, working with a fresh new virtual machine on the receiving side. Curiously Parallels doesn't seem to try to match the memory or # of CPUs of the original machine with Transporter.

I thought the approach of editing the DiskDescriptor.xml was even more strained for what struck me naively as a simple operation of converting to an hdd. It may be my best bet now, but who knows, might suffer the same fate as the more automated approach of using Transporter. I'm not much of a Windows guy. Are there any utilities out there for diagnosing bootability problems like this? It seems to me one of the test utilities I used once might have given some bootability diagnostics.

What might be nifty would be to have a way to generate a sparse image of the entire disk containing the BOOTCAMP, with all other user partitions besides BOOTCAMP omitted, partition table retained. I'm not sure if spare images of whole disks is even a supported concept. (Not that there isn't a lot of work in that, but I'm just spouting solution ideas since there are still some unmet needs in this department, and who knows what approach might be valuable if somebody took a look at it.)
 
Disk Utility can create disk images that have a partition map. You can also repartition disk images. The disk image might not have boot code in the MBR though so you'll have to make sure to put some boot code on there using another utility (maybe use dd to copy the boot code from somewhere else). Also, the boot partition may need to be selected in the MBR (using a utility like fdisk).

But instead of doing that all that, try the Import Boot Camp option in the Parallels Desktop File menu. First, create a virtual machine that uses the Boot Camp partition (optionally make sure it boots properly in Parallels and then shut down the virtual machine), then use the Import Boot Camp command to convert the Boot Camp virtual machine into a virtual machine that uses a virtual hard disk image instead of the physical Boot Camp partition.

Parallels Desktop 7:
http://download.parallels.com/deskt...n_US/Parallels Desktop User's Guide/32733.htm

Parallels Desktop 6:
http://download.parallels.com/desktop/v6/docs/en/Parallels_Desktop_Users_Guide/23112.htm

It seems you could make an arbitrarily sparse disk image by editing the DiskDescriptor.xml file since it does allow specifying different locations for different parts of a disk (e.g. A Boot Camp .hdd has separate files for the MBR and GPT that are not on the physical Boot Camp disk, and can specify multiple Boot Camp partitions that are not necessarily contiguous). But I haven't tried it with a disk image. Either the Import Boot Camp option does this for you so that the partition on the new virtual .hdd has the same starting block and size as on the physical hard disk (and as on the Boot Camp .hdd) or it rearranges the partitions on the new .hdd. I don't know which since I haven't tried the Import Boot Camp option. Either way, Parallels should be smart enough to make it as bootable as it was on the physical disk.
 
joevt,

> First, create a virtual machine that uses the Boot Camp partition (optionally make sure it boots properly in Parallels and then shut down the virtual machine)

Yes, that part was already done and works fine.

> then use the Import Boot Camp command

This ended up working and the result may be fine, although there were a some confusing things along the way, and I don't like how my virtual hard disk is configured. I will go ahead and give feedback here on the confusing things. Then I'll get into the hard disk issue. I'm not sure if this is supposed to be a feedback forum as much as a help forum, so I hope this is not off-topic, since items (1) to (3) are just feedback and not a current issue needing a solution. I am using Parallels 6 by the way.


(1) What led me *not* to have used Import Boot Camp in the first place was a series of events and mis-impressions that I won't try to fully recount. But I never dreamed I would have to select a virtual machine to import *from* prior to selecting the Import Boot Camp menu command. And so when Import Boot Camp was dimmed in the menus, and Import was not, I went for Import. Any doubts about this vanished when my searches led me to a thread in which another Parallels 6 customer was advised to use a Parallels-Transporter-based approach to solve the same problem I was solving. My mis-impressions about Import Boot Camp and failure to look into why it was dimmed stem from my understanding of what "Import" means from decades of uses in dozens of different contexts. I expect a command labelled something like "Import..." in the menus to allow me to specify (as suggested by the "...") the item I want to import which will be either imported into my current document-like context or into a new document being created by the Import. I never expect and have never seen that the object to be imported *from* would be specified by a selection made or a document opened prior to such an Import command. Any required selection or frontmost document would be taken to be the context *into* which the Import was to be done. This would seem to be as plain as day. So when the obvious "Import Boot Camp..." didn't work but another command "Import..." was both available and recommended (and in fact succcessful) I took that other approach.

So I think it could be improved, either by structuring it as an Export (even though you no doubt are used to thinking of it *technically* as Importing the data from an external medium), or by providing Import Boot Camp as an option available when creating a new virtual machine, where the use of the notion "Import" would reflect conventional use. Since I *am* creating a virtual machine after all I actually missed having the options I usually have, including setting the virtual machine name immediately, etc. The fact that I am not a Coherence user and Coherence was chosen by default caused *so* much confusion for me that I'm addressing that separately in item (2). So I was able to rename my virtual machine and could also rename the hdd file to follow the "normal" pattern but have not yet bothered to do the later. (The good thing was that in this case at least a lot of the settings were taken from the machine imported from, which seemed not possible with the Transporter approach, although I don't see why not--I'd like to see it used even when transporting from a real PC.)


(2) When the Import Boot Camp process finished it apparently at some point started the new virtual machine without really telling me so, and with absolutely no evidence because the machine was started in Coherence mode. There were no Parallels Windows on the screen, except I think the one belonging to the VM I had just Imported *from*, and the Virtual Machines list window. The result was a series of useless clicks and suspendings and resumings of an unseen machine whose existence I only presumed vaguely and not with much security from the item added to the Machines list. Was the import process still running? Anyway I find Coherence always unusable since my use of Windows tends to involve interaction with the Desktop, a "window" which I need to look at but have no apparent way to see. So I tried Coherence half a dozen times because of its compelling elegance, but each time gave it up as useless. To have it be the default when importing from another machine that was *not* set to use Coherence seems inexcusable. Worse yet in this context. Let the user switch to Coherence if they want it. If a machine is being created whose demonstrable existence is the culmination of a long hopeful path and it does not even appear--that is at least frustrating whereas the alternative of having to look at a Window for a couple seconds until you switch to Coherence is of negligible consequence.


(3) An unusual thing occurred when I turned on the Firewire disk containing the Bootcamp partition before I first attempted this import. For some reason the disks did not show up. I ended up having to power-cycle the Firewire enclosure again. Meanwhile, until I figured that out, I got the following error message, which I was about to post about when I thought to look for the BOOTCAMP disk, and found it was not there (else the message would not have helped me). When clicking "Choose" after clicking "Import" I got:

Operation failed.
Failed to execute the operations.

The error message could be a little more specific.


(4) Regarding the virtual hard drive created by this process, Parallels is treating it as "Expanding disk, 931.5 GB". And if I Edit, the size slider shows 932 GB as the minimum. The .hdd actually occupies less than 19 GB, so the space currently used is not a problem. But for the "safety" of the volume I put this hdd on, I would have limited this virtual disk to not grow beyond 32 G. When running the VM, under Computer, Drive C shows as having "10.1 GB free of 31.1 GB". It is not clear what the 932 GB means, if anything at all. That hard drive containing the BOOTCAMP source for this was a 1TB drive, and of that total, BOOTCAMP occupied 33.5 GB. So it is at best confusing and possibly worrisome. If the number is meaningless it makes it hard for me to determine how to have control over the growth on this disk. That probably won't turn out to be a big deal, but several weeks ago I had a process go awry in a Parallels VM and eat up a lot of space on my Mac boot volume in a matter of seconds. The virtual hard drive *had* expanded. So I like to be able to put a cap on it.


Thanks for any help on item (4) and also if anyone from Parallels takes feedback here please read (1) through (3).
 
1) I agree. Import Boot Camp should work without having to create the Boot Camp virtual machine in the first place. It should guide the user through the steps necessary to create the virtual machine. Otherwise, this feature should be included in the New Virtual Machine command so that if you select a Boot Camp partition, then it will ask if you want to copy the partition to a new virtual hdd or use the partition itself. Maybe the hard drive configure option could have the option of copying a boot camp hard drive to a new hard drive image.

2) I also believe that Coherence as a default is wrong. When you create a virtual machine, there are options "Like a PC" and "Like a Mac". I think that each option should describe what is different between them so that the user has the information needed to choose which they prefer, and also how to switch settings later. There is a knowledge base item about those options at:
http://kb.parallels.com/en/8727

3) I sometimes have problems with my FireWire external hard drive. I believe this is a problem with my hard drive and not with Parallels. If I see that the Windows partition mounted correctly in the Finder, then I know that Parallels will be able to boot from it when I start the virtual machine.

4) I believe Parallels must have copied the structure of your hard disk so that the Windows partition has the same start block and size on the virtual hdd as it did on the physical hdd (to increase compatibility or so that registry settings that rely on partition location and size remain valid). Also, the Windows partition was probably at the end of the disk. You can use the DISKPART command line or the Disk Management program in Windows to check this. As long as you don't create new partitions on the virtual hdd and Windows doesn't write to the unused partitions, then the virtual hdd file will not grow beyond the size of the Windows partition.
1 TB (base 10: 1000 bytes per KB) = 1000000000000 bytes = 931.3 GiB (base 2: 1024 bytes per KiB).

Parallels does the same when using a Boot Camp partition directly. The virtual hard disk that points to a Boot Camp partition will have the partition location and size set the same as on the physical hard drive.
 
joevt,

1) and 2) Yes.

> 3) I sometimes have problems with my FireWire external hard drive. I believe this is a problem with my hard drive and not with Parallels.

I didn't mean to suggest otherwise. My point was that the Parallels error message was beyond opaque and it was just by luck that I thought to check for the presence of the disk on the bus, or I'd have been posting a message here that maybe no one could have helped me with.

OT: I can't speak to your problem, but I expect problems like this to happen with Firewire drives at any time. The worst of them is bus freezes which can happen when hot-plugging or unplugging. These are in my experience almost but not completely eliminated if the power is always off on the device being plugged/unplugged, and my stats seem better now that I'm waiting longer for the power to decay before unplugging. It is just the state of Firewire at this time, at least with respect to hard drives. There have been a lot of Firewire chipset compatibility issues and I suspect Apple's firewire stack is not quite right 'yet' either.

This chipset in this particular OWC enclosure seems to exhibit the problem of drives sometimes not showing up on power-up/connect.


4) Interesting.

> Parallels does the same when using a Boot Camp partition directly.

With the VM that used the Boot Camp partition it was really scary. Parallels was in some contexts reporting the disk size to be some millions of GB. I noticed this on several occasions. It is not impossible I missed a decimal point but I did try to look carefully. That machine is gone now as is the original BOOTCAMP partition, so I can't look into this more.
 
Kurt Bigler said:
With the VM that used the Boot Camp partition it was really scary. Parallels was in some contexts reporting the disk size to be some millions of GB. I noticed this on several occasions. It is not impossible I missed a decimal point but I did try to look carefully. That machine is gone now as is the original BOOTCAMP partition, so I can't look into this more.
Click to expand...

I may have seen this before but can't recall for sure. I do know that Parallels doesn't handle Boot Camp partitions on MBR formatted disks that have an extended partition (probably a disk that came from a Dell PC). Or at least Parallels lists the partition with some nonsensical made up device name like disk5s124135 (or something like that, I don't recall exactly) which does not match any device name in /dev.
 
You must log in or register to reply here.
Back
Top