Yeah, I don't think I'd do symlinks, as you could potentially run in to issues; one could also just use mknod to make another block device pointer as Raphaël is suggesting. I'm sure there's a place somewhere to do that cleaner than mknod, too - maybe xen_blkfront even already understands changing the naming? I don't see such in the older xen_blkfront.c code, but hey...who knows.
If I recall correctly, rightscale used to assume you were using their AMIs - maybe those AMIs saw the devices incorrectly, as /dev/sd*? So if you're not using their AMI, then something they aren't expecting is happening. But yes, they most certainly should understand devices other than just sd* - so a patch is the best bet :) 2011/2/10 Raphaël De GIUSTI <[email protected]> > As far as I know, the device name could be anything, as long as the device > is associated with the right minor and major number. The symlink is > not necessarily ugly, but the patch solution is better imo. > > > On Thu, Feb 10, 2011 at 3:39 AM, David HM Spector > <[email protected]>wrote: > >> Iiinteresting. Seems like the rightscale AWS gem (which I am using in my >> scripts to actually do the attach of the EBS volume) doesn't like xvd device >> entries.. however symlinking the sd device name to the real xen one allows >> it to work (ugly, yes... but it works)... will have to look into that and >> submit a patch if its really broken. >> >> thanks much for your help - it got me where I needed to be >> >> cheers, >> David >> >> On Feb 9, 2011, at 6:28 PM, Brian LaMere wrote: >> >> replace "sd" with "xvd" and you'll be set. It's not a "*s*csi *d*isk" >> but instead a "*x*en *v*irtual (block) *d*evice" >> >> On older AKIs, sometimes one would see drives presented to the OS as >> /dev/sd* still, but it seems like since pvgrub this is no longer the case. >> It's more "honest" this way regardless; the kernel is seeing it (or at >> least, presenting it) more accurately for what it is. It never should have >> listed those drives as /dev/sd* >> >> So...point is...it's not supposed to be /dev/sd* - just like it wasn't >> /dev/sd* when you used old IDE drives (those were /dev/hd*). Almost all >> kernels have built-in support for IDE and SCSI, but not for Xen; that's >> loaded as a module, instead. If you do an "lsmod" you should see a loaded >> module named xen_blkfront - note also that it has a "used by" value that is >> the same as the number of (valid...) /dev/xvd* block devices. >> >> See http://lxr.free-electrons.com/source/drivers/block/xen-blkfront.c for >> info about that module... >> >> Does that answer the question? Disregard what Amazon says you should see >> the device reporting as - it should be xvd*, not sd*. It's not using the >> scsi driver. >> >> Brian >> >> On Wed, Feb 9, 2011 at 5:49 PM, David HM Spector >> <[email protected]>wrote: >> >>> I am trying to get an attached EBS volume to mount on a customized (ots >>> of php and rails packages) version of the FC14 AMI. >>> It seems the sd devices aren't made by default; but even once they're >>> made, mount refuses to mount the volume >>> saying " /dev/sdf is not a valid block device" Its a an ext3 filesystem >>> so nothing novel there. >>> >>> Everything works fine on my older instances with the same scripts; I can >>> get he EBS volume to attach to the instance (I have >>> some custom ruby scripts that work at startup to attach vol ids passed as >>> user data) and the perms/maj/min device numbers >>> look OK too (as one would expect from MAKEDEV). >>> >>> Anything obvious I am missing? >>> >>> >>> tnx, >>> David >>> >>> ---------------------------------------------------------------------------------------------- >>> David HM Spector >>> spector at zeitgeist dot com >>> http://www.zeitgeist.com >>> ~ ~ ~ >>> "New and stirring things are belittled because if they are not belittled, >>> the >>> humiliating question arises, 'Why then are you not taking part in them?'" >>> >>> --H. G. Wells >>> >>> >>> _______________________________________________ >>> cloud mailing list >>> [email protected] >>> https://admin.fedoraproject.org/mailman/listinfo/cloud >>> >>> >> _______________________________________________ >> cloud mailing list >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> >> >> >> ---------------------------------------------------------------------------------------------- >> >> David HM Spector >> >> spector at zeitgeist dot com >> http://www.zeitgeist.com >> >> ~ ~ ~ >> >> "New and stirring things are belittled because if they are not belittled, >> the >> >> humiliating question arises, 'Why then are you not taking part in them?'" >> >> >> --H. G. Wells >> >> >> _______________________________________________ >> cloud mailing list >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/cloud >> >> > > _______________________________________________ > cloud mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/cloud > >
_______________________________________________ cloud mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/cloud
