Thank you very much, guys. Passing the parameter to the kernel in grub and changing the direct references to /dev/xvde to its UUID worked perfectly. Luis Alen www.izap.com.br Ligue com tarifa local de todo o Brasil 4020.3000 On Wed, Jan 16, 2013 at 2:06 PM, Andy Grimm <agrimm at gmail.com> wrote: > On Wed, Jan 16, 2013 at 10:04 AM, Luis Fernando Alen < > luis.alen at izap.com.br> wrote: > >> Andy, >> >> Actually I'm not trying to build a whole new kernel. I'm just trying to >> apply the patched module into my actual kernel. >> >> Does this patch really requires a kernel rebuild, or you mean building a >> new one will save me from the trouble of applying the module into the >> running kernel? >> > > Perhaps I'm missing some key information here, but you should not need to > rebuild anything at all. You only need to modify the ramdisk to load the > xen_blkfront module with sda_is_xvda=1 . There are various ways to do > this; adding xen_blkfront.sda_is_xvda=1 to the kernel command line in > grub.conf is probably the most expedient. > > Hope this helps. > > Andy > > > >> >> Luis Alen >> www.izap.com.br >> Ligue com tarifa local de todo o Brasil 4020.3000 >> >> >> >> On Wed, Jan 16, 2013 at 10:57 AM, Nico Kadel-Garcia <nkadel at gmail.com>wrote: >> >>> >>> >>> On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen < >>> luis.alen at izap.com.br> wrote: >>> >>>> Thank you, Andy. >>>> >>>> I tried to apply the patch you guys mentioned by compiling the module >>>> following instructions at >>>> http://wiki.centos.org/HowTos/BuildingKernelModules#head-d2e4c05886f94c701e4ae74387d41d8c40c25d01, >>>> but it didn't work. >>>> >>>> I've been struggling with it for the last 8 hours and no luck so far. >>>> >>>> I really don't know what's wrong. I'm not a linux kernel developer and >>>> I'm most likely failing because of something stupid. >>>> >>>> I know this must not the right place to ask for help on such matters, >>>> but if you guys could shed some light here, I'd really appreciate that. >>>> >>>> Well, if you're up to it, here's the situation: >>>> >>>> Looks like the module compilation worked (no errors or warnings >>>> occurred when I followed the instructions at the centos wiki), but I'm >>>> unable to load the new module to my running kernel. >>>> >>> >>> If you're building a new kernel, you should really give it a new name >>> and fully install it as a distinct kernel. The safest way to do this is to >>> work from the SRPM, put the patch in *there* and update the "Release:" >>> number in the kenrel.spec file This will avoid precisely the issues you >>> described. >>> >>> Do you need a walkt hrough on rebuilding a package from SRPM's? >>> >>> >>>> I even copied the compiled and patched module to >>>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/ (overwrote >>>> the original) and /lib/modules/2.6.32-279.19.1.el6.x86_64/extra and >>>> rebooted the instance... >>>> >>>> Also, dmesg does not complain about a thing... >>>> >>>> *# modinfo >>>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/xen-blkfront.ko >>>> * >>>> *filename: >>>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/xen-blkfront.ko >>>> * >>>> *alias: xenblk* >>>> *alias: xen:vbd* >>>> *alias: block-major-202-** >>>> *license: GPL* >>>> *description: Xen virtual block device frontend* >>>> *srcversion: B00B4183E470515A96DA320* >>>> *depends: * >>>> *vermagic: 2.6.32-279.19.1.el6.x86_64 SMP mod_unload modversions >>>> * >>>> *parm: sda_is_xvda:sdX in guest config translates to xvdX, >>>> not xvd(X+4) (bool)* >>>> * >>>> * >>>> *# uname -r* >>>> *2.6.32-279.19.1.el6.x86_64* >>>> >>>> I also tried to remove the module and insert the patched one with >>>> insmod, but modprobe and rmmod are unable to unload it. They say it's in >>>> use. >>>> >>>> *# lsmod |grep blkfront* >>>> *xen_blkfront 15495 1 * >>>> >>>> I don't know what this "1" stands for, but if I were to guess, I'd say >>>> it's something unremovable... >>>> >>>> Please let me know if you need any other information. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> >>>> >>>> Luis Alen >>>> www.izap.com.br >>>> Ligue com tarifa local de todo o Brasil 4020.3000 >>>> >>>> >>>> >>>> On Tue, Jan 15, 2013 at 4:13 PM, Andy Grimm <agrimm at gmail.com> wrote: >>>> >>>>> See https://bugzilla.redhat.com/show_bug.cgi?id=729586 >>>>> >>>>> On Tue, Jan 15, 2013 at 1:10 PM, Luis Fernando Alen < >>>>> luis.alen at izap.com.br> wrote: >>>>> >>>>>> Hello, list. >>>>>> >>>>>> Yesterday I was pleased to see that Centos has released official >>>>>> images at the aws marketplace. Nice job. >>>>>> >>>>>> Today I started playing with the Centos 6.3 image ( >>>>>> https://aws.amazon.com/marketplace/pp/B00A6L6F9I, on which I plan to >>>>>> deploy a gluster cluster in production soon) and noticed a weird thing. >>>>>> >>>>>> EBS Volumes attached to sd<X> are translated to xvd<Y> at the OS >>>>>> level. However, after a few research and IRC chat, I figured out that it's >>>>>> not weird, it's actually a normal and expected behavior (thanks for your >>>>>> help, z00dax). >>>>>> >>>>>> sdX is actually mapped to xvdX+4. There is a consistent offset of 4. >>>>>> Suppose you attach an ebs volume to /dev/sdf. It'll be translated to xvdj >>>>>> at the OS level. sdg to xvdk, sdh to xvdl and so on. >>>>>> >>>>>> Allright. After having figured the mystery out, it became easy to >>>>>> work on automations that deal with ebs volumes and file systems, such as >>>>>> volumes created, attached and mounted on the fly, snapshots that freeze >>>>>> file systems and so on... >>>>>> >>>>>> However, I really do think to myself: Wouldn't it be cleaner if the >>>>>> image use simple translation (sdX to xvdX)? If I'm not wrong, Rightscale >>>>>> uses this on their Centos images and it's much simpler. There's no extra >>>>>> work needed to deal with that 4 offset when you want to automate things. >>>>>> >>>>>> Is there a reasonable reason for the 4 offset which makes it >>>>>> unchangeable? >>>>>> >>>>>> It's just a thought. I think it's worth considering it.. >>>>>> >>>>>> Luis Alen >>>>>> www.izap.com.br >>>>>> Ligue com tarifa local de todo o Brasil 4020.3000 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CentOS-virt mailing list >>>>>> CentOS-virt at centos.org >>>>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> CentOS-virt mailing list >>>>> CentOS-virt at centos.org >>>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> CentOS-virt mailing list >>>> CentOS-virt at centos.org >>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>> >>>> >>> >>> _______________________________________________ >>> CentOS-virt mailing list >>> CentOS-virt at centos.org >>> http://lists.centos.org/mailman/listinfo/centos-virt >>> >>> >> >> _______________________________________________ >> CentOS-virt mailing list >> CentOS-virt at centos.org >> http://lists.centos.org/mailman/listinfo/centos-virt >> >> > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20130116/79600c83/attachment-0006.html>