Hello I''m trying to get my NFS Xen vm guest systems to their host via NFS (within the same machine but keep getting performance-related errors): nfs: server [IP] not responding, still trying nfs: server [IP] OK [loops] Connectivity is flaky at best and applications running within the Xen guests keep crashing or freezing as a result. There is a note at a LTSP site that says NFS has problems with the 2.6 Kernel and discrepancies in NIC capacity between the host and client if the NFS block sizes are too large: http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding Does this apply to Xen too? Their fix: pass on kernel options to the NFS client. How could I try this with Xen? Thanks for any help! M -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
it could be a few different things... 1. check the physical cables. use a good, comprehensive tester (not those cheap testers) -> make sure there is no physical damage to the cable -> make sure the ends are crimped properly (sheath is under the rj45 pincher) 2. Verify the capability of your NFS server. Many NFS server based on general purpose OS''s cannot do more than an 8K rsize/wsize. You must adjust your client to match. -> if you have a netapp, the default could be 8K or 32K. run "options nfs" to find out 3. Verify the connectivity at the switches. -> Make sure there are no duplex mismatches. (this should not happen at Gige, but happens all the time on 100BT) -> If using GigE, verify Flow Control and, if possible, set it to on in both directions. ---> some switches do not support flow control in both directions Hope this helps... --tmac On Jan 31, 2008 4:12 PM, Mark Furner <mark.furner@gmx.net> wrote:> Hello > > I''m trying to get my NFS Xen vm guest systems to their host via NFS > (within the same machine but keep getting performance-related errors): > > nfs: server [IP] not responding, still trying > nfs: server [IP] OK > [loops] > > Connectivity is flaky at best and applications running within the Xen > guests keep crashing or freezing as a result. > > There is a note at a LTSP site that says NFS has problems with the 2.6Kernel and discrepancies in NIC capacity between the host and client if the > NFS block sizes are too large: > http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding > Does this apply to Xen too? > Their fix: pass on kernel options to the NFS client. How could I try this > with Xen? > > Thanks for any help! > > M > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >-- --tmac RedHat Certified Engineer #804006984323821 (RHEL4) RedHat Certified Engineer #805007643429572 (RHEL5) Principal Consultant, RABA Technologies _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Tmac! There is no cabling involved. The Xen guest and Xen host are the same machine. SO I think it might be No 2. I''m wondering if there is a discrepancy in NFS blocksize, as the LTSP project site below suggested (see quote)? I''m using a Xen Dom0 host with Ubuntu 7.10 with mounted LVM drives that are also exported via NFS to allow simultaneous access by the Xen guests (usually Ubuntu 6.10 or Debian etch). [quote] The problem is caused by the 2.6 kernels using a large default blocksize for NFS packets. The 2.6 kernels use 32k blocks, where the older kernels used 8k blocks. What happens is the 32k byte blocks need to be broken down into 1500 byte datagrams. Simple math will tell you that you need a whole lot more 1500 byte datagrams to make up a full 32kbyte block. Sending those datagrams to a 10mbit card takes too long for all of the datagrams to get there, so the NFS client times out before getting all of the fragments. [unquote] Their suggested fix is [quote] You need to pass some options to the client to tell it to use smaller block sizes for NFS. [unquote] I don''t know if this looks plausible to you, but am trying the following NFS mount options in my Xen guest: rsize=2048,wsize=2048 Regards M -------- Original-Nachricht --------> Datum: Fri, 1 Feb 2008 08:23:36 -0500 > Von: tmac <tmacmd@gmail.com> > An: "Mark Furner" <mark.furner@gmx.net> > CC: Xen-Users <xen-users@lists.xensource.com> > Betreff: Re: [Xen-users] Xen guest nfs client not responding> it could be a few different things... > > 1. check the physical cables. use a good, comprehensive tester (not those > cheap testers) > -> make sure there is no physical damage to the cable > -> make sure the ends are crimped properly (sheath is under the rj45 > pincher) > 2. Verify the capability of your NFS server. Many NFS server based on > general purpose OS''s > cannot do more than an 8K rsize/wsize. You must adjust your client to > match. > -> if you have a netapp, the default could be 8K or 32K. run "options nfs" > to find out > 3. Verify the connectivity at the switches. > -> Make sure there are no duplex mismatches. (this should not happen at > Gige, but happens all the time on 100BT) > -> If using GigE, verify Flow Control and, if possible, set it to on in > both > directions. > ---> some switches do not support flow control in both directions > > Hope this helps... > > --tmac > > On Jan 31, 2008 4:12 PM, Mark Furner <mark.furner@gmx.net> wrote: > > > Hello > > > > I''m trying to get my NFS Xen vm guest systems to their host via NFS > > (within the same machine but keep getting performance-related errors): > > > > nfs: server [IP] not responding, still trying > > nfs: server [IP] OK > > [loops] > > > > Connectivity is flaky at best and applications running within the Xen > > guests keep crashing or freezing as a result. > > > > There is a note at a LTSP site that says NFS has problems with the > 2.6Kernel and discrepancies in NIC capacity between the host and client if the > > NFS block sizes are too large: > > http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding > > Does this apply to Xen too? > > Their fix: pass on kernel options to the NFS client. How could I try > this > > with Xen? > > > > Thanks for any help! > > > > M > > -- > > Psssst! Schon vom neuen GMX MultiMessenger gehört? > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > > > > -- > --tmac > > RedHat Certified Engineer #804006984323821 (RHEL4) > RedHat Certified Engineer #805007643429572 (RHEL5) > > Principal Consultant, RABA Technologies-- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
try 1024, 2048, 4096, 8192, 16384, 32768. You should (almost) always use the largest r/wsize that you can for optimal throughput. --tmac On Feb 2, 2008 4:47 PM, Mark Furner <mark.furner@gmx.net> wrote:> Thanks Tmac! > > There is no cabling involved. The Xen guest and Xen host are the same > machine. SO I think it might be No 2. I''m wondering if there is a > discrepancy in NFS blocksize, as the LTSP project site below suggested (see > quote)? I''m using a Xen Dom0 host with Ubuntu 7.10 with mounted LVM drives > that are also exported via NFS to allow simultaneous access by the Xen > guests (usually Ubuntu 6.10 or Debian etch). > > [quote] > The problem is caused by the 2.6 kernels using a large default blocksize > for NFS packets. The 2.6 kernels use 32k blocks, where the older kernels > used 8k blocks. What happens is the 32k byte blocks need to be broken down > into 1500 byte datagrams. Simple math will tell you that you need a whole > lot more 1500 byte datagrams to make up a full 32kbyte block. Sending those > datagrams to a 10mbit card takes too long for all of the datagrams to get > there, so the NFS client times out before getting all of the fragments. > [unquote] > > Their suggested fix is > [quote] > You need to pass some options to the client to tell it to use smaller > block sizes for NFS. > [unquote] > > I don''t know if this looks plausible to you, but am trying the following > NFS mount options in my Xen guest: > rsize=2048,wsize=2048 > > Regards > > M > > > > > -------- Original-Nachricht -------- > > Datum: Fri, 1 Feb 2008 08:23:36 -0500 > > Von: tmac <tmacmd@gmail.com> > > An: "Mark Furner" <mark.furner@gmx.net> > > CC: Xen-Users <xen-users@lists.xensource.com> > > Betreff: Re: [Xen-users] Xen guest nfs client not responding > > > it could be a few different things... > > > > 1. check the physical cables. use a good, comprehensive tester (not > those > > cheap testers) > > -> make sure there is no physical damage to the cable > > -> make sure the ends are crimped properly (sheath is under the rj45 > > pincher) > > 2. Verify the capability of your NFS server. Many NFS server based on > > general purpose OS''s > > cannot do more than an 8K rsize/wsize. You must adjust your client to > > match. > > -> if you have a netapp, the default could be 8K or 32K. run "options > nfs" > > to find out > > 3. Verify the connectivity at the switches. > > -> Make sure there are no duplex mismatches. (this should not happen at > > Gige, but happens all the time on 100BT) > > -> If using GigE, verify Flow Control and, if possible, set it to on in > > both > > directions. > > ---> some switches do not support flow control in both directions > > > > Hope this helps... > > > > --tmac > > > > On Jan 31, 2008 4:12 PM, Mark Furner <mark.furner@gmx.net> wrote: > > > > > Hello > > > > > > I''m trying to get my NFS Xen vm guest systems to their host via NFS > > > (within the same machine but keep getting performance-related errors): > > > > > > nfs: server [IP] not responding, still trying > > > nfs: server [IP] OK > > > [loops] > > > > > > Connectivity is flaky at best and applications running within the Xen > > > guests keep crashing or freezing as a result. > > > > > > There is a note at a LTSP site that says NFS has problems with the > > 2.6Kernel and discrepancies in NIC capacity between the host and client > if the > > > NFS block sizes are too large: > > > http://wiki.ltsp.org/twiki/bin/view/Ltsp/NFS#NFS_Server_not_responding > > > Does this apply to Xen too? > > > Their fix: pass on kernel options to the NFS client. How could I try > > this > > > with Xen? > > > > > > Thanks for any help! > > > > > > M > > > -- > > > Psssst! Schon vom neuen GMX MultiMessenger gehört? > > > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > > > > > > _______________________________________________ > > > Xen-users mailing list > > > Xen-users@lists.xensource.com > > > http://lists.xensource.com/xen-users > > > > > > > > > > > -- > > --tmac > > > > RedHat Certified Engineer #804006984323821 (RHEL4) > > RedHat Certified Engineer #805007643429572 (RHEL5) > > > > Principal Consultant, RABA Technologies > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? > Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger >-- --tmac RedHat Certified Engineer #804006984323821 (RHEL4) RedHat Certified Engineer #805007643429572 (RHEL5) Principal Consultant, RABA Technologies _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks for the tips tmac I''m trying a lower size for now to play safe: 2048. That appears to work OK. But I''ll try to ramp it up after a while. Regards M try 1024, 2048, 4096, 8192, 16384, 32768. You should (almost) always use the largest r/wsize that you can for optimal throughput. --tmac -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users