Parallels 6: No import of VMs anymore?

Parallels Transporter 6 seems to have lost the ability to import 3rd Party VMs or virtual disk images like VHDs. The functionality was there in Parallels Transporter 5... will this be added in a future build?

 

Search for "Opening an Existing Virtual Machine" in the Parallels Desktop help. It says the Open command can be used to open all virtual machine types. Non-Parallels VM's will be converted.

Parallels Desktop 6 now also has the ability to import directly from a Boot Camp partition. This probably also includes PC drives that you connect to your Mac so you don't need to use Parallels Transporter.

 

I tried to mount a Microsoft VHD Drive to a Parallels 6 VM -> does not work. Parallels Transporter 5 could convert VHDs to Parallels HDDs, this is the functionality I'm actually missing.

 

If you open the Virtual PC machine then will it import the .vhd?

Does Parallels Mounter let you mount the vhd?

 

I just have the .vhd-File. Parallels Mounter 6 mounts it without any problems.

 

I don't know why they removed the feature. The following worked for me:

1) Mount the Parallels 5 installer disk image. Download the Parallels 5 installer disk image first if you don't still have it.
2) Open the invisible Install.mpkg file that is on the disk image with Pacifist.
3) Extract Parallels Transporter.app to a new folder by dragging it to the folder. Rename it to Parallels Transporter 5.app
4) Extract the following files and copy them to /Library/Parallels/Parallels\ Service.app/Contents/MacOS/
libQtXml.4.dylib
libQtNetwork.4.dylib
libQtGui.4.dylib
libQtCore.4.dylib

Now you can run Parallels Transporter 5.app from Parallels Desktop 5 without uninstalling Parallels Desktop 6.

 

Third party VMs could be opened and converted in Parallels Desktop 6 using File->Open.

To convert third party virtual disks you need to use Parallels VM Converter (Parallels Desktop 6 internal utility). It's location is /Library/Parallels/Parallels\ Service.app/Contents/PlugIns/Parallels\ VM\ Converter.app/Contents/MacOS/prl_convert. Try to run this utility in terminal with virtual image location as parameter.

 

That's interesting. Here's the help info:

Code:

JoeMacPro:~ joevt$ cd "/Library/Parallels/Parallels Service.app/Contents/PlugIns/Parallels VM Converter.app/Contents/MacOS"
JoeMacPro:MacOS joevt$ ./prl_convert --help
Usage: ./prl_convert <src> [<options>...]

<src> is third party VM or Disk Image.

<options>:
    --dst=<path>         destination directory (if omitted, the default
                         directory is used)
    -r, --reg[=<Y|n>]    register the resulting virtual machine (y by default)
    --os-files=<path>    path to the operating system installation files

enable/disable features: 
    --allow-no-hdd       allow to convert virtual machines that have no hard disk
    --allow-no-os        allow to convert virtual machines that have no operating system installed
    --no-reconfig        skip reconfiguration when converting the virtual machine
    --no-scsi-switch     don't switch scsi drives to ide
    --no-src-check       don't check the source virtual machine/disk state. It is not recommended to use this option.
    --update-cfg         update AppLists.xml.

Help options:
    -h,--help

But it doesn't work with a .vhd that I have and that Parallels Transporter 5 works with even if have the --allow-no-os option added.

Code:

JoeMacPro:MacOS joevt$ ~/BaseDrive.vhd --allow-no-os
The source virtual machine contains no operating system. If you want to convert it anyway, please use the --allow-no-os option.

 

Unfortunately we have some bug/restriction for single disk conversion. It is impossible to convert third party disk image without OS.

Please generate a problem report and tell me it's number. I'll try to find a problem with OS detection.

 

BaseDrive.vhd is an old Virtual PC for Mac hard disk that Parallels Mounter is able to mount. It contains Windows 98.

The problem report ID is 6684519.

 

Windows 98 is not supported as OS for conversion.

You can create simple VM configuration file (win98.vmc, for example) with following content (you need to correct locations to proper parsing):

and use it in Parallels Desktop 6 or in prl_convert. Configuration file must be simple text file in utf8 encoding.

 

I just wanted to test converting a .vhd to an .hdd. The contents shouldn't matter. Doesn't the conversion process just do a sector level copy so that it doesn't matter what file system is used on the .vhd?

The fake .vmc method worked. I can access the contents of the new .hdd but it is not bootable (no error is displayed during startup). I don't know if it's because it's Windows 98 (I do have a working version of Windows 98 elsewhere in Parallels Desktop 6) or because it was a Virtual PC version of Windows 98 (I don't have a working version of Virtual PC anymore to test if the .vhd disk is actually bootable). The boot code in the MBR and the VBR appear to be ok or at least non-empty (checked using dd | xdd in Linux).

 

joevt, thanks for your reports!

We try to detect OS to make it bootable. We reworked our tools and temporary lost ability to convert disks as data only. I hope it will be fixed soon.

It could be because our disk geometry is incompatible with VirtualPC's one (in some cases). Try to resize disk to make it grater than 4 GB.

 

It might be geometry. Changing geometry settings in DiskDescriptor.xml helped make a .hdd that I made from an .img bootable. http://forum.parallels.com/showthread.php?t=104103

But for this .vhd disk, something else is going on. I tried modifying the geometry in DiskDescriptor.xml without any success. The disk conversion utility seems to default to 32 sectors per cylinder so I tried the usual 63 (63 is the first block of partition 1 and partitions are usually on cylinder boundaries). Which didn't work. I think I need to verify the .vhd is bootable in Virtual PC before trying it in Parallels.

What might be helpful is some code that logs which blocks on the disk are being read by the BIOS. I would expect block 0 for the MBR, then block 63 for the boot block of the first partition but I don't think the BIOS is getting that far.

I looked at the DiskDescriptor.xml created by prl_convert more closely:

Code:

<Parallels_disk_image Version="1.0">
    <Disk_Parameters>
        <Disk_size>1064448</Disk_size>
        <Cylinders>2079</Cylinders>
        <Heads>16</Heads>
        <Sectors>32</Sectors>
        <Padding>0</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>1064448</End>
            <Blocksize>512</Blocksize>
            <Image>
                <GUID>{5fbaabe3-6958-40ff-92a7-860e329aab41}</GUID>
                <Type>Compressed</Type>
                <File>BaseDrive.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>

The numbers don't make sense. The disk is shown by Parallels Mounter to have a capacity of 1.07 GB (Finder Get Info)
But the above says 1064448 blocks = 519.75 MiB.
But the .hds file is 545.3 MiB. Isn't the Storage/End supposed to equal the size of the .hds file? Or does the .hds file contain extra stuff?
fdisk in Linux says the first partition is supposed to end before block 2088576 = 1020 MiB.
The Disk_size should be at least equal to 2088576 shouldn't it?
The Cylinders/Heads/Sectors multiply to 1064448 so they are probably also wrong...

The disk can be mounted by Parallels Mounter but because of the above errors, not all files can be copied (I just noticed that now). I get Error code -36 for some files probably because they exist outside the first 1064448 blocks.

I made the following changes:

Code:

        <Disk_size>2088576</Disk_size>
        <Cylinders>2072</Cylinders>
        <Heads>16</Heads>
        <Sectors>63</Sectors>

Now I can copy all the files on the disk after mounting it with Parallels Mounter. It still won't boot though.

Here's block 0 contents:

Code:

joevt@joevt-desktop:~$ sudo dd if=/dev/sdb count=1 | xxd
0000000: 33c0 8ed0 bc00 7cfb 5007 501f fcbe 1b7c  3.....|.P.P....|
0000010: bf1b 0650 57b9 e501 f3a4 cbbe be07 b104  ...PW...........
0000020: 382c 7c09 7515 83c6 10e2 f5cd 188b 148b  8,|.u...........
0000030: ee83 c610 4974 1638 2c74 f6be 1007 4eac  ....It.8,t....N.
0000040: 3c00 74fa bb07 00b4 0ecd 10eb f289 4625  <.t...........F%
0000050: 968a 4604 b406 3c0e 7411 b40b 3c0c 7405  ..F...<.t...<.t.
0000060: 3ac4 752b 40c6 4625 0675 24bb aa55 50b4  :.u+@.F%.u$..UP.
0000070: 41cd 1358 7216 81fb 55aa 7510 f6c1 0174  A..Xr...U.u....t
0000080: 0b8a e088 5624 c706 a106 eb1e 8866 04bf  ....V$.......f..
0000090: 0a00 b801 028b dc33 c983 ff05 7f03 8b4e  .......3.......N
00000a0: 2503 4e02 cd13 7229 be75 0781 3efe 7d55  %.N...r).u..>.}U
00000b0: aa74 5a83 ef05 7fda 85f6 7583 be3f 07eb  .tZ.......u..?..
00000c0: 8a98 9152 9903 4608 1356 0ae8 1200 5aeb  ...R..F..V....Z.
00000d0: d54f 74e4 33c0 cd13 ebb8 0000 8018 5111  .Ot.3.........Q.
00000e0: 5633 f656 5652 5006 5351 be10 0056 8bf4  V3.VVRP.SQ...V..
00000f0: 5052 b800 428a 5624 cd13 5a58 8d64 1072  PR..B.V$..ZX.d.r
0000100: 0a40 7501 4280 c702 e2f7 f85e c3eb 7449  .@u.B......^..tI
0000110: 6e76 616c 6964 2070 6172 7469 7469 6f6e  nvalid partition
0000120: 2074 6162 6c65 2e20 5365 7475 7020 6361   table. Setup ca
0000130: 6e6e 6f74 2063 6f6e 7469 6e75 652e 0045  nnot continue..E
0000140: 7272 6f72 206c 6f61 6469 6e67 206f 7065  rror loading ope
0000150: 7261 7469 6e67 2073 7973 7465 6d2e 2053  rating system. S
0000160: 6574 7570 2063 616e 6e6f 7420 636f 6e74  etup cannot cont
0000170: 696e 7565 2e00 0000 0000 0000 0000 0000  inue............
0000180: 0000 008b fc1e 578b f5cb 0000 0000 0000  ......W.........
0000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001b0: 0000 0000 0000 0000 0000 0000 0000 8001  ................
00001c0: 0100 060f ffff 3f00 0000 41de 1f00 0000  ......?...A.....
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Here's the first block of partition 1:

Code:

joevt@joevt-desktop:~$ sudo dd if=/dev/sdb count=1 skip=63 | xxd
0000000: eb3c 904d 5357 494e 342e 3100 0220 0100  .<.MSWIN4.1.. ..
0000010: 0200 0200 00f8 ff00 3f00 2000 3f00 0000  ........?. .?...
0000020: 41de 1f00 8000 29c6 417e 1620 2020 2020  A.....).A~.     
0000030: 2020 2020 2020 4641 5431 3620 2020 33c9        FAT16   3.
0000040: 8ed1 bcfc 7b16 07bd 7800 c576 001e 5616  ....{...x..v..V.
0000050: 55bf 2205 897e 0089 4e02 b10b fcf3 a406  U."..~..N.......
0000060: 1fbd 007c c645 fe0f 384e 247d 208b c199  ...|.E..8N$} ...
0000070: e87e 0183 eb3a 66a1 1c7c 663b 078a 57fc  .~...:f..|f;..W.
0000080: 7506 80ca 0288 5602 80c3 1073 ed33 c9fe  u.....V....s.3..
0000090: 06d8 7d8a 4610 98f7 6616 0346 1c13 561e  ..}.F...f..F..V.
00000a0: 0346 0e13 d18b 7611 6089 46fc 8956 feb8  .F....v.`.F..V..
00000b0: 2000 f7e6 8b5e 0b03 c348 f7f3 0146 fc11   ....^...H...F..
00000c0: 4efe 61bf 0007 e828 0172 3e38 2d74 1760  N.a....(.r>8-t.`
00000d0: b10b bed8 7df3 a661 743d 4e74 0983 c720  ....}..at=Nt... 
00000e0: 3bfb 72e7 ebdd fe0e d87d 7ba7 be7f 7dac  ;.r......}{...}.
00000f0: 9803 f0ac 9840 740c 4874 13b4 0ebb 0700  .....@t.Ht......
0000100: cd10 ebef be82 7deb e6be 807d ebe1 cd16  ......}....}....
0000110: 5e1f 668f 04cd 19be 817d 8b7d 1a8d 45fe  ^.f......}.}..E.
0000120: 8a4e 0df7 e103 46fc 1356 feb1 04e8 c200  .N....F..V......
0000130: 72d7 ea00 0270 0052 5006 536a 016a 1091  r....p.RP.Sj.j..
0000140: 8b46 18a2 2605 9692 33d2 f7f6 91f7 f642  .F..&...3......B
0000150: 87ca f776 1a8a f28a e8c0 cc02 0acc b801  ...v............
0000160: 0280 7e02 0e75 04b4 428b f48a 5624 cd13  ..~..u..B...V$..
0000170: 6161 720a 4075 0142 035e 0b49 7577 c303  aar.@u.B.^.Iuw..
0000180: 1801 270d 0a49 6e76 616c 6964 2073 7973  ..'..Invalid sys
0000190: 7465 6d20 6469 736b ff0d 0a44 6973 6b20  tem disk...Disk 
00001a0: 492f 4f20 6572 726f 72ff 0d0a 5265 706c  I/O error...Repl
00001b0: 6163 6520 7468 6520 6469 736b 2c20 616e  ace the disk, an
00001c0: 6420 7468 656e 2070 7265 7373 2061 6e79  d then press any
00001d0: 206b 6579 0d0a 0000 494f 2020 2020 2020   key....IO      
00001e0: 5359 534d 5344 4f53 2020 2053 5953 7f01  SYSMSDOS   SYS..
00001f0: 0041 bb00 0760 666a 00e9 3bff 0000 55aa  .A...`fj..;...U.

They look standard enough for Windows 98 but I didn't look beyond the text info.

 

DiskDeskriptor.xml and virtual disk image's internal data are very dependent. I don't recommend modify DiskDeskriptor.xml.
Try to resize disk image (with 'Resize file system' option) using Parallels Desktop 6 GUI instead. Resizing corrects MBR and FAT super sector.

 

What's a super sector?

I did more tests.
1) Using Parallels Mounter on .vhd: unable to copy all files in the Finder (error code -36)
2) Using Parallels Mounter on .hdd created by Parallels Transporter 5: same
3) Using Parallels Mounter on .hdd created by prl_convert: same

Resizing the .hdd gives the following error when Resize file system is enabled:
"Failed to resize the virtual hard disk. An internal error occurred while resizing the disk. Resizing failed. Unable to resize the last volume. The file system of this volume might be damaged or not supported." The disk uses a FAT16 file system. I can resize the disk if I unselect Resize file system. This allows me to copy all the files using Parallels Mounter just like my DiskDescriptor fix. They copy without error but do not all contain correct data (read below) which is probably why it won't boot.

I was able to mount the .vhd using Microsoft Virtual PC for the Mac 6.1 on an old Power Mac B&W G3 which has a 1GHz G4 running Mac OS X 10.4.11. I was then able to copy all the files and compare them with the files I got from Parallels Mounter. Many of the files from Parallels Mounter were blank which means all the blocks were not converted to the .hdd properly. Does this mean Parallels doesn't support .vhd's from Virtual PC for Mac or maybe there's a problem with my .vhd? I was able to boot the .vhd in Virtual PC for Mac 6.1. I was surprised by the speed of Virtual PC on my old Mac. I haven't used it in years.

Virtual PC mounts .vhd files as disk media unlike Parallels Mounter which mounts it as a file system. This means I was able to examine the disk format in Mac OS X and also make a block level copy using Disk Utility or dd and convert the compressed .vhd to a fixed uncompressed disk image which I could then manually convert to a plain .hdd. (Feature request: allow mounting .hdd's as media instead of as file system so we can use Mac utilities to format or repartition or modify or browse or copy or whatever). I was then able to mount the .hdd with Parallels Mounter and compare the files with those from the Virtual PC mounted .vhd. They were all identical. Then I tried to boot from the new .hdd in Parallels and it worked. I was also able to use Parallels Desktop to resize the .hdd and file system and convert it to an expanding disk.

Note that booting the Virtual PC disks in Parallels works best in Safe Mode which bypasses the Connectix Virtual PC Additions (The Virtual PC equivalent of Parallels Tools).

 

I mean first (or boot) sector of file system.
A good way to view sectors (MBR or file system boot sector) is to use WinHex's View->Template Manager.

Probably Parallels Mounter have some problems with FAT16. I'll try to check on my system.

Thanks for investigations!

It looks like we have some problems with your .vhd. Can you give it to us for investigations?

 

Sure. Where should I put it?

 

.hds file contains extra data.

Yes, it should.

1064448 = Cylinders * Heads * Sectors = 2079 * 16 * 32
It is correct.

It looks like we copy a half of source disk. The reason is unknown yet

 

Please read a private message.