BTW, if Dell try for a "not supported" again, you can point them to http://en.community.dell.com/techcenter/b/techcenter/archive/2013/01/03/announcing-the-release-of-red-hat-enterprise-rhev-3-1-on-dell-poweredge-servers.aspx
They have a similar announcement for 3.0: http://en.community.dell.com/techcenter/b/techcenter/archive/2012/07/13/red-hat-enterprise-virtualization-rhev-3-0-works-on-dell-poweredge-servers.aspx though worded slightly differently ----- Original Message ----- > From: "Jonathan Horne" <jho...@skopos.us> > To: users@ovirt.org > Sent: Thursday, 3 January, 2013 6:00:24 PM > Subject: Re: [Users] ovirt and EqualLogic iSCSI SAN > > well, my point for asking is, so far on my EQ san i never see more > than 1 > session per ovirt node, and the point of the EQ driver is so that > each > iscsi-client can create multiple iscsi sessions per LUN as needed. > > myself, I'm using M620 blades for my nodes, and its connected to the > backplane switches which are stacked. if i use the standard EQ > config, > both interfaces on the iscsi switch (in the case of my M620, p3p1 and > p3p2) would have their own separate IP address, and the EQ driver > would > normally cause both interfaces to establish iscsi sessions to the > LUN. > but when i tried this, only 1 IP address logged in, and that leaves > me > with a single point of failure scenario which for us isn't acceptable > at > this time. > > so my current config is bonded p3p1 and p3p2 in LACP, and this is > what i > rely on for fault tolerant connections to the EQ san. but if you put > a > call into to Dell/EQ for performance issues, the first thing they > will > tell you the problem is, is the lack of the EQ driver and the use of > LACP > to access the EQ. > > and for now, this is working, but just due to the nature of the EQ > san, > its not the optimal. RHEV is *not* on the supported OS list for > this, so > Dell just scratch their head while trying to tell me what to do to > make > this work as best as it can for me. needless to say when dell comes > out > next week to validate the deployment probably the only thing that > will > pass is the switch config :) > > maybe someday ill upgrade from MyFirstSan to a bigboy san heheehh > *wink* > > > > On 1/3/13 9:32 AM, "Dan Yasny" <dya...@redhat.com> wrote: > > >EQL storage works just fine as a normal iscsi SAN, using the normal > >iscsiadm commands. The hitkit is doing things differently, and > >that's not > >necessarily the right thing to do. oVirt is trying to keep things > >generic, using standard commands, standard daemons and access paths > > > >----- Original Message ----- > >> From: "Jonathan Horne" <jho...@skopos.us> > >> To: users@ovirt.org > >> Sent: Thursday, 3 January, 2013 5:28:44 PM > >> Subject: [Users] ovirt and EqualLogic iSCSI SAN > >> > >> > >> > >> > >> > >> i have had to abandon (hopefully just for now) getting my ovirt > >> nodes > >> properly setup with my equal logic iscsi SAN. EQ has a special > >> iscsi > >> driver, and it appears that ovirt uses the regular iscsi commands > >> to > >> connect to the storage, circumventing the features of the EQ > >> driver. > >> > >> > >> unless I'm wrong, which i totally could be. > >> > >> > >> in case I'm not, will there ever be a chance of supporting the EQ > >> iscsi features, and if there is a chance, how can i help? > >> > >> > >> > >> > >> ps-- in case someone asks, here is the basic difference between a > >> normal linux iscsi command set, and the equallogic iscsi command > >> set: > >> > >> > >> normal linux: > >> iscsiadm -m discovery -t sendtargets -p IPADDRESS > >> iscsiadm -m node -T FULLIQN -p IPADDRESS -l > >> fdisk /dev/yaymydevice > >> > >> > >> equallogic: > >> iscsiadm -m discovery -t sendtargets -p IPADDRESS > >> ehcmcli login --target FULLIQN --portal IPADDRESS > >> which will then present you your device, such as > >> /dev/eql/yaymydeviceŠ > >> > >> > >> > >> > >> thanks, > >> Jonathan > >> > >> > >> > >> This is a PRIVATE message. If you are not the intended recipient, > >> please delete without copying and kindly advise us by e-mail of > >> the > >> mistake in delivery. NOTE: Regardless of content, this e-mail > >> shall > >> not operate to bind SKOPOS to any order or other contract unless > >> pursuant to explicit written agreement or government initiative > >> expressly permitting the use of e-mail for such purpose. > >> _______________________________________________ > >> Users mailing list > >> Users@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > > > >-- > > > > > > > >Regards, > > > >Dan Yasny > >Red Hat Israel > >+972 9769 2280 > > > ________________________________ > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind SKOPOS to any order or other contract unless > pursuant to explicit written agreement or government initiative > expressly permitting the use of e-mail for such purpose. > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- Regards, Dan Yasny Red Hat Israel +972 9769 2280 _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
