headers
Michael van Elst | 1 Oct 2011 10:44
Picon

Re: default route on other subnet

pbraun <at> nethence.com (Pierre-Philipp Braun) writes:

>As an example, in a bridge configuration, say I've got 10.1.1.1/24 on 
>the dom0 and I want 10.2.2.2/24 on the guest.  And the gateway is 
>10.1.1.254.

If you have different subnets you need a router, not a bridge, and
a "default route on other subnet" is an oxymoron.

dom0 is 10.1.1.1/24 on the real interface and 10.1.1.254 is the gateway.

domU is 10.2.2.2/24 and needs a gateway in 10.2.2.0/24, e.g. 10.2.2.254.

dom0 needs a second interface to be configured for 10.2.2.254. This can
be a bridge that is used by multiple domUs, all in 10.2.2.0/24.

dom0 needs to be configured for ip forwarding.

your gateway 10.1.1.254 needs a proper route to 10.2.2.0/24 pointing
to the dom0. Other machines in 10.1.1.0/24 either need the same or
routing redirects have to work (they usually do).

-- 
--

-- 
                                Michael van Elst
Internet: mlelstv <at> serpens.de
                                "A potential Snark may lurk in every tree."
Permalink | Reply | 0 comments |
headers
Stefano Marinelli | 3 Oct 2011 00:33
Picon

Slow I/O on NetBSD domU (on Debian dom0)

Hi,
I have two Xen servers, the first one running Lenny (so Xen 3.2.1) and the second one running Squeeze (Xen 4.0.1).
Both of them are running one or more Debian domUs without any particular issue. 
NetBSD PV domUs, instead (tried with a freshly compiled netbsd-5), seem to suffer from some I/O
performance issues. Every time I start an intensive I/O task (like "tar xjvf pkgsrc.tar.bz2"), the
NetBSD domU starts to lag. ssh connections take ages to be accepted, and generally every task and every
command seem to be very very slow. This doesn't happen on Linux and the other domUs just run without any
particular problem, they can also do intensive  I/O tasks without any problem.
Any suggestion?
I've also a NetBSD 5.1 Dom0 (Xen 3.3) with some NetBSD PV domUs and some Debian Linux PV domUs. I cannot test it
now, but I never noticed something like that.

Thank you,
Stefano
Permalink | Reply | 3 comments |
headers
Greg Troxel | 3 Oct 2011 17:40
Picon

Re: Slow I/O on NetBSD domU (on Debian dom0)


  NetBSD PV domUs, instead (tried with a freshly compiled netbsd-5),
  seem to suffer from some I/O performance issues. Every time I start an
  intensive I/O task (like "tar xjvf pkgsrc.tar.bz2"), the NetBSD domU
  starts to lag. ssh connections take ages to be accepted, and generally

How are your "xbd" instances backed on the dom0?

I use NetBSD as the dom0, with files as virtual disks, via vnconfig
using the normal scripts.  I find about a <10% penalty on dd from the
file compared to dd from the raw dom0 disk, and then another <10%
penalty from the file on dom0 to the rxbd on domU.  So things seem good.

Things to check:

  can you dd from the backing store for the xbd at a reasonable speed?

  can you dd from the dom0 rxbd at a reasonable speed?

  what does 'systat vmstat' on the domU show during the heavy IO?

  what does the Linux equivalent show on the dom0?

I read a paper or web page long ago that claimed NetBSD as dom0 was
particularly efficient, but I can't find a reference to it quickly.
Permalink | Reply | 2 comments |
headers
Stefano Marinelli | 3 Oct 2011 17:56
Picon

Re: Slow I/O on NetBSD domU (on Debian dom0)

Hi Greg,

>  intensive I/O task (like "tar xjvf pkgsrc.tar.bz2"), the NetBSD domU
>  starts to lag. ssh connections take ages to be accepted, and generally
> 
> How are your "xbd" instances backed on the dom0?

The dom0 is a Debian Squeeze amd64 system, two SATA 1.5TB disks, a big raid with LVM over it, and the NetBSD xbd
are LVM volumes.

> I use NetBSD as the dom0, with files as virtual disks, via vnconfig
> using the normal scripts.  I find about a <10% penalty on dd from the
> file compared to dd from the raw dom0 disk, and then another <10%
> penalty from the file on dom0 to the rxbd on domU.  So things seem good.

This is the same thing I've noticed when using NetBSD as dom0. It seems generally more efficient than Linux,
but here I had no choice :(

> Things to check:
> 
>  can you dd from the backing store for the xbd at a reasonable speed?
> 
>  can you dd from the dom0 rxbd at a reasonable speed?
> 
>  what does 'systat vmstat' on the domU show during the heavy IO?
> 
>  what does the Linux equivalent show on the dom0?

I will try all this as soon as the machine will be under lower load and will report results back
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hugo Silva | 3 Oct 2011 23:50
Favicon

Re: Slow I/O on NetBSD domU (on Debian dom0)

On 10/03/11 16:56, Stefano Marinelli wrote:
> Hi Greg,
> 
>>  intensive I/O task (like "tar xjvf pkgsrc.tar.bz2"), the NetBSD domU
>>  starts to lag. ssh connections take ages to be accepted, and generally
>>
>> How are your "xbd" instances backed on the dom0?
> 
> The dom0 is a Debian Squeeze amd64 system, two SATA 1.5TB disks, a big raid with LVM over it, and the NetBSD
xbd are LVM volumes.
> 
>> I use NetBSD as the dom0, with files as virtual disks, via vnconfig
>> using the normal scripts.  I find about a <10% penalty on dd from the
>> file compared to dd from the raw dom0 disk, and then another <10%
>> penalty from the file on dom0 to the rxbd on domU.  So things seem good.
> 
> This is the same thing I've noticed when using NetBSD as dom0. It seems generally more efficient than
Linux, but here I had no choice :(
> 
>> Things to check:
>>
>>  can you dd from the backing store for the xbd at a reasonable speed?
>>
>>  can you dd from the dom0 rxbd at a reasonable speed?
>>
>>  what does 'systat vmstat' on the domU show during the heavy IO?
>>
>>  what does the Linux equivalent show on the dom0?
> 
> I will try all this as soon as the machine will be under lower load and will report results back
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Howland | 11 Oct 2011 01:45
Picon

unknown type vfb

Hi guys,

xen PV dmesg:
----8<----
unknown type vkbd at xenbus0 id 0 not configured
unknown type vfb at xenbus0 id 0 not configured
----8<----

Is this expected?

thanks,
-d
Permalink | Reply | 1 comment |
headers
Jean-Yves Migeon | 11 Oct 2011 10:38
Picon
Favicon

Re: unknown type vfb

 On Mon, 10 Oct 2011 19:45:37 -0400, David Howland wrote:
> Hi guys,
>
> xen PV dmesg:
> ----8<----
> unknown type vkbd at xenbus0 id 0 not configured
> unknown type vfb at xenbus0 id 0 not configured
> ----8<----
>
> Is this expected?

 Yes; one is a virtual keyboard used for PV on HVM hosts, the other one 
 is a virtual framebuffer for graphical output. None of these have a 
 driver frontend in NetBSD; xenbus(4) reports that it found them in 
 XenStore but cannot configure them.

 Should be harmless.

--

-- 
 Jean-Yves Migeon
 jeanyves.migeon <at> free.fr
Permalink | Reply | 0 comments |
headers
David Howland | 13 Oct 2011 00:49

amd64 MP (was Re: pae MP on cherry-xenmp)

On 9/9/11 4:57 AM, Cherry G. Mathew wrote:
 > Just to say I've checked in amd64 support. Do give it a spin, and let
 > us know (on list) how it goes.
 >
 > I haven't tested this on dom0.

You, Sir, are my hero.

I'm checking in with my results so far...

I am running on an Intel Xeon platform, Debian squeeze dom0 (Xen 4.0) 
with 2 vcpu's and 2GB allocated to NetBSD domU.  My domU is running 5.1 
userland with cherry-xenmp kernel, compiled like this (code was checked 
out October 12th):

cvs checkout -r cherry-xenmp src
./build.sh -m amd64 tools
./build.sh -m amd64 kernel=XEN3_DOMU

Status: working fine, but I haven't loaded it much yet.  I am running 
GNOME in Xvnc and I'm able to poke around and browse the web just fine. 
  I'll try to build /src with -j4.

-d
Permalink | Reply | 5 comments |
headers
David Howland | 13 Oct 2011 01:46

Re: amd64 MP (was Re: pae MP on cherry-xenmp)

On 10/12/2011 6:49 PM, David Howland wrote:
...
> I am running on an Intel Xeon platform, Debian squeeze dom0 (Xen 4.0)
> with 2 vcpu's and 2GB allocated to NetBSD domU. My domU is running 5.1
> userland with cherry-xenmp kernel, compiled like this (code was checked
> out October 12th):

Okay, one thing I've noticed, my NetBSD domU never seems to 'idle' from 
the hypervisor's perspective.  Check out the domain list:

root <at> rackable:/etc/xen# xm vcpu-list
Name              ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0           0     0     0   -b-     814.0 0
Domain-0           0     1     1   -b-     632.4 1
Domain-0           0     2     2   r--     582.5 2
Domain-0           0     3     3   -b-     609.1 3
centos-57          5     0     7   -b-      10.2 1-3,5-7
centos-57          5     1     6   -b-       6.7 1-3,5-7
netbsd-51          3     0     6   r--   19635.9 1-3,5-7
netbsd-51          3     1     5   r--   19634.3 1-3,5-7
solaris-11         4     0     7   -b-      40.0 1-3,5-7
solaris-11         4     1     2   -b-      36.8 1-3,5-7
windows-2008r2     1     0     4   -b-     321.9 4
windows-2008r2     1     1     5   -b-     105.4 5
windows-2008r2     1     2     6   -b-     107.7 6
windows-2008r2     1     3     7   -b-     135.5 7

The 'time' column for the NetBSD domain counts up every second even 
though 'top' in netbsd-51 shows both CPU's as 100% idle.  Basically, 
what you are seeing is a timer of how long the domain has been running
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jean-Yves Migeon | 13 Oct 2011 02:13
Picon
Favicon

Re: amd64 MP (was Re: pae MP on cherry-xenmp)

On 13.10.2011 01:46, David Howland wrote:
> The 'time' column for the NetBSD domain counts up every second even
> though 'top' in netbsd-51 shows both CPU's as 100% idle. Basically, what
> you are seeing is a timer of how long the domain has been running since
> I created it.
>
> I don't know what this means, but I report it because it seems to be
> different from all the other OS in the list.

Without looking at the code, I would say that the idle() loop for a CPU 
does not yield to hypervisor correctly. Or that something keeps kicking 
vCPUs out of it.

--

-- 
Jean-Yves Migeon
jeanyves.migeon <at> free.fr
Permalink | Reply | 1 comment |

Gmane