Network Problems in Parallel XP on Ubuntu

You don't need the linux headers in your source directory if you have the full linux kernel source tarball from kernel.org which includes the headers by default. I think this is why you're having problems compiling parallels.

Delete the linux-headers symlink and you shouldn't have problems compiling parallels at this point.

Second, after you complile your kernel, do not clean the directory afterwards because then you won't be able to compile programs and modules which depend on the configured kernel source tree.
 
@titetanium

> Delete the linux-headers symlink and you shouldn't have problems compiling parallels at this point.

That does not matter anyhow. I created that link only because Stacey proposed to do so. Without that link the problem is precisely the same. Moreover it comiles - but only partly!

Of course I did not 'make clean' after compiling the kernel. And as you can see from the error-log 'parallels-config' complains about some faulty statement in its own source:

/usr/lib/parallels/drivers/drv_main/vmmain.h:196: Fehler: expected specifier-qualifier-list before »kmem_cache_t«
.........
/usr/lib/parallels/drivers/drv_main/vmmain.c:82: Fehler: »struct <anonymous>« hat kein Element namens »totalMem«
make[4]: *** [/usr/lib/parallels/drivers/drv_main/vmmain.o] Fehler 1
make[3]: *** [_module_/usr/lib/parallels/drivers/drv_main] Fehler 2

Thanks for your help, but as now Fedora8 is released with kernel 2.6.23, we'll see if otheres face similar problems.

Ingo
 
Hi Stacey:

I did apply that patch and observed following:

a) with that patch Parallels compiles fine under Gusty with kernel 2.6.23

b) starting my well prooven VM with OS/2 with kernel 2.6.23 is impossible. VM hangs (did wait for 5 minutes) and CPU-load is extremely high: one CPU at close to 100%, the second one 40 - 80%. Finally I had to switch off the VM.

c) using the same patched Parallels modules with kernel 2.6.22 under original Gusty causes reasonable CPU-load (20 - 40% on both cores), but networking makes still trouble:
cannot mount via nfs
cannot print via cups-lpd

d) the very same VM with OS/2 under Feisty (kernel 2.6.20) and unpatched Parallels build 2204 works fine at low CPU-load (half of that in case c), networking is fine (can share folders via nfs, can print, ..)

So my impression is that something basic in the networking module is not compatible with the new tickless kernels 2.6.22 and 2.6.23, This especially as also Debian-Lenny (kernel 2.6.22.3 shows same network problems as Ubuntu-Gusty!

With best regards,
Ingo

P.S.: the VM with OS/2 for testing is always a fresh copy of my 'working VM' (*.hdd) under Feisty, so this comparison holds.
 
Are you using the same .config with all the kernels you're testing with? If not, try using the .config from 2.6.20 that worked and see how it works with 2.6.22 or 2.6.23. You might have to turn the tickless feature off since 2.6.20 didn't have it to begin with.

As for 2.6.22, I'm confounded as to why the networking problem is persisting. Can you try 2.6.22 with parallels v2204 unpatched? That is what I have as of right now: parallels v2204 unpatched with 2.6.22.14 (custom kernel).
 
@titetanium

> Can you try 2.6.22 with parallels v2204 unpatched?

With that configuration I started in this thread. All my postings before 28.11.2007 relate to that configuration (Ubuntu-Gusty with original kernel2.6.22-14) and Parallels build 2204. In fact all other things like graphic and even standard connections via the network like http, ftp to the outside via my router/gateway work fine.

The problems arise when I try to connect from my VM to servers running on the Gusty host!
In Gusty (host) I have running a nfs-server and cups-lpd (activated via openbsd-inetd). Those servers are running all the time and allow smooth connection from another PC in my net - and also from inside the VM when using Feisty as a host!

Only my posts in this thread on 28.11.2007 and later are basesd on experiments with the original Gusty-kernel, trying to locate the source for the trouble. And as Gusty and Debian-Lenny both use similar kernels and both show the network-problems I conclude that it is related to Parallels.

Another remark what I have experienced when playing with kernel-configuration:
the host-system no longer crashes that hard when 'tickless option' is turned off in .configure before building the kernel. But in that case I also cannot connect from the VM to the servers on the host (nfs, cups-lpd).

Best regards,
Ingo
 
I take it that parallels is compiled and running except for the networking problem. That said, it must be coming from the network configuration either with the parallels vnic0 or your guest network configuration. Am I correct in assuming that you have your network configuration set to bridged? Since your guest is able to reach the internet, that (to me) rules out parallels vnic0 since it is able to pass packets from the outside internet and the guest.

I'm beginning to think it might be a share problem in the host, probably samba and/or nfs being configured incorrectly, but you have other computers in your household that are able to access said server(s) on the host machine. Which leads me to think it's one of two things; the guest network is probably not configured to be on the same network/subnet as the host or the firewall on the host is silently blocking the guest vm in some way. Does the guest vm also have a firewall running? Can you turn off or disable it temporarily to see if that is the issue or not?
 
titetanium said:
I take it that parallels is compiled and running except for the networking problem. That said, it must be coming from the network configuration either with the parallels vnic0 or your guest network configuration. Am I correct in assuming that you have your network configuration set to bridged?
Click to expand...

That is correct: bridged network.
I tried to further locate the problem already some time ago and observed:
a) it seems that vnic0 does not cause any trouble
b) ther trouble only occures when the VM boots up. During boot of the VM following things happen: AMD-Pacifica is activated, and then eth0 switches to promiscous mode. Only after this has happened the trouble begins. (I also tried to switch-off hardware virtualisation, but it does not improve noticably).[/QUOTE]

titetanium said:
Which leads me to think it's one of two things; the guest network is probably not configured to be on the same network/subnet as the host or the firewall on the host is silently blocking the guest vm in some way. Does the guest vm also have a firewall running? Can you turn off or disable it temporarily to see if that is the issue or not?
Click to expand...

I have set all to fixed IP's in the local net within 192.168.0.0/24
The host (as all Ubuntu-versions) does not have any firewall
I also uninstalled AppArmor in Gusty, to avoid any problems in that direction (Feisty does not have AppArmor)
Guest in the VM is OS/2-Warp 4.5 without any protection like firewal, ..etc.

In fact, even if there were somthing going wrong in the VM (which does not harm on Feisty)
it should not be propagated to the host and cause instabilities.
Moreover with network in the bridged mode, there should ba no DHCP-server running in Parallels (it is only for the host-only mode) an I do not have it configured with regard to IP's.

So if I were further searching for the root cause, I would suspect the problem beeing in Parallels networking module. This because this module intercepts between the Linux network-module 'forthdeth' and the kernel. Otherwise 'hardware virtualisation' would not be possible for networking (according to my understanding)

With best regards,
Ingo
 
Last edited:
Probably it is worth to mention following:

1. NFS is a complex protocol with several daemons running like: portmap, nfsd, lockd, statd. And OS/2 has implemented all the features including file/drectory locking. Status is communicated via the statd. A lot of RPC-calls controls the connection and even starts additional servers if requested. I am very much familiar with the NFS-features and configuration in OS/2 and even wrote a howto for that. OS/ insists on locking mounted directories, without that feature (lockd and statd not available) it does not mount any export!

2. So that bi-directional communication via several differnt ports is probably interferred when Parallels toggles the eth0 to 'hardware-accelleration' and/or 'promiscuous mode'. So probably messages initiated from the host (nfs-server) get lost or missleadet?

3. Parallels workstation has one unique feature: it supports all versions of OS/2 and eCS as a guest - and that is why I am so concerned. If that is not cured, I probably have to stay with Ubuntu-Feisty (kernel 2.6.20-16) + Parallels as long as possible and see.

Perhaps we get a new version which also runs on amd64-hosts in future - that's where the development goes. I do hope that there will be spent some more development on the Linux-version soon, as Mac-OS seems to have the favor right now.

With bestr regards,
Ingo
 
Last edited:
ingo said:
2. So that bi-directional communication via several differnt ports is probably interferred when Parallels toggles the eth0 to 'hardware-accelleration' and/or 'promiscuous mode'. So probably messages initiated from the host (nfs-server) get lost or missleadet?

3. Parallels workstation has one unique feature: it supports all versions of OS/2 and eCS as a guest - and that is why I am so concerned. If that is not cured, I probably have to stay with Ubuntu-Feisty (kernel 2.6.20-16) + Parallels as long as possible and see.
Click to expand...

You know what, I've wondered about the purpose of parallels putting the ethernet/wireless cards in promiscuous mode. Personally, I don't think this feature is needed seeing as how virtualbox and vmware doesn't do the same....

I agree that the problem is somewhere in the parallels network module and the recent kernels (2.6.22+), but you've had success with the feisty kernel. Just a thought, have you tried compiling a straight kernel from kernel.org using the same config as the feisty kernel? You might be aware that most distros tend to patch their kernels heavily. One of the patches in those kernels could be the cause of the failure w/r/t parallels, but I don't know which ones they are as the distros don't usually publish what patches were applied to their kernels.

This has been quite entertaining as well as frustrating. I'm seeing the mac version of parallels get so much attention and updates/upgrades, and we are more or less left to create a patch or workarounds in order to get parallels to work correctly. I've pretty much run out of magic at this point, so I'm sorry if I couldn't help you further.

Titetanium
 
Thanks titetanium for your patience and help!

I have now tried so many things, I must admit that I am not a linux expert, but the solution is now really up to Parallels - they should have the knowledge to fix that, as they have built the software.

It also is a pity that we do not have yet a 64-bit version for Linux, while the Mac-version is supposed to be already 64-bit compatible. This in my opinion is the only chance if they want to sell their software to linux users in future:

It must be 64-bit and has to run on kernels 2.6.22 (next Debian stable) and also 2.6.24 which is coming soon and will be part of other major distributions. And it must fully support OS/2 and eCS, otherwise linux users will move to VirtualBox.

With best regards,
Ingo
 
Same Problem

Looks like I am in the same boat. I have the Asus m2n-e as well. Disabled onboard LAN in the BIOS. Using an atheros wireless NIC. Got frustrated with the lack of access to my home's windows network with virtualbox, and ongoing issues with the installation of vmware brought me here. I am running Gutsy, and I also do not have access to the internet or my network in the guest OS: XP Pro. I tried the patch, but it doesn't seem to take. I saved the code as a text file called patch.patch and ran the patch both normally and using sudo. No dice. It just sits there and does nothing until I hit ctrl-c to break it back to the prompt.

I could fairly easily revert to Feisty, as this is a recent install and I wouldn't lose much. Is that the easiest thing to do?
 
Now things are even worse: my VM does not start anymore

upon starting the VM I get a pop-up message:

"Unable to allocate memory for monitor PE!"

This happened after I have enabled PAE for my 32-bit kernel and system to make use of the full 6GB of RAM I have installed in my PC.

I know that Parallels workstation does not run on 64-bit Linux (amd64) that's why I stayed with a 32-bit system and enabled PAE to allow up to 64GB of RAM. Works fine for all other applications, but not for Parallels.

Any solution?

With best regards,
Ingo
 
Hello,

ingo,
sorry for losing sight of this thread.
Do you still have this problem with 'monitor PE'?

Best regards,
Stacey
 
Hi Stacey,

> Do you still have this problem with 'monitor PE'?

I have given up to get Parallels running on 32-bit OS and PAE enabled to make use of full 6GB of ECC-RAM in my PC. As neither solution works:
not on 64-bit Ubuntu/Debian
not on 32-bit with PAE enabled
I have now installed 2 different Systems (selected by boot-manager):

a) old Ubuntu-Feisty with kernel 2.6.20 to run Parallels and OS/2-VM's
b) Debian-Lenny 64-bit (kernel 2.6.22) to make full use of my CPU and RAM.
Maybe I switch to 2.6.24 kernel in Ubuntu-Hardy when released in April.
On this system Parallels-Workstation does not run (only VBox).

I would try to go back to 32-bit + PAE when Parallels supports it, but it should be compatible with kernel 2.6.24 to be able to use Paralles in the next few years. Unfortunately support for Ubuntu-Feisty expires by October 2008, so I have to find a proper solution for the future.

Best regards and a Happy New Year,
Ingo
 
Hello,

the issue with monitor PE is often caused by memory allocated to a VM.
The solution was to decrease amount of memory allocated to a VM.

Best regards and Happy Holidays,
Stacey
 
I'm in the same situation. Networking was fine under Fiesty. Since Gusty upgrade it doesn't work at all. Is there a solution to this problem???
 
> Networking .... Since Gusty upgrade it doesn't work at all. Is there a solution to this problem???

I tried the latest build 2222 on Feisty. Seems it is getting even worse. From Time to time my NFS-server running on the Host (Feisty) and within the guest (Warp 4.5) is killed silently. I downgraded to build 2204 - which I was forced, since after upgrade the installed 'Parallels mouse synchronisation tools' prohibited loading of any mouse driver in OS/2 and I was left without mouse support in the guest. So I was unable to do anything in the guest - even de-installation of Parallels-Tools was not possible.

Ingo
 
Doesn't look likely that we'll get a solution to this problem. I switched to using host only networking and set up IP masquerading and now I have networking from windows (my guest OS).
 
You are right. My impression as well is that the recent builds just got some patches to install on newer Ubuntu versions. However networking in general needs a more basic rework to get reliable. Currently it is really annoying and causing lot of trouble.

Ingo
 
You must log in or register to reply here.
Back
Top