[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Hotplug scripts not working... xen/ia64 domU stopped working

  • To: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
  • From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
  • Date: Fri, 2 Dec 2005 09:41:39 -0800
  • Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 02 Dec 2005 17:41:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcX22owD117ieNy3RRKgd9aD8TliaQAhX+Vg
  • Thread-topic: [Xen-devel] Hotplug scripts not working... xen/ia64 domU stopped working

Problem identified but it's a weird one!  I turned on logging
in /etc/xen/scripts/block and /etc/hotplug/xen-backend.agent
using Adam's cool trick of redirecting stderr output (exec 2>>file),
and discovered I *was* getting a message that domain0 already
was using the loopback device.

So I again tried turning on w! in /etc/xen/xmdefconfig
and this time it worked!

However, when I turned off logging, the w! no longer makes
the problem go away, and there is a long pause before the
"Error: Device 769... Hotplug scripts not working" message.
(Logging need only be enabled in xen-backend.agent to
make the problem again go away.)

Some weird timing problem?

My /etc/xen/xmdefconfig is very short:
kernel = "/tmp/xenlinux"
memory = 256
disk = ['phy:loop0,hda1,w']  # <-change to w!

and after a fresh boot, I am simply doing:

# lomount -t ext2 -diskimage /var/xen/hda /mnt
# xend start
# xm create

I can see how it could be interpreted that loop0 is
being used both by domain0 and the newly created domain,
but isn't this a common use model?


P.S. When I change my /etc/xen/xmdefconfig to
disk = ['file:/var/xen/hda,hda1,w']
mounting the root disk fails with:
UDF-fs: No VRS found

> -----Original Message-----
> From: Ewan Mellor [mailto:ewan@xxxxxxxxxxxxx] 
> Sent: Thursday, December 01, 2005 5:51 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Xen Mailing List
> Subject: Re: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domU stopped working
> On Thu, Dec 01, 2005 at 04:39:03PM -0800, Magenheimer, Dan 
> (HP Labs Fort Collins) wrote:
> > 
> > > > By "put logging into" do you mean adding a '-x' at the end
> > > > of the first (bin/sh) line?  If so, where is the logging going?
> > > > (not to the console nor to /var/log/xend.log...)  Sorry...
> > > > it's been awhile since I've done script debugging and it's
> > > > definitely a lot different than hypervisor debugging :-}
> > > 
> > > Doing that writes to stderr, which unfortunately is going 
> > > straight down
> > > /dev/null, because this is being run by the kernel's hotplug 
> > > infrastruture.
> > > 
> > > You can either use echo "Message" >~/my-log to write to a log 
> > > file of your own,
> > > or log err "Message" to write to syslog (once you have included
> > > xen-hotplug-common.h).
> > 
> > Any suggestions as to where in the file would be illuminating?
> Just keep shuffling them forward until they stop working ;-)  
> I really have no
> idea -- I'd just binary chop until I found out where the problem was. 
> > And where is "syslog"? (not in /var/log... it's a RHEL3 system)
> /var/log/messages is normal for Redhat, I think.  This is 
> usually configurable
> with /etc/syslog.conf or /etc/syslog-ng.conf, but hardly 
> anyone changes from the
> default!
> > I can confirm now that cset 8048 works and 8049 does not.
> > Using 'w!' does not make any difference.  I don't see any
> > changes in the changeset that look particularly interesting
> > from an ia64 perspective.  Do you see anything new that might
> > reach into the hypervisor that didn't before?  Or perhaps
> > something new with evtchn (which has some differences on ia64)?
> Are you using really long file names for these 
> loopback-mounted disks?  Someone
> reported a failure with filenames greater than 64 chars 
> today.  There's
> nothing IA64-specific that I'm aware of.
> Ewan.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.