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
See https://bugzilla.redhat.com/show_bug.cgi?id=729586
On Tue, Jan 15, 2013 at 1:10 PM, Luis Fernando Alen luis.alen@izap.com.brwrote:
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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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-d2e4c05886f94c701e4..., 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.
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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen luis.alen@izap.com.brwrote:
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-d2e4c05886f94c701e4..., 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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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?
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@gmail.comwrote:
On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen <luis.alen@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-d2e4c05886f94c701e4..., 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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On Wed, Jan 16, 2013 at 10:04 AM, Luis Fernando Alen luis.alen@izap.com.brwrote:
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?
Since you're replacing a critical, actively used component, you're going to have.... adventures if you try to just slide it into place in your existing kernel. You'll be much server if you simply build a new kernel.
On Wed, Jan 16, 2013 at 10:04 AM, Luis Fernando Alen luis.alen@izap.com.brwrote:
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@gmail.comwrote:
On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen < luis.alen@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-d2e4c05886f94c701e4..., 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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
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@gmail.com wrote:
On Wed, Jan 16, 2013 at 10:04 AM, Luis Fernando Alen < luis.alen@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@gmail.comwrote:
On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen < luis.alen@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-d2e4c05886f94c701e4..., 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@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@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@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
On 01/16/2013 01:39 AM, Luis Fernando Alen wrote:
Thank you, Andy.
I tried to apply the patch you guys mentioned by compiling the module following instructions at
You dont need to build anything, just consider the implications of xen_blkfront.sda_is_xvda kernel boot option.
-
Andy Grimm -
Karanbir Singh -
Luis Fernando Alen -
Nico Kadel-Garcia