Incompatibility of Transporter Agent and Parallels Desktop versions + other problems

T

TomaszT

Bit poster
Copy of a post in different thread, as requested by Parallels' Support (original message here).

I've ended up with FIVE different versions of "Parallels Transporter Agent". One from product's download page, two from different areas of parallels.com and two from external sources (like Softpedia etc., found by Google). NONE OF THEM worked with product I've downloaded ("Parallels Workstation 6.0 for Windows"). Including the one downloaded from the same page as product. In all five attempts "Parallels Workstation 6.0 for Windows" claimed that it's build number is different then installed "Parallels Transporter Agent" build number. I found this situation completely not acceptable. I don't have time to install n-different versions of a software, because even small change in build number makes them incompatible and not working. I was forced to use external disk as destination for imaged system.

I've imaged Windows XP with one-core processor and 512 MB of RAM and two disks. Total image file was 59,1 GB. I've run this image in a freshly installed "Parallels Workstation 6.0 for Windows". After SEVENTEEN HOURS (!!!) of seeing "Please wait while virtual machine is being configured" message and noticing that 17 hours was enough for "Parallels Workstation 6.0 for Windows" to only achieve around 33% of first of four steps of "auto-configuration" I gave up and decided to run concurrence software. Either I have a rally bad luck or your software isn't simply prepared to work efficiently under Windows.

Regards,
Trejder
 
TomaszT,

Parallels Workstation can't lock a virtual disk image.
1) If VM is located on network drive, please copy it to local drive.
2) Please check that you have write access to VM.

To avoid upgrade procedure edit DiskDescriptor.xml (Windows XP.pvm/Windows XP.hdd/DirkDescriptor.xml is located in your images path):
change <CompatLevel>level2:p</CompatLevel> to <CompatLevel>level2</CompatLevel> (remove :p).
 
Stuw,

Stuw said:
Parallels Workstation can't lock a virtual disk image.
1) If VM is located on network drive, please copy it to local drive.
Click to expand...

Not true. Since Paralells Workstation (run on host computer) failed to create disk snapshot over network (claiming that Paralells Transporter Agent, run on guest computer, has different build number) I was forced to used Paralells Transporter Agent to create disk snapshot on some external device. Since there was not enough space on guest computer, I used mapped network drive. But it was solely for creating virtual machine purpose. After this was complited, I run Paralells Workstation from host computer and used virtual machine 100% stored on local hard drive.

There might be a bug in your software that makes Paralells Workstation claiming that virtual disk image is stored on network drive, while in fact it was only created over network but after creation is phisically stored on a local hard drive.

Stuw said:
2) Please check that you have write access to VM.
Click to expand...

Since it is stored on local hard drive and I was able to move it from one partition to another and copy it to external USB drive, I assume that I have both read and write access to it.

There is for sure a huge bug in your software that, when Paralells Workstation is unable to lock a virtual disk image, it does not displays any message to a user and instead it is pretending, it is doing something (for seventeen hours!) - like faked auto-configuration process.

Stuw said:
To avoid upgrade procedure edit DiskDescriptor.xml (Windows XP.pvm/Windows XP.hdd/DirkDescriptor.xml is located in your images path):
change <CompatLevel>level2:p</CompatLevel> to <CompatLevel>level2</CompatLevel> (remove :p).
Click to expand...

I did that and was able to run virtual machine without auto-configuration (fake or not). Does this change auto-magically cause Paralells Workstation to now be able to lock a virtual disk image, that it was previously not able to lock?

There is for sure another big bug in your software that a "lock" icon, that allows to switch from auto-configuration to manual does not appear from the beginning of "auto-configuration" process, but user must wait (some times many minutes) before it appear. It would be much easier, if Paralells Workstation would simply ask user before starting a virtual machine, if he or she wants to use auto-configuration or manual one. Without forcing him or her to make manual edits to configuration files, as you presented.

After sucessfully running my virtual machine for first time, my virtual Windows XP showed blue screen with "Unable to mount volume" message and immediatelly restarted system. After restart sitation repeated. I'm therefore unable to run virtual system. Can this mean that Paralells Transporter Agent failed to create a valid virtual disk image? Seems so to me.
 
External storage migration is not completely intuitive scenario. Please check information about migration Using an External Storage Device in Users's Guide.

You need to finish migration from step 10. Without this steps our software can't configure guest OS and OS will show BSOD on boot.
 
Last edited:
Stuw said:
External storage migration is not completely intuitive scenario. Please check information about migration Using an External Storage Device in Users's Guide.

You need to finish migration from step 10. Without this steps our software can't configure guest OS and OS will show BSOD on boot.
Click to expand...
Then I'm really surprised that Parallels Transporter Agent says nothing about this. It simple claims: "You're done, thank you", which is not true, because after Transporter work is done, user is actually in a middle of a process, with useless, not working virtual machine. I would strongly suggest to add a proper note to Transporter Agent last screen to notify user that he should follow mentioned guide from that point.

I followed guide provided by you and was able to boot my virtual Windows. I don't know yet anything else, as Parallels Transporter Agent is deactivating Windows very strongly (badly). I.e.: user cannot even login to Windows before he finish activation. This is a bit strange, as usually deactivated Windows allows to login and even work few days with reminding of a need of activation. Because I'm not able to login, I can't check virtual machine's network settings from inside the virtual system. I can only control this from outside (from Parallels Workstation) and for some reason my virtual Windows is unable to connect to Internet to finish activation. I'll have to take it to another network, to see, if there I'll be able to finish activation of my Windows.
 
TomaszT said:
Then I'm really surprised that Parallels Transporter Agent says nothing about this. It simple claims: "You're done, thank you", which is not true, because after Transporter work is done, user is actually in a middle of a process, with useless, not working virtual machine. I would strongly suggest to add a proper note to Transporter Agent last screen to notify user that he should follow mentioned guide from that point.
Click to expand...
My fault. Vm **must** be usable after Agent-side migration. But probably agent contains some bugs, wich was fixed on Parallels Workstation side.
I agree about the note, it must be available on last page. It other case it is a bug.
 
You must log in or register to reply here.
Back
Top