Hello,
I am using XEN 2.0.7, kernel 2.6.11.12, EVMS 2.5.2.
I am trying to use EVMS in my domU but it is not detecting a "virtual"
disk. I get the following error when issuing evms_activate -d debug:
---
Dec 01 17:20:34 samba _8_ LocalDskMgr: get_geometry: Error getting
geometry for disk sda: 38: Function not implemented.
---
So sda is "seen", but evms doesn''t like it because-- it would
appear--
it can''t get the drive''s geometry.
This is the domU configuration:
---
hostname = ''samba''
domainname = ''blah.com''
config_eth0 = ''dhcp''
# domU configuration
name = hostname + ''.'' + domainname
kernel = ''/boot/kernel.xen-dom0''
ramdisk = ''/boot/initrd''
memory = 128
cpu = -1
nics = 1
vif = [ ''mac=00:48:45:44:01:01, bridge=xen-br0'' ]
disk = [ ''phy:loop0,hda,r'', ''phy:sda4,sda,w''
]
root = ''/dev/ram0 ro init=/linuxrc cdroot hostname='' +
hostname + \
'' domainname='' + domainname + ''
config_eth0='' + config_eth0
---
Note that the sda device is what I''m unable to detect. (Note that the
''hostname'', ''domainname'',
''config_eth0'' root parameters are my own
customizations and unrelated to this discussion.)
I should note that:
1. I don''t have these problems in domU when detecting an iSCSI volume
in
EVMS; everything works perfectly under these conditions.
2. The O/S itself in dom-U has no problems; I can fdisk /dev/sda, make
partitions, make file systems, mount it, etc. It''s just EVMS
that''s
having trouble with the drive geometry.
3. In dom-0 I have no problems with EVMS; it detects sda4. The problem
only occurs when I try EVMS within the dom-U. I''ve tried exporting
sda4
into the dom-U as sda1 (instead of sda) as well, with the same results.
So the question is: Is there something unique about xen disks in domU
that might cause EVMS to fail reading the disk geometry? What else
might be the cause?
Thank you,
James
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Jim Henderson <his_jimboness@yahoo.ca> wrote on 12/01/2005 11:56:08 AM:> Hello, > > I am using XEN 2.0.7, kernel 2.6.11.12, EVMS 2.5.2. > > I am trying to use EVMS in my domU but it is not detecting a "virtual" > disk. I get the following error when issuing evms_activate -d debug: > --- > Dec 01 17:20:34 samba _8_ LocalDskMgr: get_geometry: Error getting > geometry for disk sda: 38: Function not implemented. > --- > So sda is "seen", but evms doesn''t like it because-- it would appear-- > it can''t get the drive''s geometry.<snip>> So the question is: Is there something unique about xen disks in domU > that might cause EVMS to fail reading the disk geometry? What else > might be the cause?Hi, James. The Local Disk Manager in EVMS has had some recent changes to its algorithm for getting the geometry of the disk. The changes have not yet made it into an official release. (2.5.4 should come out "very soon".) Here is a patch built from the current CVS tree. It should apply to 2.5.1, but the offsets may be wrong. (See attached file: localdskmgr.patch) If the patch applies and you still have problems, then we will have to look at the ioctls to get the disk geometry. It may be that EVMS needs another tweak to handle the ioctl. It may be that Xen needs to respond to the ioctl correctly. Steve D. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Steve, The patch applied perfectly to EVMS 2.5.3 (I decided to upgrade from 2.5.2 while I was at it) but unfortunately there''s still a problem. Now, instead of "Function not implemented." I''m getting "Invalid argument": --- Dec 01 22:59:28 samba _8_ LocalDskMgr: get_geometry: Error getting geometry for disk sda: 22: Invalid argument. --- In addition (not sure if this helps), I''ve found that hdparm has problems getting geometry in my domU too: --- samba ~ # hdparm /dev/sda /dev/sda: readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Function not implemented --- Any ideas? Thanks for your help so far. -James> Hi, James. > > The Local Disk Manager in EVMS has had some recent changes to its algorithm > for getting the geometry of the disk. The changes have not yet made it > into an official release. (2.5.4 should come out "very soon".) Here is a > patch built from the current CVS tree. It should apply to 2.5.1, but the > offsets may be wrong. > (See attached file: localdskmgr.patch) > > If the patch applies and you still have problems, then we will have to look > at the ioctls to get the disk geometry. It may be that EVMS needs another > tweak to handle the ioctl. It may be that Xen needs to respond to the > ioctl correctly. > > Steve D. > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Jim Henderson <his_jimboness@yahoo.ca> wrote on 12/01/2005 05:10:46 PM:> Steve, > > The patch applied perfectly to EVMS 2.5.3 (I decided to upgrade from > 2.5.2 while I was at it) but unfortunately there''s still a problem. > Now, instead of "Function not implemented." I''m getting "Invalidargument":> > --- > Dec 01 22:59:28 samba _8_ LocalDskMgr: get_geometry: Error getting > geometry for disk sda: 22: Invalid argument. > --- > > In addition (not sure if this helps), I''ve found that hdparm has > problems getting geometry in my domU too: > > --- > samba ~ # hdparm /dev/sda > > /dev/sda: > readonly = 0 (off) > readahead = 256 (on) > HDIO_GETGEO failed: Function not implemented > --- > > Any ideas? Thanks for your help so far.Hi, Jim. Since hdparam is also getting an error on the HDIO_GETGEO ioctl, my guess is that the Xen driver for the disk is not handling the ioctl. So, looking at the Xen source, I see that in blkif_ioctl() in linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c that the case for HDIO_GETGEO just does "return -ENOSYS;" with a comment that says "return ENOSYS to use defaults". Looks like the ENOSYS is making its way back to hdparam with no defaults set. EVMS gets a different error code because it first tries the HDIO_GETGEO ioctl, which fails with ENOSYS, then it tries the HDIO_GETGEO_BIG ioctl (an old, deprecated ioctl) which blkif_ioctl() doesn''t handle and returns its default -EINVAL. Taking a quick look at the fdisk code, it appears fdisk ignores errors from the HDIO_GETGEO ioctl and uses the defaults of 255 heads and 63 sectors per track. (It can get the settings of heads and sectors from several ways: user input, the partition table, or HDIO_GETGEO ioctl, in that order. If all three of those are not set, it uses the defaults.) It always calculates the number of cylinders from the disk size, the number of heads, and number of sectors per track. I see two ways to fix this. One is to have the Xen blkif_ioctl() return zeroes for the geometry and return a zero return code. Other Linux block drivers do that, and EVMS handles that situation. The other fix is to change EVMS to behave like fdisk and use defaults if the ioctls return error codes. Anyone on the list have thoughts on this issue? Steve D. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users