Network Problems in Parallel XP on Ubuntu

Hello Stacey,

you do propose to configure the Network for OS/2. I think that is not the issue, because:

I am using the very same VM (*.hdd and *.pvs) under Feisty and they work.
Just booting Gusty and starting precisely the same VM, gives network-problems.

My VM has been set up to use a fixed IP and not DHCP!

To verify whether it is caused by Ubuntu Gusty, I did the same tests under Debian Lenny.
Lenny has very similar versions of kernel and cups. The only difference here is that Lenny does not freeze, but reports thousands of lost IRQ's:

pp:/home/ingo# tail /var/log/messages
Nov 12 12:17:25 pp cups-lpd[4155]: Connection from 192.168.0.21 (IPv4
192.168.0.21)
Nov 12 12:17:25 pp cups-lpd[4155]: Receive print job for Queue
Nov 12 12:17:25 pp kernel: rtc: lost some interrupts at 1024Hz.
Nov 12 12:17:56 pp last message repeated 1517 times
Nov 12 12:18:20 pp last message repeated 1211 times
Nov 12 12:18:20 pp syslogd 1.5.0#1: restart.
Nov 12 12:18:20 pp kernel: rtc: lost some interrupts at 1024Hz.
Nov 12 12:18:22 pp last message repeated 97 times
Nov 12 12:18:22 pp cups-lpd[4155]: Closing connection
Nov 12 12:18:22 pp kernel: rtc: lost some interrupts at 1024Hz.
pp:/home/ingo#

So it is likely that something is wrong with the network-module built by Parallels?
Or do you think it is related to CUPS 1.3.2?

Best regards,
Ingo
 
Last edited:
Hello Stacey,

as said before: OS/2 and network ist working perfectly under Ubutu-Feisty and Parallels Build 2204.
Exactly the same VM (*.pvs) and the same VD (*.hdd) under Gusty cause problems!

Best regards,
Ingo
 
Found a quick and easy way to reproduce the problem!

Hello Stacey,

here I describe you an easy way to reproduce the network problems under Ubuntu-Gusty (kernel 2.6.22-14):

start Parallels
open a xterm window
boot the VM (in my case it is Warp 4.5)

while VM is booting, execute following command in the xterm:

'netstat -tlen'

You'll see some strange characters as output, then the xterm crasches and depending on the situation even te whole system may freeze!

With best regards,
Ingo
 
Hello,

thank you for your feedback.
Could you please tell me what types of connection do you use in Ubutu-Feisty and in Ubuntu-Gusty?

Best regards,
Stacey
 
Stacey M said:
Hello,

thank you for your feedback.
Could you please tell me what types of connection do you use in Ubutu-Feisty and in Ubuntu-Gusty?

Best regards,
Stacey
Click to expand...

Let's start with the hardware:
MB: ASUS M2N-E with nForce 570-Ultra Chipset
Driver: forcedeth (eth0)
Configuration (ifconfig) with fixed IP4-address:
eth0 Protokoll:Ethernet Hardware Adresse 00:18:F3:D1:1A:E5
inet Adresse:192.168.0.11 Bcast:192.168.0.255 Maske:255.255.255.0
inet6 Adresse: fe80::218:f3ff:fed1:1ae5/64 Gültigkeitsbereich:Verbindung

connected to a router/switch, which also has a DHCP-server built in and running. However it only assigns the address space 192.168.0.100 - 192.168.0.199 (just for network installations).

On the host-PC I have running following servers:
CUPS (port 631), cups-lpd (port 515), portmap (port 111) , nfs (ports see below from rpcinfo):

ingo@pp:~$ netstat -tlen
Activ Internet connections (Only Server)
Proto Recv-Q Send-Q Local Address Foreign Address State Benutzer Inode
tcp 0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 0 18101
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN 0 18267
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN 0 18364
tcp 0 0 0.0.0.0:709 0.0.0.0:* LISTEN 0 18333
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 15420
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN 0 21700
tcp 0 0 0.0.0.0:56602 0.0.0.0:* LISTEN 110 18474
tcp 0 0 0.0.0.0:56762 0.0.0.0:* LISTEN 0 18286
tcp 0 0 127.0.0.1:2046 0.0.0.0:* LISTEN 1000 19754
tcp 0 0 127.0.0.1:2207 0.0.0.0:* LISTEN 108 18112
tcp6 0 0 :::631 :::* LISTEN 0 21699


ingo@pp:~$ rpcinfo -p 192.168.0.11
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 32768 nlockmgr
100021 3 udp 32768 nlockmgr
100021 4 udp 32768 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 56762 nlockmgr
100021 3 tcp 56762 nlockmgr
100021 4 tcp 56762 nlockmgr
100005 1 udp 706 mountd
100005 1 tcp 709 mountd
100005 2 udp 706 mountd
100005 2 tcp 709 mountd
100005 3 udp 706 mountd
100005 3 tcp 709 mountd
100024 1 udp 32770 status
100024 1 tcp 56602 status

Within the guest in Parallels-VM there is currently no server activated, but on demand I start a ftp-server under OS/2 and sometimes also a nfs-server to realise 'shared folders'.

If you do need more information, please let me know.

With best regards,
Ingo
 
Stacey M said:
Hello,

ingo,
try to perform these steps in order to configure your network in OS/2.

cbs and Crischan,
Bridged Ethernet networking allows VMs to access a physical network, but then the VM will be seen as individual PC in your sub network.
cbs, as I can see from your messages, the IP-address in Windows is 169.254.128.244. That means that none of the DHCP-servers can provide your Windows VM with an IP-address. Try to contact your network administrator.
Crischan, what type of connection are you using in VMWare?

Best regards,
Stacey
Click to expand...

The computer running parallels (gusty) grabs IP's from DHCP server-- no problem. Other windows xp machines and linux machines on my network grap IP's fine.

Entertaining the idea that it may be a DHCP issue, I have manually provided the virtual xp machine with a valid unique IP address, and it still cannot ping the gateway.

Here are some more details:

I reboot my machine, issue the 'sudo parallels-config' and here is what I get now.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiling Parallels Workstation 2.2 drivers...
Drivers have been compiled successfully.
Installing drivers...
Starting drivers...
Loading Parallels Workstation 2.2 hypervisor ...
Loading Parallels Workstation 2.2 vm-main ...
Loading Parallels Workstation 2.2 vm-bridge ...
Loading Parallels Workstation 2.2 vmvirtualnic ...
Parallels Workstation has been successfully configured

Now you can run Parallels Workstation 2.2
Issue parallels command.

cbs@cbs-laptop:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:13:A9:60:74:8A
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:17

eth1 Link encap:Ethernet HWaddr 00:18:DE:8D:89:5A
inet addr:10.10.10.102 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: fe80::218:deff:fe8d:895a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:87 errors:3 dropped:40 overruns:0 frame:0
TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12774 (12.4 KB) TX bytes:11526 (11.2 KB)
Interrupt:18 Base address:0xe000 Memory:cc000000-cc000fff

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)

vnic0 Link encap:Ethernet HWaddr 00:01:23:45:BE:EF
inet addr:10.37.129.2 Bcast:10.37.129.255 Mask:255.255.255.0
inet6 addr: fe80::201:23ff:fe45:beef/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5038 (4.9 KB) TX bytes:5038 (4.9 KB)

~~~~~~~~~~~~~~~~~~~~~~
My network paramaters are as follows:

I know I don't need such a large subnet, but 192.168.xxx.xxx was getting old.
10.10.10.0/8
gateway: 10.10.10.1
DHCP 10.10.10.100-149
~~~~~~~~~~~~~~~~~~~~~~

I notice the vnic0 gets a weird 10.37.129.2 address, no idea where that comes from.

In parallels, under network adapter settings it is "bridged ethernet" manually to "eth1".

Thanks!
 
Last edited:
Hello,

cbs,
could you please provide me with a screenshot of 'Network Adapter Options' from Configuration Editor of your VM?
Also please tell me if you have made any changes in 'Advanced' tab of 'Network Adapter Options', especially in MAC address field.

Best regards,
Stacey
 
Stacey M said:
Crischan,
unfortunately, the current version of Parallels Workstation does not have Shared Network and does not support NAT, but this feature will be available in future updates.
But you can try to use the solution I suggested to cbs.

Best regards,
Stacey
Click to expand...

Hmm, I don't get this. A while back I had asked if it was possible to make Workstation have shared networking. Well, hate to break it to you, but it does, just not the way you think.

There was a KB/howto article that explained how to set this up. Its not there now, but I can tell you I have mine set to host-based networking. As I understand it, this is supposed to allow communication between the guest and host only, no outside connection is supposed to be possible from the guest. With ip forwarding active, and setting my firewall to do NAT between the parallels network interface and my wireless card, I have outside connectivity from the guest as well as host-based connectivity. Further, I can communicate with the VM on the server at work from the guest as well. (I couldn't figure out how that worked, but it does and I'll take it any day of the week). So basically in a nutshell, my host machine is doing the NAT work, effectively hiding the guest from the network. If this isn't shared networking or close to it, I don't know what is.
 
Hello,

sorry I did not make everything quite clear. There is no option to enable Shared Networking.
But there is a solution that can create a Network very similar with Shared Network.

Best regards,
Stacey
 
Can someone please post how to do this. Without some guest OS internet connection Parallels is completely useless.
 
Network problems in Ubuntu-Gusty, any further info needed?

Hello Stacey,

I absolutely cannot get networking to be reliable in Gusty (with Feisty all is fine).
I tried to collect some more information and found that at the moment when eth0 (module forcedeth) is switching to promiscous mode, the system freezes. Here the corresponding tail from /var/log/messages:

Nov 27 16:31:34 pp kernel: [ 52.440000] hypervisor: module license 'unspecified' taints kernel.
Nov 27 16:31:34 pp kernel: [ 52.450000] [ 6093] Device /dev/hypervisor registered with 10.63
Nov 27 16:31:34 pp kernel: [ 52.460000] [ 6093] parallels Hypervisor 2.2-2204 initialized.
Nov 27 16:31:34 pp kernel: [ 52.570000] vm_main: no version for "appIncCounter" found: kernel tainted.
Nov 27 16:31:34 pp kernel: [ 52.580000] [ 6104] Device /dev/vm-main registered with 10.62
Nov 27 16:31:34 pp kernel: [ 52.580000] [ 6104] Parallels Workstation 2.2-2204 Main module initialized.
Nov 27 16:31:34 pp prl_dhcpd[6137]: Parallels DHCP daemon is starting
Nov 27 16:31:35 pp prl_dhcpd[6137]: Parallels DHCP daemon at vnic0 scope: 10.37.129.1-10.37.129.254(255.255.255.0)
Nov 27 16:31:35 pp prl_dhcp[6144]: Parallels DHCP server for virtual NIC started.
Nov 27 16:31:35 pp prl_dhcp[6144]: Parallels DHCP server for virtual NIC reading configuration.
Nov 27 16:31:35 pp kernel: [ 53.110000] device vnic0 entered promiscuous mode
Nov 27 16:31:35 pp kernel: [ 53.110000] audit(1196177494.593:2): dev=vnic0 prom=256 old_prom=0 auid=4294967295
Nov 27 16:34:45 pp kernel: [ 243.310000] [ 6460] svm_support_on(): SVM mode activated
Nov 27 16:34:45 pp kernel: [ 243.320000] device eth0 entered promiscuous mode
Nov 27 16:34:45 pp kernel: [ 243.320000] audit(1196177684.596:3): dev=eth0 prom=256 old_prom=0 auid=4294967295

Then the only coice to recover is to hit the reset-button.

Is there any progress on solving this issue?

With best regards,
Ingo

P.S.: I have kept a copy of the log from Feisty (all ok) and Gusty from booting until 'networking is doing fine' (Feisty) and 'Crash' (Gusty).
 
some more information (workaround?)

I am still 'playing' with Gusty and by accident found a way to at least avoid the crashes of the whole system:

when building the original Gusty kernel 2.6.22.9 with modified options it no longer crashes with Parallels and networking. I modified following:

a) disabled 'tickless function'
b) enabled IRQ balancing

After that the crashes are gone. So my suspicion is that at least the combination:

tickless kernel + network forthdeth + promiscuous mode + Pacifica virtualisation + Parallels vmvirtualnic

is responsible for the problems. As the same is observed under Debian Lenny, my asumption is that 'vmvirtualnic' is not prepared to handle the new tickless feature of the 2.6.22 kernel.
 
That would be an incorrect conclusion, as I have the tickless+dynticks+force hpet feature enabled in 2.6.22.14 and it works with parallels without any workarounds.

There is one thing you might want to check for when using the tickless feature though, enable force hpet on your kernel to see if that solves your problem. Google for the force hpet patch for 2.6.22.
 
> enable force hpet on your kernel

Checked out that patch, but had to realize it is only for Intel-Chipsets.
I am running here an Athlon64-X2 on ASUS M2N-E.
In the kernel configuration 'High Resolution Event Timer' (HRET) is activated. I am not sure whether that is the same? Anyhow, did not find a 'hpet-force' patch for my nForce570-Ultra Chipset.

On the other hand I doubt, that Parallels has ever been tested on Ubuntu-Gusty with similar hardware, seems that I am not alone with severe network problems. My hardware is carefully selected to be fully supported by Linux kernel 2.6.18 and up. I even have 2GB ECC-RAM and that is why I have originally patched the 2.6.22 kernel: to monitor RAM errors and corrections with 'edac-utils' (there have none been reported since a week).
 
I have an Intel PIII mobile cpu. In perusing the force-hpet patch, it's for core duo and higher cpus. So in theory, it wouldn't work on my laptop. Note I said "in theory".

I patched the kernel with the force-hpet patch, and made 2 kernels: 1 with and 1 without to see if there was a difference.

Testing when running the run of the mill apps, I didn't notice much difference. With powertop running, I did notice something that did show a difference:

Kernel 2.6.22.14 without force-hpet patch+tickless: parallels hooks the rtc, and my wakeups from idle/second jumps from 170's to 1200's and stays that way even when parallels is closed/killed.

Kernel 2.6.22.14 with force-hpet patch+tickless: parallels is unable to hook the rtc, and my wakeups from idle/second stays at 170's at all times. Battery life is improved by an additional 20 minutes of runtime.

Even though my kernel doesn't have an hpet timer, the patch does work in an indirect way, probably by emulating the hpet timer when there is none in hardware. Applications are unable to hook the rtc and a warning pops up stating this. Operations/performance seems to be unaffected subjectively.
 
Tested with vanilla 2.6.23.9 kernel - it does not compile

To check whether the network problems are related to the kernel, I installed kernel 2.6.23.9 (latest stable) from kernel.org.
With tis kernel Parallels fails to compile its modules:

Can not compile and/or link drivers. Read /usr/lib/parallels/doc/INSTALL
and follow instructions specified in this document.
Compilation log is available at /usr/lib/parallels/comp.log.6594.error

Here the content of sais logfile:
(remark: 'Fehler' is Germen and translates to 'Error')

root@pp:/home/ingo# cat /usr/lib/parallels/comp.log.6594.error
cd drivers && make KSRC=/lib/modules/2.6.23.9-ingo1/build clean && cd ../
make[1]: Betrete Verzeichnis '/usr/lib/parallels/drivers'
cd drv_main/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_main'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
cd common; rm -rf *.o .*.cmd .tmp_versions; cd ..
cd mm; rm -rf *.o .*.cmd .tmp_versions; cd ..
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_main'
cd hypervisor/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/hypervisor'
/bin/sh: [[: not found
/bin/sh: [[: not found
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/hypervisor'
cd drv_net/linux/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_net/linux'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_net/linux'
cd drv_virtualnic/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_virtualnic'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_virtualnic'
make[1]: Verlasse Verzeichnis '/usr/lib/parallels/drivers'
cd drivers && make KSRC=/lib/modules/2.6.23.9-ingo1/build all && cd ../
make[1]: Betrete Verzeichnis '/usr/lib/parallels/drivers'
cd drv_main/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_main'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
cd common; rm -rf *.o .*.cmd .tmp_versions; cd ..
cd mm; rm -rf *.o .*.cmd .tmp_versions; cd ..
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_main'
cd hypervisor/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/hypervisor'
/bin/sh: [[: not found
/bin/sh: [[: not found
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/hypervisor'
cd drv_net/linux/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_net/linux'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_net/linux'
cd drv_virtualnic/ && make clean && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_virtualnic'
rm -rf *.o *.ko .*.cmd *.mod.c .tmp_versions
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_virtualnic'
cd drv_main/ && make KSRC=/lib/modules/2.6.23.9-ingo1/build && cd ..
make[2]: Betrete Verzeichnis '/usr/lib/parallels/drivers/drv_main'
make -C /lib/modules/2.6.23.9-ingo1/build SUBDIRS=/usr/lib/parallels/drivers/drv_main SRCROOT=/usr/lib/parallels/drivers/drv_main modules
make[3]: Betrete Verzeichnis '/usr/src/linux-2.6.23.9'
CC [M] /usr/lib/parallels/drivers/drv_main/vmmain.o
In file included from /usr/lib/parallels/drivers/drv_main/vmmain.c:29:
/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: In Funktion »init_module«:
/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
make[3]: Verlasse Verzeichnis '/usr/src/linux-2.6.23.9'
make[2]: *** [all] Fehler 2
make[2]: Verlasse Verzeichnis '/usr/lib/parallels/drivers/drv_main'
make[1]: *** [vmmain] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/lib/parallels/drivers'
make: *** [build] Fehler 2
root@pp:/home/ingo#


So I am rather helpless now how to get Parallels work with kernel 2.6.22 and up.
(also with 2.6.22.9 in Debian Lenny it does compile, but network problems persist).

Best regards,
Ingo
 
Hello,

regarding your problem with compiling: did you install kernel headers and kernel-devel?
If so, please create a right symlink.

Best regards,
Stacey
 
of course I also installed the matching linux-headers.
I compiled the kernel with 'make-kpkg --initrd --revision=ingo1 binary'
installed the Kernel and headers from the deb-package with 'dpkg -i ...'

Directory content of /usr/src is like this:

root@pp:/usr/src# ls -l
insgesamt 264592
lrwxrwxrwx 1 root src 14 2007-11-29 17:29 linux -> linux-2.6.23.9
drwxrwxr-x 21 root root 4096 2007-11-30 15:27 linux-2.6.23.9
-rw-r--r-- 1 root src 4313194 2007-11-30 14:29 linux-doc-2.6.23.9-ingo1_ingo1_all.deb
lrwxrwxrwx 1 root src 28 2007-11-30 15:33 linux-headers -> linux-headers-2.6.23.9-ingo1
drwxr-xr-x 19 root root 4096 2007-10-28 20:22 linux-headers-2.6.22-14
drwxr-xr-x 5 root root 4096 2007-11-29 16:43 linux-headers-2.6.22-14-generic
drwxr-xr-x 19 root root 4096 2007-11-30 14:54 linux-headers-2.6.23.9-ingo1
-rw-r--r-- 1 root src 8863952 2007-11-30 15:26 linux-headers-2.6.23.9-ingo1_ingo1_i386.deb
-rw-r--r-- 1 root src 210906520 2007-11-30 15:33 linux-image-2.6.23.9-ingo1_ingo1_i386.deb
-rw-r--r-- 1 root src 2130 2007-11-30 14:29 linux-manual-2.6.23.9-ingo1_ingo1_all.deb
-rw-r--r-- 1 root src 46527328 2007-11-30 14:29 linux-source-2.6.23.9-ingo1_ingo1_all.deb
drwxr-xr-x 2 ingo users 4096 2007-11-29 17:31 patches
root@pp:/usr/src#


My kernel running reports as:

root@pp:/usr/src# uname -r
2.6.23.9-ingo1


Best regards,
Ingo

P.S.: if you need translation from Germen -> English for some expressions in the error-log, please let me know:
 
Last edited:
You must log in or register to reply here.
Back
Top