Parallels Desktop 9 Does Not Virtualize NVRAM Correctly.

A

AMcWhirter

Bit poster
When running OS X as a guest you will not be able to use iMessage, start the caching feature of OS X Server, or use all of the functionality of iCloud. On a real mac (Not a VM) there is a physical chip on the motherboard that stores information about the mac which is called NVRAM. These services (Caching, iMessage, iCloud) pull information out of the NVRAM and send that information to Apple to authorize the service. If the information is incorrect you get what is called an Invalid Device error. The actuall GUI will report and error stating it could not connect, but in the logs you will see many HTTP requests giving "Invalid Device" errors.

Luckily this should not be too hard to fix. I am not certain what Parallels uses to emulate the EFI environment, but many other open source EFI boot loaders for load OS X have implemented an NVRAM fix for this issue. Such boot loaders are known as Chameleon or Chimera, which i will admit the Parallels boot loader looks very similar so perhaps Parallels uses a derivative?

Either way i have had this escalated to Level 2 support, we will see where this goes from here. It should't be to hard to fix, hopefully anyways.
 
Do you think this may be why we are having retina display issues with Mac Guest OSes on Retina MacBook Pros? The guest OS knows what the native resolution for the display should be but doesn't understand that it is a retina display no matter what I do. I've tried fiddling with terminal commands and other downloaded tools to make it think that it has a HiDPI display but it has no affect.
 
Hi,

Paralles virtualizes NVRAM - without it neither boot-args, nor kernel-problem logging nor many other things would not work. This could be checked by executing command "sudo nvram -p" in Mac Guest and trying to add/modify variables. The changes will be persistent.

About the described problem I cannot give any comments, sorry.
 
What has been revealed:

Smoke test of iMessage functionality seems working for 10.8.5 host/10.8.5 guest combinations. New VM could delivery iMessage to VM itself and to host. All seems OK.

After that I have made VM copy and start it too. iMessages from the first VM are not delivered to this second guest but is still delivered to host.

So, it looks like the root of the problem is this non-unique UUIDs.

UUID is generated using <SourceVmUuid> field in config.pvs. This field is preserved for a purpose and we do not want to change this behaviour. Should we generate PlatformUUID using VmUuid field or not is questionable, I can't answer immediately, but you could made a check.

Pls change SourceVmUuid with new for your VM and try to use iMessage etc services. Pls notify me if this helps.
 
You must log in or register to reply here.
Back
Top