[CentOS-virt] xen device mapping/translation

Wed Jan 16 17:07:21 UTC 2013
Luis Fernando Alen <luis.alen at izap.com.br>

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-0003.html>