From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Wray Subject: Re: exception looking up device number f,or hda Date: Mon, 08 Aug 2005 09:08:51 +0100 Message-ID: <42F71313.4010201@hp.com> References: <42F3BF2C.70403@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <42F3BF2C.70403@intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Arun Sharma Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Arun Sharma wrote: > Hi Mike, > > I have the following line in my config file: > > disk = [ 'file:/var/images/min-el3-i386.img,hda,w' ] > > and my host doesn't have a /dev/hda (it has a SATA disk which shows up > as /dev/sda). > > But I would like the guest to see a /dev/hda. Sounds reasonable? > > Now, when I try to create this domain, I get: > > [2005-08-05 14:40:53 xend] DEBUG (blkif:24) exception looking up device > number for hda: [Errno 2] No such file or directory: '/dev/hda' > 2005-08-05 14:40:53 xend] DEBUG (blkif:449) Destroying blkif domain=1 > [2005-08-05 14:40:53 xend] DEBUG (blkif:337) Destroying vbd domain=1 id=0 > > The code in util/blkif.py that tries to convert name to device number > doesn't seem to be new, but I don't know why it started showing up > suddenly. > > I worked around by manually creating /dev/hda, but I don't think it's > reasonable to expect that host's /dev contains entries for all guest > devices. No, and the blkdev_name_to_number() function should convert names like /dev/hda without the device existing. This code should be trapping the error: try: return os.stat(n).st_rdev except Exception, ex: log.debug("exception looking up device number for %s: %s", name, ex) pass The code then uses regexps to analyse the device name (though you will see the debug message in the log). What xen version are you using? > > Also, the effect of having a bad "disk=" line in xmdefconfig (such as > pointing to a non-existent file) results in a xend crash. We probably > need to add a few checks at the python level so that the user sees a > more useful stack trace. All errors during domain construction are intended to be trapped and returned to the caller - so maybe something got broken. Did you see anything in the xend log? Might be worth causing the error using xend with tracing on (xend trace_start) and having a look at the trace (/var/log/xend.trace). Mike