WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Creating a paravirtualized guest with Xen 3.4.1 and Cent

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Creating a paravirtualized guest with Xen 3.4.1 and Centos 5.3 (64bit)
From: Martin Troester <TroyMcClure@xxxxxx>
Date: Tue, 22 Sep 2009 21:31:16 +0200
Delivery-date: Tue, 22 Sep 2009 12:35:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AB9072E.9090106@xxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <832875840@xxxxxx> <4AB9072E.9090106@xxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.23 (X11/20090817)
Hi Andrew,

thanks for your quick response here. But no, that solution would be too easy... Maybe I expressed myself not clear enough in the first note - the very same VM runs fine using pygrub, but fails using "kernel","initrd","root" and "extras" parameters in the cfg file...

So everything necessary should be in the image. I doublechecked, and can confirm xennet and xenblk are both in /lib/modules and (probably more important) initrd. But it must be something like this, I just don't understand why and where to look... Maybe someone can clarify what's going on differently between using pygrub (this boots the disk-internal kernel and initrd, at least that's what I'm thinking) and moving the internal kernel and initrd outside, and using the very same command lines? Is there anything special automatically appended to the kernel parameters specified in /boot/grub/grub.conf via pygrub?

Is there a way to force kernel output to tell me which modules are loaded in which order during boot? I don't find enough on the kernel messages output...

Thanks again,
Martin

Andrew Evans wrote:
I think your problem is the lack of xenblk/xennet drivers. Try `cp -pr /lib/modules` to your target VM. I think then you'll be able to boot.

-Andrew

Martin Tröster wrote:
Hi,

I have a set of 32bit HVM images running fine under Xen 3.2.1 and Xen 3.4.1. Due to performance issues with the fully virtualized setup, I would like to migrate one of those images to a paravirtualized image to compare the network performance. As I do not have a Xen-aware kernel for that VM, I thought the best would be to provide one from outside.

Sounds like an easy task, doesn't it? ;-)

However, I fail miserably on this task. It just does not work. To get rid of any side effects, I thought it would be nice to try with a known-working image.

Therefore I got the image Centos 5.3 image from http://stacklet.com/downloads/images/centos/5.3. And voila, using the pygrub version works like a charm - I can either log in using xm console, or ssh. This is the config used:

bootloader = "/usr/bin/pygrub"
memory = 256
name = "centos_pygrub"
vif = [ 'bridge=eth0,mac=02:00:00:00:01:86'  ]
disk = ['file:image,sda1,w']
root = "/dev/sda1"
extra = "fastboot"

Now, as this kernel appears to be working fine, I thought I'd like to just take this kernel and initrd out of the known-good vm, and give it to Xen as parameters. In my naive thinking, this should be the very same as pygrub is doing - loading the kernel specified in /boot/grub.conf with initrd and parameters (all taken from the VM running fine with pygrub):

kernel = "vmlinuz"
initrd = "initrd"
extra = "console=xvc0"
root = "/dev/sda1"
memory = 256
name = "centos_pv"
vif = [ 'bridge=eth0,mac=02:00:00:00:01:86'  ]
disk = ['file:image,sda1,w']

BUT - this fails! The last lines on the command line are:

XENBUS: Device with no driver: device/vbd/2048
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/console/0
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
VFS: Cannot open root device "sda1" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

The only obvious difference compared to the previous VM is the line stating "md: autodetecting RAID arrays.". But why should this very same kernel, that initializes fine when using pygrub, now start setting up raid configs? I don't seem to get it, so I really appreciate some help here, I already spent too long debugging this, I have no idea what goes wrong here. Does my host config have anything to do with it (yes, it has a raid)? But if yes, why would it? I did not build the initrd image myself, it's the one taken from the VM which booted fine using pygrub...

Thanks a lot!

Regards,
Martin

P.S.: The Xen log does not show any error at all, only reports the VM having crashed. P.P.S.: When I get this running (there's still hope left...), I would like to understand what's the best option to provide a disk - is it tap:aio, or file? Any documentation on reasons to choose either the one or the other?
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>