Well, Parallels support is basically telling me "SOL" in ticket #997656, because FreeBSD 8.1 (amd64) is not supported, only 7.x is, but maybe someone here has been trying a bit harder than they have? Poor me didn't see that, or expected it before migrating an entire legacy Intel box (Celeron 566Mhz, 256MB RAM, 1U pizza box case) onto Parallels 5.0 (under Mac Mini /w 4GB), especially since the the install went without a hitch, and the problems only turned up once the box was pushing production traffic. Quoting from the ticket: Computer Type: Mac Mini Build Number: 9376 (5.x) Amount of memory: 4GB and more Host OS: Mac OS X 10.6.x Snow Leopard Host OS details: Guest OS: FreeBSD Guest OS type: 64-bit Number of CPUs in Virtual machine: 1 Amount of Guest OS memory: 2GB I have a FreeBSD 8.1 guest (amd64 build) installed with 2GB on a 4GB Mac Mini, the VM model chosen is "FreeBSD other", but I've tried "FreeBSD 7.x" with no observed change in behavior. The network adapter used is "ed0", and the performance through it is atrocious, and seems to consume major amounts of CPU. I've seen a few remarks in the support forum regarding vaguely similar issues with the realtek driver, and the suggestion was to reduce the VM from 2 to 1 CPUs: no visible effect with that change. vmstat -i shows: sonet:~# vmstat -i interrupt total rate irq1: atkbd0 557 0 irq6: fdc0 9 0 irq14: ata0 622643 13 irq23: ed0 1355320 29 cpu0: timer 18178514 400 Total 20157043 443 top -S shows: last pid: 95064; load averages: 6.27, 5.40, 5.34 up 0+12:39:59 10:26:19 145 processes: 6 running, 125 sleeping, 14 waiting CPU: 1.1% user, 0.0% nice, 32.6% system, 66.3% interrupt, 0.0% idle Mem: 553M Active, 834M Inact, 387M Wired, 32M Cache, 213M Buf, 166M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 12 root 14 -60 - 0K 224K WAIT 179:06 57.91% intr 94942 root 1 98 0 5804K 1740K RUN 0:08 9.96% rsync 1025 root 1 97 0 10852K 1968K RUN 57:34 5.96% vtund This is with an rsync running at only ~300KB/s (barely 3Mbps). At this point, the machine is basically unresponsive - outbound ping is encountering a "ping: sendto: No buffer space available", and ping times to the local default gw (192.168.1.1) are reaching 100's of ms. My vtund (VPN tunnel daemon) experiences 25% CPU load, with barely 20-30KB/s going through it - ktrace'ing it seems to show that SELECT() calls to the network interface take ages to return (10-150ms!). Known issue? Any resolution? Thank you.
Hi, there is a port of faster network-driver, it can make the trick http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/parallels-tools Also (if new driver will not help) - the PD5 issue - you can try to disable APIC in BSD boot-args http://keramida.wordpress.com/2007/12/10/disabling-apic-on-freebsd/ PS: just a notice: in PD6 the situation is completely different. PD6 provides emulation of e1000 network adapter
Thank you Elric! Wow. there's a FreeBSD port for the parallels-tools. I google'd this extensively, but never turned that up. I installed the port and rebooted, but it seems to me that I might have to recompile the kernel in its entirety for this to activate - do you know if this is required? What does the port actually do? Establish a new network interface ? (That being said, a reboot of the machine after the port install did change behavior temporarily - I got some >1000KB/s rsync speeds out of the ed0 interface with about 15% CPU on interrupts, but this deteriorated within 10 minutes to <200KB/s and 50%++ CPU for interrupts). And as you mention PD6: wow, just: wow. Why did support not point me to THIS? http://www.parallels.com/products/desktop/system-requirements/ says: 64-bit Operating Systems ... FreeBSD 8.x,7.x I am rebuilding the kernel now, to see if this changes things, and will try to disable APIC if it does not.
Rebooted with the new kernel : no effect, still performance issues: trying to find documentation on the Parallels port and how to use/activate it. What new device is it creating+supporting? I added the 2nd CPU back in - interrupt use of CPU reached >90% for one CPU. Booted right out of the FreeBSD boot menu into "no ACPI" mode - hangs during kernel boot. Booted with set hint.apic.0.disabled="1" in the boot loader - hangs during kernel boot right after "load_dn_sched dn_shed PRIO loaded" (same as with "no ACPI"). Booted with same hint.apic.0.disabled="1" in the loader.conf - hangs as well. Now that I am thinking of it: 2 CPUs *require* APIC to work, don't they?
The port just implements network driver.. It seems that it is not very helpful in your case, because you have interrupt flood inside guest Yep. 2CPU will not work with apic disabled Your support-case is rare.. there is not so many supporters know these details.. I'd suggest to try PD6. There was some efforts to make BSD work on it and if you will find any issue with it, it will be fixed asap
Support has provided me with a trial key for PD6 - I couldn't wait any longer, so I upgraded, but I am being promised the official upgrade keys within 2-3 days. An upgrade to PD6 indeed changed the FreeBSD virtual device from ed0 to em0 : em0: <Intel(R) PRO/1000 Legacy Network Connection 1.0.1> port 0x8200-0x821f mem 0xee000000-0xee01ffff irq 23 at device 5.0 on pci0 Preliminary testing (with 2 CPUs) shows that when pushing >10Mbps of traffic through the interface, the amount of CPU spent on interrupts remains in the 1-2% range, and all is well! So the resolution for this issue is: Must upgrade to Parallels Desktop 6 (and reconfigure networking on the guest to use em0 as the primary interface, as configured into your options in /etc/rc.conf and likely rc.firewall or rc.firewall.local, as applicable). The Parallels-tools remain in my kernel, but appear to have no effect: this is a console-only (non-X11) FreeBSD 8.1 guest. Thank you.
