[CentOS-virt] xen device mapping/translation

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20130116/632857b4/attachment-0002.html>