NetApp Multi-Tenancy - What is the impact of NOT defining storage in fabric set up in VMM 2012?
-
2012年6月14日 13:11
We recently implemented NetApp and it appears that if we implement the storage provider for NetApp it will give VMM control of the entire NetApp storage environment. Our storage team (understandably) has "reservations" about allowing this level of access. From their research on implementing multi-tenancy it will require some major rework of the NetApp deployment (more reservations).
What's the overall impact to the functionality of VMM 2012 if we do NOT define storage in the fabric. I see we won't bet storage classifications (don't care, we only have one flavor) and we won't be able to use Rapd Provisioning. Are there other impacts (i.e., Live Migration, etc.)?
William Busby, PMP
すべての返信
-
2012年6月14日 16:53モデレータ
No. No other "impacts".
You just have to provision Storage by using netapp directly to Your hosts (FC/iSCSI) and VMM is able to detect this - through the communication With the hosts, and everything will work.
The idea behind this is that you could be able to manage the entire fabric layer of Your cloud infrastructure from VMM. SMI-S will be the New protocol the industry will be based on, and VDS will be faded out after a while.
Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
-
2012年6月14日 18:28
Thanks for the info, I'm a noob at storage so I've got more questions than answers. My storage team is concerned about implementing cluster shared volumes. In the scenario where we don't define storage in the fabric it seems we'll wind up with multiple VM's per LUN (depending on LUN size) and won't be able to adhere to the "one VM per LUN" practice for standard cluster volumes. Is there really that significant a network hit for cluster shared volumes at a density of about 20 VM's per host for two hosts?
William Busby, PMP
.png)
