debian testing domU under netbsd xen 3 dom0

Hi,

Has anyone tried running debian domU under
netbsd xen 3 dom0 ? I have managed it to
boot (had problems with sparse disk files but
that was fixed by creating non-spare ones) but
network works only partially:

- dhclient is able to get IP from dhcp server
- ping works
- tcp connections hang
- name resolver does not work

I had similar domU running under debian dom0
a while ago and I don't recall problems like this
(but this doesn't mean that the problem couldn't be
on debian side, of course)


	Ari S.

On Thu, Jul 06, 2006 at 10:15:01AM +0300, Ari Suutari wrote:
> Hi,
> 
> Has anyone tried running debian domU under
> netbsd xen 3 dom0 ? I have managed it to
> boot (had problems with sparse disk files but
> that was fixed by creating non-spare ones) but
> network works only partially:
> 
> - dhclient is able to get IP from dhcp server
> - ping works
> - tcp connections hang
> - name resolver does not work

use rootdebian:/ #  ethtool -K eth0 tx off

You might have to install it first.


For a discussion of the problem, see:
http://wiki.
xensource.com/xenwiki/XenFaq

You probably used a debian-modified dom0/domU kernel on
debian,
and are now using a stock Xen domU kernel, right?

Florian

Florian Heigl wrote:
> 
> use rootdebian:/ #  ethtool -K eth0 tx off
> 
> You might have to install it first.
> 
> 
> For a discussion of the problem, see:
> http://wiki.
xensource.com/xenwiki/XenFaq

	Thank you ! Network works perfectly now.
	I should have read the FAQ first instead of
	assuming that this is netbsd -related.
> 
> You probably used a debian-modified dom0/domU kernel on
debian,
> and are now using a stock Xen domU kernel, right?

	All debian stuff was/is installed via apt-get, and
	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)

		Ari S.

On Thu, Jul 06, 2006 at 10:15:01AM +0300, Ari Suutari wrote:
> Hi,
> 
> Has anyone tried running debian domU under
> netbsd xen 3 dom0 ? I have managed it to
> boot (had problems with sparse disk files but
> that was fixed by creating non-spare ones) but
> network works only partially:
> 
> - dhclient is able to get IP from dhcp server
> - ping works
> - tcp connections hang
> - name resolver does not work

use rootdebian:/ #  ethtool -K eth0 tx off

You might have to install it first.


For a discussion of the problem, see:
http://wiki.
xensource.com/xenwiki/XenFaq

You probably used a debian-modified dom0/domU kernel on
debian,
and are now using a stock Xen domU kernel, right?

Florian

Florian Heigl wrote:
> 
> use rootdebian:/ #  ethtool -K eth0 tx off
> 
> You might have to install it first.
> 
> 
> For a discussion of the problem, see:
> http://wiki.
xensource.com/xenwiki/XenFaq

	Thank you ! Network works perfectly now.
	I should have read the FAQ first instead of
	assuming that this is netbsd -related.
> 
> You probably used a debian-modified dom0/domU kernel on
debian,
> and are now using a stock Xen domU kernel, right?

	All debian stuff was/is installed via apt-get, and
	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)

		Ari S.

Hi Ari,

On Thu, Jul 06, 2006 at 03:58:22PM +0300, Ari Suutari wrote:
> 
> 	Thank you ! Network works perfectly now.
> 	I should have read the FAQ first instead of
> 	assuming that this is netbsd -related.

Noone can expect this error, it took me two weeks to find
out the issue,
not by debugging, but by at last giving up and searching for
"xen bridge
packet loss network issue" (and a few swear words to
boil down the results)

> 	All debian stuff was/is installed via apt-get, and
> 	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)

hmmm, then there is still some space to look at in relation
to what
our bridge interface does when a linux kernel turns on tcp
offloading.

I have no idea of the real internals of xen 

flo

-- 

florian heigl			 http://deranfangvomen.de/

Grid Computing erfreut sich gerade bei Windows-Nutzern sehr
regem Zuspruch, auch
wenn die Rechnerbesitzer meist nichts von ihrem Glück
wissen. --f. weimer

Hi Ari,

On Thu, Jul 06, 2006 at 03:58:22PM +0300, Ari Suutari wrote:
> 
> 	Thank you ! Network works perfectly now.
> 	I should have read the FAQ first instead of
> 	assuming that this is netbsd -related.

Noone can expect this error, it took me two weeks to find
out the issue,
not by debugging, but by at last giving up and searching for
"xen bridge
packet loss network issue" (and a few swear words to
boil down the results)

> 	All debian stuff was/is installed via apt-get, and
> 	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)

hmmm, then there is still some space to look at in relation
to what
our bridge interface does when a linux kernel turns on tcp
offloading.

I have no idea of the real internals of xen 

flo

-- 

florian heigl			 http://deranfangvomen.de/

Grid Computing erfreut sich gerade bei Windows-Nutzern sehr
regem Zuspruch, auch
wenn die Rechnerbesitzer meist nichts von ihrem Glück
wissen. --f. weimer

On Thu, Jul 06, 2006 at 04:14:31PM +0200, Florian Heigl
wrote:
> Hi Ari,
> 
> On Thu, Jul 06, 2006 at 03:58:22PM +0300, Ari Suutari
wrote:
> > 
> > 	Thank you ! Network works perfectly now.
> > 	I should have read the FAQ first instead of
> > 	assuming that this is netbsd -related.
> 
> Noone can expect this error, it took me two weeks to
find out the issue,
> not by debugging, but by at last giving up and
searching for "xen bridge
> packet loss network issue" (and a few swear words
to boil down the results)

Hrm, I caught it after a tcpdump showed me the bad checksums
and googled for that.

The lesson learned "Even if your network doesn't
physically exist, tcpdump
can be useful."
> 
> > 	All debian stuff was/is installed via apt-get,
and
> > 	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)
> 
> hmmm, then there is still some space to look at in
relation to what
> our bridge interface does when a linux kernel turns on
tcp offloading.

Linux does a few things on packet optimization that I would
describe as
pathological.  DaveM would probably say it's efficient.

Since folks will get burned with a netbsd domU on a linux
dom0.
You still need to disable tx checksum offloading on
dummynets.
If you attempt this prior to xen starting up the bridge, it
will
fail to create the bridge (And also keep you from removing
the bridge).
I currently have a kludge to do the setting after bringing
up the dummynet 
bridge (dual bridge configuration), but it seems to have a
race condition,
and doesn't work after every reboot.

For the bridge that goes to a real ethernet adaptor, I leave
the tcp
transmit checksumming off, but remind myself that I won't
be able to
effectively reach the dom0.
Someone that has poked more than me might be able to tell me
if I can
force tcp checksuming on the specific veths and vifs so that
the most
efficient combination is chosen.
> 
> I have no idea of the real internals of xen 

Or when it's an OS internal that is doing things to make
life
miserable for doms under Xen.
> 
> flo
> 
> -- 
> 
> florian heigl			 http://deranfangvomen.de/
> 
> Grid Computing erfreut sich gerade bei Windows-Nutzern
sehr regem Zuspruch, auch
> wenn die Rechnerbesitzer meist nichts von ihrem Glück
wissen. --f. weimer

-- 
Chris Dukes
"The key to effective management is properly timed
hovering."

On Thu, Jul 06, 2006 at 04:14:31PM +0200, Florian Heigl
wrote:
> Hi Ari,
> 
> On Thu, Jul 06, 2006 at 03:58:22PM +0300, Ari Suutari
wrote:
> > 
> > 	Thank you ! Network works perfectly now.
> > 	I should have read the FAQ first instead of
> > 	assuming that this is netbsd -related.
> 
> Noone can expect this error, it took me two weeks to
find out the issue,
> not by debugging, but by at last giving up and
searching for "xen bridge
> packet loss network issue" (and a few swear words
to boil down the results)

Hrm, I caught it after a tcpdump showed me the bad checksums
and googled for that.

The lesson learned "Even if your network doesn't
physically exist, tcpdump
can be useful."
> 
> > 	All debian stuff was/is installed via apt-get,
and
> > 	on netbsd dom0 xen is from pkgsrc (I assume it is
unmodifed)
> 
> hmmm, then there is still some space to look at in
relation to what
> our bridge interface does when a linux kernel turns on
tcp offloading.

Linux does a few things on packet optimization that I would
describe as
pathological.  DaveM would probably say it's efficient.

Since folks will get burned with a netbsd domU on a linux
dom0.
You still need to disable tx checksum offloading on
dummynets.
If you attempt this prior to xen starting up the bridge, it
will
fail to create the bridge (And also keep you from removing
the bridge).
I currently have a kludge to do the setting after bringing
up the dummynet 
bridge (dual bridge configuration), but it seems to have a
race condition,
and doesn't work after every reboot.

For the bridge that goes to a real ethernet adaptor, I leave
the tcp
transmit checksumming off, but remind myself that I won't
be able to
effectively reach the dom0.
Someone that has poked more than me might be able to tell me
if I can
force tcp checksuming on the specific veths and vifs so that
the most
efficient combination is chosen.
> 
> I have no idea of the real internals of xen 

Or when it's an OS internal that is doing things to make
life
miserable for doms under Xen.
> 
> flo
> 
> -- 
> 
> florian heigl			 http://deranfangvomen.de/
> 
> Grid Computing erfreut sich gerade bei Windows-Nutzern
sehr regem Zuspruch, auch
> wenn die Rechnerbesitzer meist nichts von ihrem Glück
wissen. --f. weimer

-- 
Chris Dukes
"The key to effective management is properly timed
hovering."