Change iGroup ostype - disruptive?

[#1]

Hi all,

Our Vsphere cluster is identified by a single iGroup on the netapp target end. Unfortunately, this igroup was set to ostype linux at creation. When trying to mount a snapshot of a cluster datastore using smvi 2, I get an error saying that the ostype isn't vmware. Does anyone know if doing an "igroup set [igroup name] ostype" command on the existing igroup is disruptive or not? It would be nice to not have to take down all guests to make this change.

Thanks

[#2]

Hi!

I had test today with 1VM on vSphere 4.0.0, OnTap 7.3.2.

Changed igroup ostype while vm is running.

And... nothing happened with my windows virtual machine.

In real world i never do that.

[#3]

Thanks for answering. The igroup you changed was for the ESX host connections, correct? I can't believe that no one has had this issue. Netapp wasn't able to give me an positive answer one way or another.

Thanks!

[#4]

First i create igroup ostype linux and create new data store on esx host.

Then migrate exiting vm on new data store and run it.

Start large file copy operation on this vm and run igroup set igroupname ostype vmware from telnet session.

I think this not disruptive operation (if you have backup and do this in non working hours).

But to be sure you ned get answer form NetApp PS.

[#5]

Thanks for the testing results. I think I'll shutdown db services on vm's and go for it. PS had no definitive answer for me.

Regards,

Glen

[#6]

Ok. Please let me know after that.

Thank you!

[#7]

How did it go? You could also possibly create a new igroup with the OS type VMware, map the LUNs to the igroup with the same IDs, and remove the original Linux igroup.

[#8]

The change should be  non-disruptive unless you have the same initiators as part of an igroup  in partner node...In case of having the initiators as part of an igroup  on partner node, it will be a disruptive change(in single image  mode-which is default now) as you need to remove the igroup from partner  and make the necessary changes.

changing igroup will make scsi behaviour  change on the host for a brief period which may not be noticable...so it  should be non-disruptive.

[#9]

I'm not sure why I didn't think of this at first....but it should actually be pretty straightforward (although somewhat tedious) to do this completely non-disruptively presuming a DRS cluster....

1. Make a new igroup of type vmware.
2. Map that igroup to the existing LUNs with the same LUN ID #'s.
3. Put a VMware host into Maintenance Mode.
4. Remove that host's IQN (or WWPN's for that matter) from the existing igroup and add it to the new igroup (preferably do this quickly).
5. Rescan storage in vCenter and verify can see all LUNs and datastores.
6. Remove host from Maintenance Mode.
7. Rinse and repeat through the rest of your cluster.