Looking at the SR, looks like your questions were answered? For the rest, this was the recommendation:
From ECC you may view the Meta and its members in a graphical format,
Select Relationship from ECC console. Expand Symmetrix from Storage Systems and select Meta Devices.
This would show the Meta Head, Meta Members and Back-End devices and the FA it is mapped to.
You may export this in an html format.
For backend, select the device and look under the properties which displays the meta members and the backend devices. For viewing submembers, select relationships and then storage device.
The graphical format is NOT what i am looking for.. that i know about that, but that means i have to type out a few thousand different devices.
I personally found a work-around solution of right clicking on the DMX array, going to relationships, and than selecting Storage Devices.
This gives me the Devices and sub-Devices in a workable format, but not exactly what i'm looking for. To get what i'm looking for we're combing about 3 different tables together after we massage the tables to have the same consitant columns.
So a worak-around is found (by me) but this is not solved.
There has to be an easier way to get this information output as 1 table. Yes, the relationship view has the information i am looking for, but you can't export it as an excel sheet & you can't view all 500+ Metas on our array with it.
All i want, is a that data from the relationships view in a spreadsheet. I was hoping there could be some Solutions Enabler command to pull that information directly from the VCMDB.
If you have access to an XSLT processor, this should do the trick. (I run this on a Unix-based system but it's do-able on Windows as well).
$ symdev -sid 0123 -v list -output xml_element >symdev.0123.xml
$ xsltproc metainfo.xsl symdev.0123.xml
*** metainfo.xsl ***
http://www.w3.org/1999/XSL/Transform">
*** EOF ***
Note there are tab characters (which don't cut/paste too well) to generate a tab-separated file.
The resulting output looks like this:
00D4 00D4 Head 00D5 00D4 Member 00D6 00D4 Member 00D7 00D7 Head 00D8 00D7 Member 00D9 00D7 Member 00DA 00D7 Member 00DB 00D7 Member 00DC 00D7 Member 00DD 00D7 Member 00DE 00D7 Member 00DF 00D7 Member 0100 0100 Head 0101 0100 Member 0102 0100 Member 0103 0100 Member 0104 0104 Head 0105 0104 Member 0106 0104 Member 0107 0104 Member 0162 0162 Head 0163 0162 Member 0164 0162 Member 0165 0162 Member 0166 0162 Member 0167 0162 Member 0168 0162 Member 0169 0162 Member 016A 0162 Member 016B 0162 Member 016C 0162 Member 016D 0162 Member 016E 0162 Member 016F 016F Head 0170 016F Member 0171 016F Member 0172 016F Member 0173 016F Member 0174 016F Member 0175 016F Member 0176 016F Member 0177 016F Member 0178 016F Member 0179 016F Member 017A 016F Member 017B 016F Member
# dump XML my $twig = new XML::Twig ( twig_handlers => { 'Device' => \&device_handler } );
print "Running symcfg discover...\n"; print `symcfg discover`; print "Dumping symdev list to temporary file 'symdev_list_v.xml'\n"; print `symdev list -v -output XML > symdev_list_v.xml`; $twig -> parsefile ( "symdev_list_v.xml" );
Will work on both Unix and Windows, but with Windows/Activestate perl, you'll need to download and install XML::Twig yourself. It writes out a file, rather than just running in memory because 'symdev list -output XML' gets pretty big - and XML parsing can take a lot of memory, so I work through it sequentially.
An interesting example of the trade-off between space and time. You are definitely correct about XSLT being memory hungry. A 70 MB symdev XML output file will consume 600MB (or more) of memory processed through Xalan. I ran your Perl script against athe same file. Very memory efficient (about 10MB), but it took almost 10 minutes to run. Xalan takes less than 90 seconds.
That being said... nice to see other ways of skinning the proverbial cat.
MikeMac1
2 Intern
•
292 Posts
0
March 9th, 2010 08:00
Looking at the SR, looks like your questions were answered? For the rest, this was the recommendation:
From ECC you may view the Meta and its members in a graphical format,
Select Relationship from ECC console.
Expand Symmetrix from Storage Systems and select Meta Devices.
This would show the Meta Head, Meta Members and Back-End devices and the FA it is mapped to.
You may export this in an html format.
For backend, select the device and look under the properties which displays the meta members and the backend devices. For viewing submembers, select relationships and then storage device.
dernsber
52 Posts
0
March 9th, 2010 08:00
The graphical format is NOT what i am looking for.. that i know about that, but that means i have to type out a few thousand different devices.
I personally found a work-around solution of right clicking on the DMX array, going to relationships, and than selecting Storage Devices.
This gives me the Devices and sub-Devices in a workable format, but not exactly what i'm looking for. To get what i'm looking for we're combing about 3 different tables together after we massage the tables to have the same consitant columns.
So a worak-around is found (by me) but this is not solved.
There has to be an easier way to get this information output as 1 table. Yes, the relationship view has the information i am looking for, but you can't export it as an excel sheet & you can't view all 500+ Metas on our array with it.
All i want, is a that data from the relationships view in a spreadsheet. I was hoping there could be some Solutions Enabler command to pull that information directly from the VCMDB.
beran1
9 Posts
1
March 9th, 2010 10:00
If you have access to an XSLT processor, this should do the trick. (I run this on a Unix-based system but it's do-able on Windows as well).
$ symdev -sid 0123 -v list -output xml_element >symdev.0123.xml
$ xsltproc metainfo.xsl symdev.0123.xml
*** metainfo.xsl ***
http://www.w3.org/1999/XSL/Transform ">
*** EOF ***
Note there are tab characters (which don't cut/paste too well) to generate a tab-separated file.
The resulting output looks like this:
00D4 00D4 Head
00D5 00D4 Member
00D6 00D4 Member
00D7 00D7 Head
00D8 00D7 Member
00D9 00D7 Member
00DA 00D7 Member
00DB 00D7 Member
00DC 00D7 Member
00DD 00D7 Member
00DE 00D7 Member
00DF 00D7 Member
0100 0100 Head
0101 0100 Member
0102 0100 Member
0103 0100 Member
0104 0104 Head
0105 0104 Member
0106 0104 Member
0107 0104 Member
0162 0162 Head
0163 0162 Member
0164 0162 Member
0165 0162 Member
0166 0162 Member
0167 0162 Member
0168 0162 Member
0169 0162 Member
016A 0162 Member
016B 0162 Member
016C 0162 Member
016D 0162 Member
016E 0162 Member
016F 016F Head
0170 016F Member
0171 016F Member
0172 016F Member
0173 016F Member
0174 016F Member
0175 016F Member
0176 016F Member
0177 016F Member
0178 016F Member
0179 016F Member
017A 016F Member
017B 016F Member
Hope this helps.
dernsber
52 Posts
0
March 9th, 2010 13:00
that would be perfect... i'll have to look a lil deeper to try it, but will try it.
Ed_R1
53 Posts
0
March 10th, 2010 06:00
I've recently started using perl, and XML::Twig to parse SYMAPI XML.
Er.
Something like:
use strict;
use warnings;
use XML::Twig;
sub device_handler
{
my ( $twig, $device ) = @_;
unless ( $device -> first_child('Flags') -> first_child('meta') -> text =~ m/None/ )
{
my $dev = $device -> first_child('Dev_Info') -> first_child('dev_name') -> text;
my $meta_head = $device -> first_child('Meta') -> first_child('Meta_Device') -> first_child('dev_name') -> text;
print "$meta_head,$dev\n";
}
$twig -> purge;
}
# dump XML
my $twig = new XML::Twig (
twig_handlers =>
{ 'Device' => \&device_handler } );
print "Running symcfg discover...\n";
print `symcfg discover`;
print "Dumping symdev list to temporary file 'symdev_list_v.xml'\n";
print `symdev list -v -output XML > symdev_list_v.xml`;
$twig -> parsefile ( "symdev_list_v.xml" );
Will work on both Unix and Windows, but with Windows/Activestate perl, you'll need to download and install XML::Twig yourself.
It writes out a file, rather than just running in memory because 'symdev list -output XML' gets pretty big - and XML parsing can take a lot of memory, so I work through it sequentially.
beran1
9 Posts
0
March 16th, 2010 20:00
Ed_R, Interesting piece of code...
An interesting example of the trade-off between space and time. You are definitely correct about XSLT being memory hungry. A 70 MB symdev XML output file will consume 600MB (or more) of memory processed through Xalan. I ran your Perl script against athe same file. Very memory efficient (about 10MB), but it took almost 10 minutes to run. Xalan takes less than 90 seconds.
That being said... nice to see other ways of skinning the proverbial cat.