Hi! Any ideas? I have a Toshiba Tecra M5 with Windows 2008 RC1 (fully virtualized) and Fedora 8 paravirtualized. Windows works great. Got rdesktop working. Fedora works great, got vnc-server working. However, after a minute or two, networking stops working. Can''t ping FC8 can''t ping dom0, Solaris can''t ping FC8. It was working great over the weekend, where I did the install over NFS (on Friday), and spent all day Saturday on FC8 doing a ''yum update''. If I do a ''xm shutdown'' and then an ''xm start'', networking works for a few minutes. FC8 is bridged, and doing DHCP. emike
* emike@sun.com [2008-01-16 19:08:37]> I have a Toshiba Tecra M5 with Windows 2008 RC1 (fully virtualized) > and Fedora 8 paravirtualized.Which network interface does this machine have? Which build of OpenSolaris are you using? dme. -- David Edmondson, Sun Microsystems, http://dme.org
It''s an e1000g0 interface. I have the 01/10/2008 nightly build. David Edmondson wrote:> * emike@sun.com [2008-01-16 19:08:37] > >> I have a Toshiba Tecra M5 with Windows 2008 RC1 (fully virtualized) >> and Fedora 8 paravirtualized. >> > > Which network interface does this machine have? > > Which build of OpenSolaris are you using? > > dme. >
* emike@sun.com [2008-01-17 12:17:22]> It''s an e1000g0 interface. > > I have the 01/10/2008 nightly build.Then I don''t know why it fails after a while. Is anyone else here running FC8 as a PV guest? dme. -- David Edmondson, Sun Microsystems, http://dme.org
David Edmondson wrote:> * emike@sun.com [2008-01-17 12:17:22] >> It''s an e1000g0 interface. >> >> I have the 01/10/2008 nightly build. > > Then I don''t know why it fails after a while. > > Is anyone else here running FC8 as a PV guest?Yep, I have been running a 64-bit FC8 PV guest for a while. Haven''t had any problems. MRJ
Thanks! I plan on upgrading from the nightly build to build 81 asap. emike Mark Johnson wrote:> > > David Edmondson wrote: >> * emike@sun.com [2008-01-17 12:17:22] >>> It''s an e1000g0 interface. >>> >>> I have the 01/10/2008 nightly build. >> >> Then I don''t know why it fails after a while. >> >> Is anyone else here running FC8 as a PV guest? > > Yep, I have been running a 64-bit FC8 PV guest > for a while. Haven''t had any problems. > > > > MRJ >
On Thu, 17 Jan 2008, David Edmondson wrote:> * emike@sun.com [2008-01-17 12:17:22] >> It''s an e1000g0 interface. >> >> I have the 01/10/2008 nightly build. > > Then I don''t know why it fails after a while. > > Is anyone else here running FC8 as a PV guest?I''m running FC8 as a PV guest on snv_78 (along with XP via HVM) and even have the same network interface. Host: chris@fs1:~$ uname -a SunOS fs1 5.11 snv_78 i86pc i386 i86xpv Guest: chris@lx1:~$ uname -a Linux lx1 2.6.21-2952.fc8xen #1 SMP Mon Nov 19 07:06:36 EST 2007 x86_64 x86_64 x86_64 GNU/Linux FC8 dies for me too due to an NFS problem (see console output below) - a reasonable amount of NFS activity triggers it. The linux NFSv4 driver has been improved quite a bit since 2.6.21, but that''s the most recent Fedora kernel with Xen support (as far as I can tell). Of course this may not be the OPs problem, but using "xm console" to monitor the guest may throw up some clues. Cheers, Chris. Pid: 5, comm: events/0 Not tainted 2.6.21-2952.fc8xen #1 RIP: e030:[<ffffffff8814c196>] [<ffffffff8814c196>] :nfs:nfs_update_inode+0xa3/0x56a RSP: e02b:ffff880000f4bc50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff880008f47ad0 RCX: 00000000000081a4 RDX: ffff880014de8ec0 RSI: ffff880008f47ad0 RDI: ffff880007cc25d0 RBP: ffff880007cc25d0 R08: 00000000000081a4 R09: ffff8800005ac820 R10: ffff88001f7c3a70 R11: ffffffff88160470 R12: ffff880007cc2420 R13: ffff880007cc25d0 R14: 00000001001347b1 R15: ffff880008f47ad0 FS: 00002aaaaaabb230(0000) GS:ffffffff80589000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000015850000 CR4: 0000000000002620 Process events/0 (pid: 5, threadinfo ffff880000f4a000, task ffff8800005ac820) Stack: 000000001b174200 ffff880007cc25d0 ffff880008f47ad0 0000000000000000 ffff880007cc25d0 ffff8800138c64c0 ffff880008f47ad0 ffffffff8814d712 ffff880008f47a00 ffff880008f47a00 ffff88001b174200 ffffffff8815b05a Call Trace: [<ffffffff8814d712>] :nfs:nfs_post_op_update_inode+0x35/0x44 [<ffffffff8815b05a>] :nfs:nfs4_proc_delegreturn+0x14a/0x199 [<ffffffff88154c94>] :nfs:nfs_expire_automounts+0x0/0x34 [<ffffffff88165677>] :nfs:nfs_do_return_delegation+0x17/0x2a [<ffffffff8814aad9>] :nfs:nfs_dentry_iput+0x1b/0x4f [<ffffffff802c7f12>] shrink_dcache_for_umount_subtree+0x1e2/0x236 [<ffffffff802c839a>] shrink_dcache_for_umount+0x2f/0x3d [<ffffffff802c2010>] generic_shutdown_super+0x19/0xd1 [<ffffffff802c210c>] kill_anon_super+0x9/0x35 [<ffffffff8814e193>] :nfs:nfs_kill_super+0xd/0x16 [<ffffffff802c21bd>] deactivate_super+0x6a/0x83 [<ffffffff802c9fdb>] expire_mount_list+0x120/0x160 [<ffffffff88154c94>] :nfs:nfs_expire_automounts+0x0/0x34 [<ffffffff802cb1dc>] mark_mounts_for_expiry+0x85/0x96 [<ffffffff88154ca4>] :nfs:nfs_expire_automounts+0x10/0x34 [<ffffffff8024b854>] run_workqueue+0x8f/0x137 [<ffffffff802484a0>] worker_thread+0x0/0x11f
* chris@sorted.org [2008-01-17 12:54:36]> FC8 dies for me too due to an NFS problem (see console output below) - > a reasonable amount of NFS activity triggers it. The linux NFSv4 > driver has been improved quite a bit since 2.6.21, but that''s the most > recent Fedora kernel with Xen support (as far as I can tell).Off on a tangent, but did you realise that you can force Solaris to only allow NFSv2 and NFSv3? (See NFS_CLIENT_VERSMAX in /etc/default/nfs.) dme. -- David Edmondson, Sun Microsystems, http://dme.org
On Thu, 17 Jan 2008, David Edmondson wrote:> * chris@sorted.org [2008-01-17 12:54:36] >> FC8 dies for me too due to an NFS problem (see console output below) - >> a reasonable amount of NFS activity triggers it. The linux NFSv4 >> driver has been improved quite a bit since 2.6.21, but that''s the most >> recent Fedora kernel with Xen support (as far as I can tell). > > Off on a tangent, but did you realise that you can force Solaris to > only allow NFSv2 and NFSv3? (See NFS_CLIENT_VERSMAX in > /etc/default/nfs.)I didn''t, thanks, I''ll give that a go over the weekend. Cheers, Chris.
* chris@sorted.org [2008-01-17 13:05:50]> On Thu, 17 Jan 2008, David Edmondson wrote: >> * chris@sorted.org [2008-01-17 12:54:36] >>> FC8 dies for me too due to an NFS problem (see console output below) - >>> a reasonable amount of NFS activity triggers it. The linux NFSv4 >>> driver has been improved quite a bit since 2.6.21, but that''s the most >>> recent Fedora kernel with Xen support (as far as I can tell). >> >> Off on a tangent, but did you realise that you can force Solaris to >> only allow NFSv2 and NFSv3? (See NFS_CLIENT_VERSMAX in >> /etc/default/nfs.) > > I didn''t, thanks, I''ll give that a go over the weekend.Actually, it''s NFS_SERVER_VERSMAX in this case, but hey :-) dme. -- David Edmondson, Sun Microsystems, http://dme.org
On Thu, Jan 17, 2008 at 12:24:00PM +0000, David Edmondson wrote:> * emike@sun.com [2008-01-17 12:17:22] > > It''s an e1000g0 interface. > > > > I have the 01/10/2008 nightly build. > > Then I don''t know why it fails after a while. > > Is anyone else here running FC8 as a PV guest?Might not be the same problem, but I have experienced the same thing with several Linux distributions installed as PV guests on NV78. I didn´t pursue it further at that point since I thought I should upgrade Nevada first. But since others seem to experience something similar... I do see these messages in my log file: xnb: [ID 873713 kern.warning] WARNING: xnb_alloc_page: Cannot allocate memory to transfer packets to peer Seem to correlate to when the guest tries to access the network in some way (either during installation or when running an already installed guest). Regards, Mikael Dalsgard
* mikaeld@dalsgard.fupp.net [2008-01-17 13:53:55]> xnb: [ID 873713 kern.warning] WARNING: xnb_alloc_page: Cannot > allocate memory to transfer packets to peerThis I can explain :-) Until build 81 is available the Solaris network backend uses "page flipping" to transfer packets from the IO domain to the guest. To do this it needs to allocate a page to flip. The message you are seeing is the failure to allocate a page. This happens when the hypervisor has no free memory to give to the IO domain (obviously). Build 81 includes support for an alternative mechanism where guest domains advertise pages into which the IO domain copies packet data. No memory allocation is necessary. It''s usually possible to avoid this problem by constraining the amount of memory given to dom0 (using the "dom0_mem" to Xen in grub''s menu.lst), as it seems to occur much more frequently when ballooning is used. dme. -- David Edmondson, Sun Microsystems, http://dme.org
I''ve done this before for the same reason, stability. There''s also a few kernel tunables to look for, such as if you have OSX clients. (insecure equivalent must be done through kernel tunable for instance) I''ve had a fair amount of problems even to this date with Linux NFSv4 when used with Solaris, it mounts and can see shares for example, but has unexpected timeouts and occasionally with some flaky nics drops the connection out. (Mainly on the Linux side) I haven''t seen any performance improvements trying out v4, maybe slightly less CPU, and then the more advanced features I don''t need at the moment, although it''s indefinitely a more secure option if you''ve got a KDC and want to use it. For my home network, it''s overkill. James On Jan 17, 2008, at 5:01 AM, David Edmondson wrote:> * chris@sorted.org [2008-01-17 12:54:36] >> FC8 dies for me too due to an NFS problem (see console output >> below) - >> a reasonable amount of NFS activity triggers it. The linux NFSv4 >> driver has been improved quite a bit since 2.6.21, but that''s the >> most >> recent Fedora kernel with Xen support (as far as I can tell). > > Off on a tangent, but did you realise that you can force Solaris to > only allow NFSv2 and NFSv3? (See NFS_CLIENT_VERSMAX in > /etc/default/nfs.) > > dme. > -- > David Edmondson, Sun Microsystems, http://dme.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org
Thanks David! Now it proceeds. :-) Do I understand you correctly if I interpret your mail as saying this workaround is not needed anymore on NV81 onwards? Regards, Mikael On Thu, Jan 17, 2008 at 02:04:45PM +0000, David Edmondson wrote:> * mikaeld@dalsgard.fupp.net [2008-01-17 13:53:55] > > xnb: [ID 873713 kern.warning] WARNING: xnb_alloc_page: Cannot > > allocate memory to transfer packets to peer > > This I can explain :-) > > Until build 81 is available the Solaris network backend uses "page > flipping" to transfer packets from the IO domain to the guest. To do > this it needs to allocate a page to flip. The message you are seeing > is the failure to allocate a page. > > This happens when the hypervisor has no free memory to give to the IO > domain (obviously). > > Build 81 includes support for an alternative mechanism where guest > domains advertise pages into which the IO domain copies packet > data. No memory allocation is necessary. > > It''s usually possible to avoid this problem by constraining the amount > of memory given to dom0 (using the "dom0_mem" to Xen in grub''s > menu.lst), as it seems to occur much more frequently when ballooning > is used. > > dme. > -- > David Edmondson, Sun Microsystems, http://dme.org
* mikaeld@dalsgard.fupp.net [2008-01-22 14:50:33]> Do I understand you correctly if I interpret your mail as saying > this workaround is not needed anymore on NV81 onwards?Providing that the guest domain also supports the copy mechanism (most current Linux distributions do) the workaround should not be required from nv81 onward. dme. -- David Edmondson, Sun Microsystems, http://dme.org