Since my upgrade to Parallels 7 I almost every time run into the following problem after a MacOS X suspend/resume: The CentOS (Redhat Linux) guest OS has only "read only" access to it's root device (/dev/sda3) and probably others. It cannot write any more to it's filesystem. The only solution is to reboot the guest OS, since a Linux "mount -o remount,rw /" is not possible. Unfortunately I do not have any logs from the Linux, since the disk was frozen (processes were still running, open shell sessions worked). MacOS logs are partly attached below. - CentOS is a "Linux HMS0 2.6.18-238.9.1.el5 #1 SMP Tue Apr 12 18:10:56 EDT 2011 i686 i686 i386 GNU/Linux" - MacOS is a "Darwin godewind 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386" With Parallels 6 I had a similar problem: CentOS was frozen every now and then after suspend/resume. Any ideas are appreciated. How could I open a bug report with parallels.com. I do not have a support contract. Is there any "free" past sales support (upgrade was only days ago)? Thanks, Gerd 12-02 01:05:41.731 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName = 12-02 01:05:41.731 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processed command DspEvtHwChanged with status 1 12-02 01:15:53.231 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processing command DspEvtHwChanged .... 12-02 01:15:53.265 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName = 12-02 01:15:53.265 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processed command DspEvtHwChanged with status 1 12-02 01:15:54.304 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processing command DspEvtHwChanged .... 12-02 01:15:54.309 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName = 12-02 01:15:54.309 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processed command DspEvtHwChanged with status 1 /drv/ MacDevice.cpp:598 com_parallels_hypervisor_client:owerDownHandler: message e0000280 /drv/ MacDevice.cpp:598 com_parallels_hypervisor_client:owerDownHandler: message e0000280 /drv/ MacModule.cpp:304 powerStateWillChangeTo: flags=4 stateNumber=2 /drv/ MacModule.cpp:309 powerStateWillChangeTo: found flag=kIOPMSleepCapability (4) /drv/ MacModule.cpp:304 powerStateDidChangeTo: flags=4 stateNumber=2 /drv/ MacModule.cpp:309 powerStateDidChangeTo: found flag=kIOPMSleepCapability (4) /drv/ MacModule.cpp:304 powerStateWillChangeTo: flags=82 stateNumber=4 /drv/ MacModule.cpp:305 powerStateWillChangeTo: found flag=kIOPMPowerOn (2) /drv/ MacModule.cpp:310 powerStateWillChangeTo: found flag=kIOPMRestartCapability (80) /drv/ MacModule.cpp:304 powerStateDidChangeTo: flags=82 stateNumber=4 /drv/ MacModule.cpp:305 powerStateDidChangeTo: found flag=kIOPMPowerOn (2) /drv/ MacModule.cpp:310 powerStateDidChangeTo: found flag=kIOPMRestartCapability (80) 12-02 10:48:15.532 W /LocalDevices:6072:9207/ NET: osxSleepWakeup() 12-02 10:48:15.853 W /LocalDevices:6072:9207/ net adapter 0: OsX_ipcfg_changed 12-02 10:48:16.875 W /LocalDevices:6072:9207/ net adapter 0: OsX_ipcfg_changed 12-02 10:53:32.641 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processing command DspEvtHwChanged .... 12-02 10:53:32.660 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName = 12-02 10:53:32.660 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processed command DspEvtHwChanged with status 1 12-02 10:53:33.717 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processing command DspEvtHwChanged .... 12-02 10:53:33.723 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName = 12-02 10:53:33.723 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processed command DspEvtHwChanged with status 1 12-02 11:03:45.341 F /vm:6072:3507/ Vm {084e2e38-e8e6-45d9-8043-09b35f46a656} processing command DspEvtHwChanged .... 12-02 11:03:45.376 F /vm:6072:3507/ vmEvtHwChanged() dev_type = 16, dev_state = 2, dev_path = , dev_frName =
Hello! Please report about this problem via Help → Report a Problem and provide an ID of a submitted report. Follow to this instruction http://kb.parallels.com/en/9058 if you do not know how to submit a report Thank you!
Thank you for your report. We will investigate this issue. Do not sure about the result, but it can help, if you switch location of a virtual HDD from SATA to some of IDE locations. I suppose that CentOS will able to boot from IDE drive.
Switched from virtual SATA to IDE drive now Thanks for the hint. I have switched to an IDE disk now (and the new configuration survived the first suspend/resume of MacOS then). I precautiously copied everything to a new virtual IDE drive, installed grub, put it first in the boot loader chain and relabeled old and new disk. Could I also have switched the type from SATA to IDE instead? I mean, in the end it is only a virtual disk with same geometry etc. Is Parallels able to handle this? Why then, do we even have different virtual disk types? One type would be enough then, right? Regards, Gerd
IDE more stable than SATA driver? For some days it was stable now: It survived several suspend/resume cycles ... Obviously the IDE virtual disk has better quality than the SATA drive ;-)
It's a pitty... I suppose that it might be because of enabled NCQ feature and request queue might be broken on suspend/resume somehow. Meanwhile I did not understand why any additional actions were required (any data copying, grub setup, etc) A simple changing of location is enough since IDE ATA drivers existed on linux ramdisk. This is not true in case of original IDE to SATA changes. There are another workarounds present: 1 disable NCQ within guest linux 2 boot VM with specified system flag "devices.ahci.ncq=0" In this case any problems with virtual storage controller replacement could be avoided.
