The Complete Geek

• 1)      Log into the member you wish to convert (or the group IP) via SSH or telnet. You must log in as an administrator account but it need not be grpadmin (though that would work too)
• 2)      Type the following line “member select {member name} configure raid-policy {policy name}  “ (no quotes)

Labels: Converting RAID, equallogic, RAID, RAID6-nospares

# posted by Slackerhobo : 8:57 PM  0 Comments Links to this post

There are many many improvements that I love in this post it is going to be GUI features that I like that make my management life easier. The order does not really matter here to me all are very useful.

1) Search

Absolutely love the search box, with over 300 virtuals in 5 different clusters even though they are numerically ordered by name they are still a pain to find. Combine that with the fact that it searches the note fields makes it amazing (especially if you do like us and consistently put the client name and function for every virtual in the notes)

2) Storage vmotion

While there are other changes I am focusing here on simple act of integrating it into the gui, while I am a CLI fan at heart, the ease it makes it easy, especially tracking down which volumes have free space when you have many VMFS volumes in a cluster

3) Storage Views

The ease of tracking down and mapping which VMFS volumes are attached where or which virtuals are in the wrong volume make this a big tool for us. We have phased rollouts in pre-deployment volumes and clusters for virtual sprawl reasons. But that means its easy to vmotion a virtual while forgetting to move it out of the pre-production volume.

4) Performance overview

For a quick look the overview section in the performance tab is a big feature add, I do like getting a dashboard view of some of the important stats to see the health of your system

5) Alerts

While this is not expressly a GUI addition I am going to bundle it with it. The additional alarms are a life saver. One of my favorites is being able to alert on snapshot size and being able to set thresholds. We have whole teams of people building virtual, it is easy for one or two to forget one out there. We used to track this by a lot of SQL fancyness but no more!

There are many and many other alerts that are useful that I will probably create a separate post on just these after we investigate further.

Labels: ESX, Vcenter, Virtual Center, Vmware, Vsphere, vsphere4

# posted by Slackerhobo : 11:50 PM  0 Comments Links to this post

Labels: Kaseya, Vmware

# posted by Slackerhobo : 8:30 AM  3 Comments Links to this post

I am approaching this from the point of view of our EquaLlogic SAN some of these (namely number 4) may not be as big of an issue. Also discussing in the 3.5 world for most of this will address what 4.0 changes in the end

Pro

1) One place that VMDK’s are a good choice to use is where you have questionable System administrators with local administrative accounts. In some cases we have vendor or client administer accounts (they are the exception) so they can handle specific processes. The problem is if the virtual actually has adapters on the SAN network they have a more direct avenue for causing problems weather on purpose or accident. Anything from re-addressing adapters or some mal-ware that could get installed as they are an admin (not likely in a controlled environment but still possible)As such VMDK’s protect that network from those admins.

2) VMDK’s also behave nicer in the case of SAN failure or performance issues, if a virtual looses connectivity to its VMDK it pauses rather than dropping the volume.

3) Svmotion, while moving volumes between pools is easy moving them between groups and or different SAN vendors is much harder. There are processes but if your data is in VMDK it is a snap. Simply mount the new SAN or volume in a new group and fly, no downtime necessary for what would have been a major move. Virtual storage is the best thing for storage administrators.

4) Not having to administer separate SAN volumes and configuration. This cuts deployment time for a SAN volume to a fraction of the time separate volumes take. Not having to setup ACLS, MPIO configurations … install HIT and configure adapters. It cuts deployment time from a half an hour to 2 Minutes and moves the knowledge out to system administrators rather than storage administrators.

5) We have run across a number of situations lately that either required a host integration tool upgrade or MSISCSI version upgrade to overcome the loss of connectivity to volumes. This is a BIG deal when that means touching 200+ servers. Reducing update and hand maintenance tasks is a huge money saver from the point of view of labor costs.

6) And the last advantage Ill discuss is administration security, unfortunately the granularity of permissions for EqualLogic is lacking. You may not want all your system administrators to be group admins just so they can expand a SAN volume. We have in the past written custom interfaces to achieve this without giving them direct permission but VMDK’s also achieves this. No longer does a sys admin need to be a group administrator on your SAN just for creating new volumes or expanding drives.

Con:

1) Performance: This is the biggest concern with 3.5 not supporting MPIO on its software initiator the performance is just not as good in the equallogic world where MPIO has a huge impact on performance.

2) Not able to take advantage right now of some of the advanced features the Host integration toolkit provides you. Most people are not using these features so it is not as large of a concern

And I am not pleased to say that we are seeing awesome performance (especially with the new beta driver) out of vsphere4 as the software initiator now does have MPIO support. We are likely to evaluate it as our default configuration (presuming successful testing in production) because of the advantages.

Labels: EquaLogic, ISCSI, Storage, VMDK, VMFS

# posted by Slackerhobo : 8:35 PM  2 Comments Links to this post

Labels: equallogic

# posted by Slackerhobo : 3:06 PM  2 Comments Links to this post