VMware Solutions Discussions
VMware Solutions Discussions
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
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.
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!
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.
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
Ok. Please let me know after that.
Thank you!
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.
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.
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....