> -----Original Message-----
> From: Сергей Лукашевич [mailto:lukash33@xxxxxxxxx]
> Sent: 25 June 2007 16:30
> To: Petersson, Mats
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] xen 3.1 - domU hangs just after "xm create"
>
>
>
> 25.06.07, 18:34, Petersson, Mats <Mats.Petersson@xxxxxxx> <>:
>
> >
> > > -----Original Message-----
> > > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> > > ?????? ?????????
> > > Sent: 25 June 2007 15:26
> > > To: xen-users@xxxxxxxxxxxxxxxxxxx
> > > Subject: [Xen-users] xen 3.1 - domU hangs just after "xm create"
> > >
> > > What are methods to debug domU when it hangs? Using xen 3.1
> > > compiled from sources I could not manage to launch no domU.
> > > Fot instance, I run something like this:
> > >
> > >
> > >
> > > =====8<=====================
> > >
> > > disk = [ 'file:/oradata-act/sles.disk,hda1,w', ',hdc:cdrom,r' ]
> > >
> > > kernel = "/boot/vmlinuz-2.6.18-xen"
> > >
> > > ramdisk = "/boot/initrd-2.6.18-xen"
> > I take it this is the same initrd you use for Dom0? Does it
> have the drivers for DomU too?
>
> Yes, the same kernel and the same initrd. I beleive XEN
> allows using same here from some of 2.* versions, is not it?
Same kernel is no problem at all - that's normal operating procedure for most
people - although some will argue that the kernel is slightly larger this way
compared to when you have a DomU specific kerne.
Yes, it's just that sometimes the initrd contains "stuff" that is corresponding
to the management of Dom0 that conflicts with the usage on DomU - typical
example is LVM management, but there's other things that cause this too.
> Initrd contains reiserfs driver - that's quite enough to
> start booting. I suspect something wrong with my compiling
> and installing XEN because domUs output NO lines to their
> consoles to suspect its kernel.
I agree, there's probably something wrong in your system on a more fundamental
level.
>
> > You may want to mount the sles.disk and use "mkinitrd" to
> create a new ramdisk from inside the sles.disk instead - that
> has uses the fstab of the sles.disk, etc.
> > >
> > > cpus = "1"
> > >
> > > vcpus = 2
> > >
> > > memory = 256
> > >
> > > name = "sles"
> > >
> > > root="/dev/hda1 ro"
> > >
> > > =====8<=====================
> > >
> > >
> > >
> > > Of course, sles.disk is a reiserfs image containing unTARred
> > > SLES9.3 64bit OS.
> > I hope you don't use reiserfs on reiserfs here - as if you
> do and you ever need to "fsck" the underlaying disk, then
> you'll get problems - reiserfs uses a "magic word" to
> indicate where it starts it's filesystem, and finding another
> (same) magic word in the middle of the file-system is most
> certainly going to make things very confused when trying to
> figure out what's what.
>
> I DO use reiserfs onto reiserfs. Sounds very strange - magics
> can confuse fsck? Do you have some additional info on this
> behaviour? Some link or the like? It would be interesting to look at.
>
> > >
> > >
> > >
> > > The domain console outputs nothing but several spaces at the
> > > very start and the domU hangs in a few (15-25) seconds.
> > "Interesting". Not sure what that could be.
> > >
> > >
> > >
> > > What are log files to analyze? What are 'debug' options?
> > I'd start with "xm dmesg". If that's not saying anything
> useful, look at /var/log/xen/xend.log and .../xend-debug.log
>
> Only following files present there:
>
> domain-builder-ng.log
> qemu-dm.25423.log
> qemu-dm.3345.log
> xen-hotplug.log
Surely you should have a /var/log/xen/xend.log too.
By the way, what is "builder" in your config file? Qemu-dm indicates that
you're trying to start a HVM domain - in which case your "kernel" shouldn't be
a linux kernel, but rather "hvmbuilder".
>
> xm dmesg is very interesting, thank you. Seems that every
> attempt to launch a domU yelds the following:
>
> (XEN) mm.c:636:d0 Error getting mfn 100 (pfn
> 5555555555555555) from L1 entry 8000000000100125 for dom32753
This may be harmfull - not sure.
>
> Also I saw some other strange lines from "xm dmesg" like this:
>
> (XEN) microcode: CPU6 not a capable Intel processor
At first I though this was due to your processors being AMD models, but I
suspect that with 16 "virtual cores", you have the Xeon model of X4600 rather
than the AMD one.
I'd ignore it anyways, as you most likely have the relevant microcode loaded by
the BIOS.
>
> Not sure whether they appear when I experiment with HVM domUs...
>
>
> > These may also not contain anything useful - but it would
> be where I'd start trying to figure out what's wrong.
> > >
> > >
> > >
> > > I managed to run dom0 which is behaving not so bad.
> > >
> > > Only several 'segfault's in dmesg confuse me.
> > Where are those segfualts from?
>
> Well, I was trying to compile dev86 there and the ncc
> compiler sigfaulted. Also irqbalance sigfaulted:
>
> irqbalance[3258]: segfault at 0000000000528018 rip
> 00000000004016ba rsp 00007fff9cf9b8f0 error 4
They shouldn't fail like that.
>
> > >
> > >
> > >
> > > I use SUN X4600 server which is of 64bits, 32gigs and 16
> virtual CPUs.
> > I expect this to be capable of running Xen for sure.
> > --
> > Mats
>
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home