bug in starting xen machines - expectation of /dev/sda1 existing on *host*

bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Luke Kenneth Casson Leighton]

hi,

there's a bug in xen 2.0 which can be replicated by installing
udev on the xen master.

if you have udev - and no scsi devices present - on the xen
master, and you specify sda1234 etc as the disk partition
names in the /etc/xen/xen-guest-spec-files, then the xen
guest WILL NOT START.

... what has the existence or otherwise of /dev/sda1 on the
xen master machine got to do with the guest OSes?

to "fix" this problem, you must cp -aux /.dev/sd* /dev.

l.

[2004-12-29 22:11:16 xend] DEBUG (XendDomainInfo:720) init_domain> Created domain=1 name=xenselinuxnfs memory=32
[2004-12-29 22:11:16 xend] INFO (console:92) Created console id=12 domain=1 port=9601
[2004-12-29 22:11:17 xend] DEBUG (blkif:146) Connecting blkif <BlkifBackendInterface 1 0>
[2004-12-29 22:11:17 xend] INFO (XendRoot:91) EVENT> xend.console.create [12, 1, 9601]
[2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:1099) Creating vbd dom=1 uname=phy:/dev/hda17
[2004-12-29 22:11:17 xend] DEBUG (blkif:63) exception looking up device number for sda1: [Errno 2] No such file or directory: '/dev/sda1'
[2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:674) Destroying vbds for domain 1
[2004-12-29 22:11:17 xend] DEBUG (blkif:541) Destroying blkif domain=1
[2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:634) Closing console, domain 1
[2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:622) Closing channel to domain 1
[2004-12-29 22:11:17 xend] ERROR (SrvBase:162) op=create: vbd: Device not found: sda1
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/twisted/internet/defer.py", line 338, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "/lib/python/xen/xend/XendDomainInfo.py", line 975, in <lambda>
    d.addCallback(lambda x: self.create_devices())
  File "/lib/python/xen/xend/XendDomainInfo.py", line 802, in create_devices
    v = dev_handler(self, dev, dev_index)
  File "/lib/python/xen/xend/XendDomainInfo.py", line 1102, in vm_dev_vbd
    defer = ctrl.attachDevice(idx, val, recreate=recreate)
  File "/lib/python/xen/xend/server/blkif.py", line 530, in attachDevice
    dev = self.addDevice(idx, config)
  File "/lib/python/xen/xend/server/blkif.py", line 515, in addDevice
    dev = BlkDev(idx, self, config )
  File "/lib/python/xen/xend/server/blkif.py", line 318, in __init__
    self.configure(config)
  File "/lib/python/xen/xend/server/blkif.py", line 335, in configure
    raise VmError('vbd: Device not found: %s' % self.dev)
VmError: vbd: Device not found: sda1


-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Fajar A. Nugraha]

Luke Kenneth Casson Leighton wrote:

>hi,
>
>there's a bug in xen 2.0 which can be replicated by installing
>udev on the xen master.
>
>if you have udev - and no scsi devices present - on the xen
>master, and you specify sda1234 etc as the disk partition
>names in the /etc/xen/xen-guest-spec-files, then the xen
>guest WILL NOT START.
>
>  
>
Really? My Sun B100x don't have any scsi device, I use udev (with Gentoo)
as Domain-0 on on linux-2.6.9-xen-0 (custom config), and
my guest Fedora 1s and 2s run fine.

Regards,

Fajar


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[M.A. Williamson]

> Really? My Sun B100x don't have any scsi device, I use udev (with Gentoo)
> as Domain-0 on on linux-2.6.9-xen-0 (custom config), and
> my guest Fedora 1s and 2s run fine.

The bug will only occur if the device node you specified as the guest 
device *does not also* exist in dom0 so that the lookup can occur. If you 
specify target devices that also happen to exist in dom0 then it'll work 
even without directly specifying the node number.

It's just an unfortunate consequence of Xend's lookup algorithm on udev / 
devfs dom0...

Cheers,
Mark

> 
> Regards,
> 
> Fajar
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Milan Holzäpfel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 30 Dec 2004 10:49:30 +0000
Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:

> [...]
> 
> ... what has the existence or otherwise of /dev/sda1 on the
> xen master machine got to do with the guest OSes?

Xend does a stat on /dev/<dev-to-be-used-in-xenU-domain> to find the
device numbers (which the virtual block device driver is then providing
inside the xenU-domain.)  

But since you usually are likely to have either an IDE or an SCSI hard
disk, you should be able to use hda1 instead.  I'd guess that the only
difference between sda1 and hda1 with respect to the virtual block
device driver should be the device number, isn't it?

On the other hand, this finding out aboud device name <-> number mapping
is probably not very elegant, but simple.  Anyone familiar with Python
may fix it in the file site-packages/xen/xend/server/blkif.py; probably
modifying the function "blkdev_name_to_number" at the top.

> [...]
>   File "/lib/python/xen/xend/server/blkif.py", line 335, in configure
>     raise VmError('vbd: Device not found: %s' % self.dev)
> VmError: vbd: Device not found: sda1

(on your setup, /lib/python/xen/xend/server/blkif.py is the exact path
to that file; usually the xen directory is
/usr/lib/python2.3/site-packages.)

Regards,
Milan

PS: Sorry for sending it to only to you, Luke, I forgot to change the
recipient...

- -- 

                   Milan Holzäpfel alias jagdfalke alias jag

Antworten direkt an mich                             Answers directly to me
gehen bitte an eine Addresse,                        go to an address one
die man hier finden kann:                            can find here, please:

Kontaktinfos sowie                                   Contact infos as well as
Öff GnuPG-Schlüssel    <URL:http://con.mjh.name/>    GnuPG Public Key
GnuPG Fingerabdruck     4C8A 5FAF 5D32 6125 89D1     GnuPG Fingerprint
                        0CE5 DB0C AF4F 6583 7966



                    http://www.deppenleerzeichen.de/ 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB0+wj2wyvT2WDeWYRAnoCAJ46J91+0WU+0KAZJ6LOAPFVopwpPQCgibrn
fg18qXwETMEZJmJTStVh4HQ=
=MNpf
-----END PGP SIGNATURE-----


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[M.A. Williamson]

This is a known limitation... :-(

> ... what has the existence or otherwise of /dev/sda1 on the
> xen master machine got to do with the guest OSes?

In order to create the guest, Xend needs to look up the major / minor for 
the device name in the guest you specified. It has to do this on dom0's 
filesystem, so if there isn't a /dev/sda1 there it'll fail.

The current workaround is to specify the device number explicitly (e.g. 
phy:0801 should work for /dev/sda1).

The long-term fix would be to include a table for Xend to generate device 
numbers from, thus eliminating the dependency on these nodes existing in 
dom0.

HTH,
Mark

> to "fix" this problem, you must cp -aux /.dev/sd* /dev.
> 
> l.
> 
> [2004-12-29 22:11:16 xend] DEBUG (XendDomainInfo:720) init_domain> 
> Created domain=1 name=xenselinuxnfs memory=32 [2004-12-29 22:11:16 xend] 
> INFO (console:92) Created console id=12 domain=1 port=9601 [2004-12-29 
> 22:11:17 xend] DEBUG (blkif:146) Connecting blkif <BlkifBackendInterface 
> 1 0> [2004-12-29 22:11:17 xend] INFO (XendRoot:91) EVENT> 
> xend.console.create [12, 1, 9601] [2004-12-29 22:11:17 xend] DEBUG 
> (XendDomainInfo:1099) Creating vbd dom=1 uname=phy:/dev/hda17 [2004-12-29 
> 22:11:17 xend] DEBUG (blkif:63) exception looking up device number for 
> sda1: [Errno 2] No such file or directory: '/dev/sda1' [2004-12-29 
> 22:11:17 xend] DEBUG (XendDomainInfo:674) Destroying vbds for domain 1 
> [2004-12-29 22:11:17 xend] DEBUG (blkif:541) Destroying blkif domain=1 
> [2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:634) Closing console, 
> domain 1 [2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:622) Closing 
> channel to domain 1 [2004-12-29 22:11:17 xend] ERROR (SrvBase:162) 
> op=create: vbd: Device not found: sda1 Traceback (most recent call last):
>   File "/usr/lib/python2.3/site-packages/twisted/internet/defer.py", 
> line 338, in _runCallbacks
>     self.result = callback(self.result, *args, **kw)
>   File "/lib/python/xen/xend/XendDomainInfo.py", line 975, in <lambda>
>     d.addCallback(lambda x: self.create_devices())
>   File "/lib/python/xen/xend/XendDomainInfo.py", line 802, in 
> create_devices
>     v = dev_handler(self, dev, dev_index)
>   File "/lib/python/xen/xend/XendDomainInfo.py", line 1102, in vm_dev_vbd
>     defer = ctrl.attachDevice(idx, val, recreate=recreate)
>   File "/lib/python/xen/xend/server/blkif.py", line 530, in attachDevice
>     dev = self.addDevice(idx, config)
>   File "/lib/python/xen/xend/server/blkif.py", line 515, in addDevice
>     dev = BlkDev(idx, self, config )
>   File "/lib/python/xen/xend/server/blkif.py", line 318, in __init__
>     self.configure(config)
>   File "/lib/python/xen/xend/server/blkif.py", line 335, in configure
>     raise VmError('vbd: Device not found: %s' % self.dev)
> VmError: vbd: Device not found: sda1
> 
> 
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Luke Kenneth Casson Leighton]

how about running MAKEDEV sda in a known directory, to
create the sda* nodes in /var/tmp for example?

only thing to watch out for is that /sbin/MAKEDEV has been modified to
go "if udev installed, cd /.dev".

which is a bit stupid if you ask me.

so if you do if -x /.dev mkdir /.dev; cd /.dev; /sbin/MAKEDEV sda
then check the major/minor nums on /.dev/sda* then you have no need to
rely on /dev/sda* existing or not existing.

l.

On Thu, Dec 30, 2004 at 02:25:03PM +0000, M.A. Williamson wrote:
> This is a known limitation... :-(
> 
> >... what has the existence or otherwise of /dev/sda1 on the
> >xen master machine got to do with the guest OSes?
> 
> In order to create the guest, Xend needs to look up the major / minor for 
> the device name in the guest you specified. It has to do this on dom0's 
> filesystem, so if there isn't a /dev/sda1 there it'll fail.
> 
> The current workaround is to specify the device number explicitly (e.g. 
> phy:0801 should work for /dev/sda1).
> 
> The long-term fix would be to include a table for Xend to generate device 
> numbers from, thus eliminating the dependency on these nodes existing in 
> dom0.
> 
> HTH,
> Mark
> 
> >to "fix" this problem, you must cp -aux /.dev/sd* /dev.
> >
> >l.
> >
> >[2004-12-29 22:11:16 xend] DEBUG (XendDomainInfo:720) init_domain> 
> >Created domain=1 name=xenselinuxnfs memory=32 [2004-12-29 22:11:16 xend] 
> >INFO (console:92) Created console id=12 domain=1 port=9601 [2004-12-29 
> >22:11:17 xend] DEBUG (blkif:146) Connecting blkif <BlkifBackendInterface 
> >1 0> [2004-12-29 22:11:17 xend] INFO (XendRoot:91) EVENT> 
> >xend.console.create [12, 1, 9601] [2004-12-29 22:11:17 xend] DEBUG 
> >(XendDomainInfo:1099) Creating vbd dom=1 uname=phy:/dev/hda17 [2004-12-29 
> >22:11:17 xend] DEBUG (blkif:63) exception looking up device number for 
> >sda1: [Errno 2] No such file or directory: '/dev/sda1' [2004-12-29 
> >22:11:17 xend] DEBUG (XendDomainInfo:674) Destroying vbds for domain 1 
> >[2004-12-29 22:11:17 xend] DEBUG (blkif:541) Destroying blkif domain=1 
> >[2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:634) Closing console, 
> >domain 1 [2004-12-29 22:11:17 xend] DEBUG (XendDomainInfo:622) Closing 
> >channel to domain 1 [2004-12-29 22:11:17 xend] ERROR (SrvBase:162) 
> >op=create: vbd: Device not found: sda1 Traceback (most recent call last):
> >  File "/usr/lib/python2.3/site-packages/twisted/internet/defer.py", 
> >line 338, in _runCallbacks
> >    self.result = callback(self.result, *args, **kw)
> >  File "/lib/python/xen/xend/XendDomainInfo.py", line 975, in <lambda>
> >    d.addCallback(lambda x: self.create_devices())
> >  File "/lib/python/xen/xend/XendDomainInfo.py", line 802, in 
> >create_devices
> >    v = dev_handler(self, dev, dev_index)
> >  File "/lib/python/xen/xend/XendDomainInfo.py", line 1102, in vm_dev_vbd
> >    defer = ctrl.attachDevice(idx, val, recreate=recreate)
> >  File "/lib/python/xen/xend/server/blkif.py", line 530, in attachDevice
> >    dev = self.addDevice(idx, config)
> >  File "/lib/python/xen/xend/server/blkif.py", line 515, in addDevice
> >    dev = BlkDev(idx, self, config )
> >  File "/lib/python/xen/xend/server/blkif.py", line 318, in __init__
> >    self.configure(config)
> >  File "/lib/python/xen/xend/server/blkif.py", line 335, in configure
> >    raise VmError('vbd: Device not found: %s' % self.dev)
> >VmError: vbd: Device not found: sda1
> >
> >
> >

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Michael Day]

On Thu, 2004-12-30 at 22:43 +0000, Luke Kenneth Casson Leighton wrote:
> how about running MAKEDEV sda in a known directory, to
> create the sda* nodes in /var/tmp for example?
> 
Much better to put the device nodes you need into /etc/udev/devices.
Every time udev starts it runs MAKEDEV on that directory and creates
those devices for you automatically. 

Also, another helpful resource on this topic is 
http://www.lanana.org/docs/device-list/devices.txt

which has the current standard device numbers for linux. 

Mike
-- 
//------------------------------------------------------------//

Mike Day
md@soft-hackle.net
pgp signature key at: http://www.ncultra.org/md_sigkey.html

//------------------------------------------------------------//






-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: bug in starting xen machines - expectation of /dev/sda1 existing on *host*

[Nuutti Kotivuori]

M. A. Williamson wrote:
> The long-term fix would be to include a table for Xend to generate
> device numbers from, thus eliminating the dependency on these nodes
> existing in dom0.

This would certainly be a good idea, since blockdev frontend driver in
XenLinux already contains this mapping table in the other direction
(major and minor to device name). These two mappings should then be
kept in sync and there would be no more troubles from domain0 not
having the device files, or having the files with different minor and
major.

-- Naked




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt