headers
Glen Johnson | 1 Sep 2009 14:35

xenU install fails on newfs.

Port-xen users,
I have Xen0 - NetBSD 5.0.1 running fine.  When I attempt to install a
XenU - NetBSD 5.0.1 I keep running into issues.  Just before the install
screen from sysinst is displayed a message xbd  IO domain 1: error 22
appears in the messages scrolling by.  Then the sysinst menu pops up and
everything appears to run fine until it comes time for newfs to do its
job and I get "wtfs: write error for sector 32: Rad-only file system".

Here is some background info on how I set things up.
The file system that XenU is supposed to use was generated by "dd
if=/dev/zero of=netbsd.img -bs=1024 count=2048 ; chmod 777 netbsd.img". 

My config file for my XenU is /usr/pkg/etc/xen/netbsd1:
kernel = "/usr/pkg/etc/xen/kernels/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 64
name = "netbsd1"
vif = [ 'mac=00:16:3e:00:00:11, bridge=bridge0' ]
disk = [ 'file:/home/glen/img/netbsd.img,3,w','phy:/dev/cd0a,0x4,r' ]
extra = ""
root = "xbd0"

My ifconfig -a shows:
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:0b:cd:be:10:7f
        media: Ethernet autoselect (100baseTX
full-duplex,flowcontrol,rxpause,txpause)
        status: active
        inet 192.168.45.154 netmask 0xffffff00 broadcast 192.168.45.255
        inet6 fe80::20b:cdff:febe:107f%fxp0 prefixlen 64 scopeid 0x1
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Hayward | 1 Sep 2009 15:18

Re: xenU install fails on newfs.

I'm no expert on Xen and NetBSD but I think the issue may be related
to the specification of root and index - Here is what you have:

====
> disk = [ 'file:/home/glen/img/netbsd.img,3,w','phy:/dev/cd0a,0x4,r' ]
> extra = ""
> root = "xbd0"
====

The following works for me:
====
disk = [ 'file:/Xen/fs/netbsd-4.0.1.fs,0x01,w', 'file:/Xen/ISO/i386cd-4.0.1.iso,0x2,r' ]
# Set root device. This one does matter for NetBSD
#root = "/dev/wd0a"
#below for run
root = "xbd0a"
#below for install
#root = "xbd1d"
====

Note: for install I have root pointing to the "d" partition of the CD 
image which has index 2 and after install I have root pointing to the "a" 
partition of the disk image which has index 1.

johnh...
>
>
>
> My ifconfig -a shows:
> fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
(Continue reading)

Permalink | Reply | 3 comments |
headers
Linus Nordberg | 1 Sep 2009 22:21
Picon
Gravatar

I/O performance in hvm domU

Hi,

I'm running FreeBSD (6.3) in a hvm domain on NetBSD (5.0.1) and suffer
from pretty bad I/O performance.  I realize that disk I/O should be
punished for going through qemu but would like to hear if my figures
make sense.

I've been running bonnie on both the domU and the dom0, using a file
system on the same disk device on the dom0 as the one on which the files
backing the domU disks resides.  The amount of data used for testing has
been chosen to be equal to the amount of RAM available to the domains,
2GB and 256MB for the domU and the dom0 respectively.

Write performance in domU is 11% and 9% of that for dom0 for char and
block writes, respectively.  For disk reads these figures are 36% and
44% and for random seek performance it's 23%.  The "rewrite" figure is
actually slightly better in domU than dom0 (103%).

Any thoughts on this?  Does it seem reasonable to you?  I can tell that
running ./configure && make throws me back in time about 15 years and in
space to a Slowaris box.  It's very depressing.

hvm configuration and typical output from running bonnie shown below.

Thanks,
Linus N

hvm config
----------
#  -*- mode: python; -*-
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Lerrahn | 2 Sep 2009 00:01

Re: I/O errors in Linux domUs

Mouse,
> > While ls would show me an image of 1GB, du only gives me about
> > 250MB. I'll have to make a copy that isn't sparse on a Linux system
> > somewhere, I suppose.
> 
> It's fairly easy to de-sparse a file with dd:
> 
> dd conv=notrunc if=the-file of=the-file bs=some-size
> 
> I usually use bs=1048576, but that's noncritical - you don't want it
> too small or you waste time crossing the user/kernel boundary; you
> don't want it too large or you need lots of buffer RAM.  (Of course,
> if you have way more RAM than the file's size, go ahead and crank it
> up. :)

Just after I had sent off the email, I realised that Manuel never
claimed that NetBSD had a problem with the sparse file but only the vnd
device. In other words, copying a file locally without ensuring that it
will be kept sparse does the trick already. My domUs now work like a
charm. :)

Thanks again for all the help from this mailing list. I would not have
made it this far without all the answers I got here. :)

Cheers,
Christian
Permalink | Reply | 0 comments |
headers
Christoph Egger | 2 Sep 2009 12:11
Picon
Picon

Re: current domu panic: xpq_flush_cache


I just got the same panic:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 5.99.15 (XEN3_DOMU) #1: Tue Aug 18 09:48:00 CEST 2009

cegger <at> tulln.osrc.amd.com:/data/netbsd/current-modified/build/obj.kern.amd64/XEN3_DOMU
total memory = 512 MB
avail memory = 486 MB
mainbus0 (root)
hypervisor0 at mainbus0: Xen version 3.3
vcpu0 at hypervisor0: AMD 686-class, 1895MHz, id 0x100f23
panic: xpq_flush_cache
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8012c42d cs e030 rflags 246 cr2  0 cpl 8 rsp 
ffffffff80879bb0
Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x5:  leave
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x285
xpq_flush_cache() at netbsd:xpq_flush_cache+0x58
cpu_init() at netbsd:cpu_init+0x32
cpu_attach_common() at netbsd:cpu_attach_common+0x13b
config_attach_loc() at netbsd:config_attach_loc+0x166
hypervisor_attach() at netbsd:hypervisor_attach+0x76
config_attach_loc() at netbsd:config_attach_loc+0x166
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christoph Egger | 2 Sep 2009 12:45
Picon
Picon

Re: current domu panic: xpq_flush_cache

On Wednesday 02 September 2009 12:11:10 Christoph Egger wrote:
> I just got the same panic:
>
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
>     2006, 2007, 2008, 2009
>     The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>     The Regents of the University of California.  All rights reserved.
>
> NetBSD 5.99.15 (XEN3_DOMU) #1: Tue Aug 18 09:48:00 CEST 2009
>
> cegger <at> tulln.osrc.amd.com:/data/netbsd/current-modified/build/obj.kern.amd6
>4/XEN3_DOMU total memory = 512 MB
> avail memory = 486 MB
> mainbus0 (root)
> hypervisor0 at mainbus0: Xen version 3.3
> vcpu0 at hypervisor0: AMD 686-class, 1895MHz, id 0x100f23
> panic: xpq_flush_cache
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 rip ffffffff8012c42d cs e030 rflags 246 cr2  0 cpl 8 rsp
> ffffffff80879bb0
> Stopped in pid 0.1 (system) at  netbsd:breakpoint+0x5:  leave
> breakpoint() at netbsd:breakpoint+0x5
> panic() at netbsd:panic+0x285
> xpq_flush_cache() at netbsd:xpq_flush_cache+0x58
> cpu_init() at netbsd:cpu_init+0x32
> cpu_attach_common() at netbsd:cpu_attach_common+0x13b
> config_attach_loc() at netbsd:config_attach_loc+0x166
> hypervisor_attach() at netbsd:hypervisor_attach+0x76
> config_attach_loc() at netbsd:config_attach_loc+0x166
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glen Johnson | 2 Sep 2009 15:35

Re: xenU install fails on newfs.

John Hayward wrote:
> I'm no expert on Xen and NetBSD but I think the issue may be related
> to the specification of root and index - Here is what you have:
>
> ====
>> disk = [ 'file:/home/glen/img/netbsd.img,3,w','phy:/dev/cd0a,0x4,r' ]
>> extra = ""
>> root = "xbd0"
> ====
>
> The following works for me:
> ====
> disk = [ 'file:/Xen/fs/netbsd-4.0.1.fs,0x01,w',
> 'file:/Xen/ISO/i386cd-4.0.1.iso,0x2,r' ]
> # Set root device. This one does matter for NetBSD
> #root = "/dev/wd0a"
> #below for run
> root = "xbd0a"
> #below for install
> #root = "xbd1d"
> ====
>
> Note: for install I have root pointing to the "d" partition of the CD
> image which has index 2 and after install I have root pointing to the
> "a" partition of the disk image which has index 1.
>
> johnh...
I copied over a NetBSD install image to my system and tried following
your example.  It did work just like you said.  Below is the disk line I
used.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sarton O'Brien | 3 Sep 2009 03:19

Re: current domu panic: xpq_flush_cache

On 2/09/2009 8:11 PM, Christoph Egger wrote:
> I just got the same panic:
>
>    
[ ... ]
> With a xen-debug kernel, Xen prints the reason for the xpq_flush_cache()
> failure:
>
> (XEN) mm.c:2474:d1 Non-physdev domain tried to FLUSH_CACHE.
>    

Ah, I should have thought of that. Is there much of a performance hit if 
you run the debug kernel? I'd consider making it my default.

Sarton
Permalink | Reply | 0 comments |
headers
Sarton O'Brien | 3 Sep 2009 03:27

Re: current domu panic: xpq_flush_cache

On 28/08/2009 11:03 PM, Chris Ruff wrote:
> Based on of the testing I've done it seems to be dome related.
>
> *I meant domU related*
>
> I was able to run dom0 5.99.15 and domU 5.0.1, but received the problem below when trying to run install_xen3_domU.
>
>    

Hehe all good. Yeah I didn't really think before I typed, I was running 
the latest dom0 with a July domU so the chances were high that it was 
the domU. Luckily Christoph has taken the time to have a look, I can't 
imagine the problem will stick around long now :)

Sarton
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 3 Sep 2009 18:13

Re: I/O performance in hvm domU

On Tue, Sep 01, 2009 at 10:21:36PM +0200, Linus Nordberg wrote:
> Hi,
> 
> I'm running FreeBSD (6.3) in a hvm domain on NetBSD (5.0.1) and suffer
> from pretty bad I/O performance.  I realize that disk I/O should be
> punished for going through qemu but would like to hear if my figures
> make sense.
> 
> I've been running bonnie on both the domU and the dom0, using a file
> system on the same disk device on the dom0 as the one on which the files
> backing the domU disks resides.  The amount of data used for testing has
> been chosen to be equal to the amount of RAM available to the domains,
> 2GB and 256MB for the domU and the dom0 respectively.
> 
> Write performance in domU is 11% and 9% of that for dom0 for char and
> block writes, respectively.  For disk reads these figures are 36% and
> 44% and for random seek performance it's 23%.  The "rewrite" figure is
> actually slightly better in domU than dom0 (103%).
> 
> Any thoughts on this?  Does it seem reasonable to you?

For a HVM guest with emulated I/O it looks reasonable to me. 
This matches more or less what I've seen with a linux HVM guest ...

--

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer <at> lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane