Thread: [Aoetools-discuss] Help: aoe-stat returns nothing
Brought to you by:
ecashin,
elcapitansam
From: Lee E. <ope...@gm...> - 2011-07-15 03:42:18
|
Hi, I use Fedora 14 to setup AoE target and initiator. In target side: [root@storage ~]# modprobe aoe [root@storage ~]# lsmod | grep aoe aoe 24631 0 [root@storage ~]# /etc/init.d/vblade restart Shutting down vblade: [ OK ] Starting up vblade: /dev/vdc (e0.0@eth0) [pid 3457] [ OK ] [root@storage ~]# ps auwx | grep vblade root 3457 0.0 0.2 4204 560 pts/0 S 23:38 0:00 vblade -m 52:54:00:4C:0A:01 0 0 eth0 /dev/vdc [root@storage ~]# cat /etc/vblade.conf eth0 0 0 /dev/vdc 52:54:00:4C:0A:01 [root@storage ~]# In initiator side: [root@server ~]# modprobe aoe [root@server ~]# lsmod | grep aoe aoe 24631 0 [root@server ~]# aoe-interfaces eth0 [root@server ~]# aoe-discover [root@server ~]# aoe-stat [root@server ~]# aoe-version aoetools: 23 installed aoe driver: 47 running aoe driver: 47 [root@server ~]# I don't know why aoe-stat returns nothing. I think the target side has exported the disk already. Could anyone tell me how to fix that? Thanks very much. Regards, Eric Lee |
From: Jeff S. <jef...@ep...> - 2011-07-15 04:11:34
|
> -----Original Message----- > From: Lee Eric [mailto:ope...@gm...] > Sent: Thursday, July 14, 2011 11:42 PM > > [root@storage ~]# modprobe aoe Note: There's normally no reason to load the aoe module on the target, but it is probably harmless to do so. > eth0 0 0 /dev/vdc 52:54:00:4C:0A:01 > [root@server ~]# modprobe aoe > [root@server ~]# lsmod | grep aoe > aoe 24631 0 > [root@server ~]# aoe-interfaces eth0 > [root@server ~]# aoe-discover > [root@server ~]# aoe-stat Run "dmesg" here to see if the aoe module found anything. Since aoe-stat returned no output, I'm guessing it did not. The next step would be to check network connectivity. Make sure the target is reachable from the initiator, they are on the same subnet (i.e. no router in between) and packet filtering (iptables) isn't blocking AoE traffic. -Jeff |
From: Lee E. <ope...@gm...> - 2011-07-15 04:58:02
|
Hi Jeff, I just found one log item "[ 375.432193] aoe: AoE v47 initialised." in dmesg at initiator side. The target and the initiator are in the subnet. Both systems are virtual machines and the network is bridged by a host bridge virbr0. Any idea? Eric Lee On Fri, Jul 15, 2011 at 11:56 AM, Jeff Sturm <jef...@ep...> wrote: >> -----Original Message----- >> From: Lee Eric [mailto:ope...@gm...] >> Sent: Thursday, July 14, 2011 11:42 PM >> >> [root@storage ~]# modprobe aoe > > Note: There's normally no reason to load the aoe module on the target, but it is probably harmless to do so. > >> eth0 0 0 /dev/vdc 52:54:00:4C:0A:01 > >> [root@server ~]# modprobe aoe >> [root@server ~]# lsmod | grep aoe >> aoe 24631 0 >> [root@server ~]# aoe-interfaces eth0 >> [root@server ~]# aoe-discover >> [root@server ~]# aoe-stat > > Run "dmesg" here to see if the aoe module found anything. Since aoe-stat returned no output, I'm guessing it did not. > > The next step would be to check network connectivity. Make sure the target is reachable from the initiator, they are on the same subnet (i.e. no router in between) and packet filtering (iptables) isn't blocking AoE traffic. > > -Jeff > > > |
From: Jesse B. <bec...@ma...> - 2011-07-15 14:10:29
|
On Thu, Jul 14, 2011 at 11:42:12PM -0400, Lee Eric wrote: >[root@server ~]# aoe-version > aoetools: 23 > installed aoe driver: 47 > running aoe driver: 47 >[root@server ~]# Those are ancient versions of the aoe drive. I'd grab the newest release from aoetools.sf.net (should be around version 76). > > >I don't know why aoe-stat returns nothing. I think the target side has >exported the disk already. Could anyone tell me how to fix that? > >Thanks very much. > >Regards, > >Eric Lee > >------------------------------------------------------------------------------ >AppSumo Presents a FREE Video for the SourceForge Community by Eric >Ries, the creator of the Lean Startup Methodology on "Lean Startup >Secrets Revealed." This video shows you how to validate your ideas, >optimize your ideas and identify your business strategy. >http://p.sf.net/sfu/appsumosfdev2dev >_______________________________________________ >Aoetools-discuss mailing list >Aoe...@li... >https://lists.sourceforge.net/lists/listinfo/aoetools-discuss -- Jesse Becker NHGRI Linux support (Digicon Contractor) |
From: Lee E. <ope...@gm...> - 2011-07-15 15:33:07
|
I have upgraded to the latest version but sill failed. [root@server ~]# lsmod | grep aoe aoe 46546 0 [root@server ~]# aoe-version aoetools: 32 installed aoe driver: 77 running aoe driver: 77 [root@server ~]# aoe-discover [root@server ~]# aoe-stat [root@server ~]# Any further idea? Eric |
From: Jeff S. <jef...@ep...> - 2011-07-15 15:51:18
|
> -----Original Message----- > From: Lee Eric [mailto:ope...@gm...] > Sent: Friday, July 15, 2011 11:33 AM > > [root@server ~]# aoe-version > aoetools: 32 > installed aoe driver: 77 > running aoe driver: 77 > [root@server ~]# aoe-discover > [root@server ~]# aoe-stat > [root@server ~]# > > Any further idea? At this point you may have to resort to debugging techniques. Either trace the vblade process on the target, to see if it receives and handles any requests from the initiator (during an aoe-discover operation), and/or dump network packets on both target and initiator. Libpcap doesn't have any support for dumping AoE packets as far as I am aware, but you should at least be able to see the raw packet bytes. (The Ethernet type is 0x88a2.) If things are working normally an AoE request will be sent from the initiator when the driver module is loaded, or when an aoe-discover is issued. The target will receive this request and issue a response, which the initiator will receive. See if you can find out where things are breaking. -Jeff |
From: Lee E. <ope...@gm...> - 2011-07-16 03:18:19
|
Hey mate, I notice something interesting. I run following commands on initiator side. [root@server ~]# aoe-sancheck Probing...done. ========================================== INTERFACE SUMMARY ========================================== Name Status MTU PCI ID eth0 UP 1500 ========================================== DEVICE SUMMARY ========================================== Device Macs Payload Local Interfaces e0.0 1 1024 eth0 [root@server ~]# ls /dev/etherd/ discover err flush interfaces revalidate [root@server ~]# aoe-discover [root@server ~]# aoe-stat [root@server ~]# But as you see, aoe-stat still returns nothing. I don't know why this happens. Eric |
From: Lee E. <ope...@gm...> - 2011-07-16 14:21:14
|
Hey mates, I realize something I missed. I found an error message in udev part while system booted up. It is "Starting udev: udevd[387]: NAME="%k" is ignored, because it breaks kernel supplied names, please remove it from /etc/udev/rules.d/60-aoe.rules:9". Here's the /etc/udev/rules.d/60-aoe.rules file content. # aoe char devices SUBSYSTEM=="aoe", KERNEL=="discover", NAME="etherd/%k", GROUP="disk", MODE="0220" SUBSYSTEM=="aoe", KERNEL=="err", NAME="etherd/%k", GROUP="disk", MODE="0440" SUBSYSTEM=="aoe", KERNEL=="interfaces", NAME="etherd/%k", GROUP="disk", MODE="0220" SUBSYSTEM=="aoe", KERNEL=="revalidate", NAME="etherd/%k", GROUP="disk", MODE="0220" SUBSYSTEM=="aoe", KERNEL=="flush", NAME="etherd/%k", GROUP="disk", MODE="0220" # aoe block devices KERNEL=="etherd*", NAME="%k", GROUP="disk" So it seems the udev rule has something incompatibility. And furthermore, aoeping also no response while running. [root@server ~]# aoeping -v 0 0 eth0 tag: 80000000 eth: eth0 shelf: 0 slot: 0 But as I mentioned in the last email, aoe-sancheck works well and can get the information from the target. Any idea? Thanks. Eric |
From: Lee E. <ope...@gm...> - 2011-07-17 14:16:10
|
Hi, Anyone have any idea about this strange problem? I really appreciate that. Eric On Sat, Jul 16, 2011 at 10:21 PM, Lee Eric <ope...@gm...> wrote: > Hey mates, > > I realize something I missed. I found an error message in udev part > while system booted up. It is "Starting udev: udevd[387]: NAME="%k" is > ignored, because it breaks kernel supplied names, please remove it > from /etc/udev/rules.d/60-aoe.rules:9". Here's the > /etc/udev/rules.d/60-aoe.rules file content. > > # aoe char devices > SUBSYSTEM=="aoe", KERNEL=="discover", NAME="etherd/%k", GROUP="disk", > MODE="0220" > SUBSYSTEM=="aoe", KERNEL=="err", NAME="etherd/%k", GROUP="disk", MODE="0440" > SUBSYSTEM=="aoe", KERNEL=="interfaces", NAME="etherd/%k", > GROUP="disk", MODE="0220" > SUBSYSTEM=="aoe", KERNEL=="revalidate", NAME="etherd/%k", > GROUP="disk", MODE="0220" > SUBSYSTEM=="aoe", KERNEL=="flush", NAME="etherd/%k", GROUP="disk", MODE="0220" > > # aoe block devices > KERNEL=="etherd*", NAME="%k", GROUP="disk" > > So it seems the udev rule has something incompatibility. > > And furthermore, aoeping also no response while running. > > [root@server ~]# aoeping -v 0 0 eth0 > tag: 80000000 > eth: eth0 > shelf: 0 > slot: 0 > > But as I mentioned in the last email, aoe-sancheck works well and can > get the information from the target. > > Any idea? Thanks. > > Eric > |
From: Lee E. <ope...@gm...> - 2011-07-18 03:12:28
|
Hey mate, I use tcpdump to get the ethernet packets and notice something interesting. On the target I run "tcpdump -i eth0 -e -p not ip" and run aoe-discover on initiator then got following results from the target side. 11:01:50.884069 52:54:00:cd:dd:fc (oui Unknown) > Broadcast, ethertype Unknown (0x88a2), length 32: 0x0000: 1000 ffff ff01 0000 0000 0000 0000 0000 ................ 0x0010: 0000 .. And on the initiator I also can get following results. 11:04:46.752362 52:54:00:cd:dd:fc (oui Unknown) > Broadcast, ethertype Unknown (0x88a2), length 32: 0x0000: 1000 ffff ff01 0000 0000 0000 0000 0000 ................ 0x0010: 0000 So I think the Ethernet packets transfered well. But it seems some magics make this unavailable. Any idea? Eric |
From: Lee E. <ope...@gm...> - 2011-07-18 06:11:29
|
Hey buddy, I have fixed the problem. It was caused by Fedora old AoE target and initiator packages. I downloaded the latest version target and initiator software. It works well. [20093.808263] aoe: e0.0: setting 1024 byte data frames [20093.811872] aoe: 5254004c0a01 e0.0 v4014 has 1024000 sectors [20093.819626] etherd/e0.0: unknown partition table [20347.586636] etherd/e0.0: p1 /dev/etherd/e0.0p1 495M 26M 470M 6% /aoe Thanks all. Eric |