Storage access for specific VM on a Nutanix VMware edition | Nutanix Community
Skip to main content
We have a shiny new VMware NTNX environment, yeeh!



Question:

I'd like to be able to measure the virtual disk metrics for a specific workload (backup). Preferably without any layer in between so I can really see what the workload does.

Idea is to use a virtual machine on NTNX as a backup server and see what kind of parameters I use for the backup storage.

Is it possible to present a container on the CVM as an SMB share and write my backup on it? Or would it be best to use the Windows NFS client to access an export on the CVM?



Background:

I'd like to purchase a separate storage platform for the backups. But since I'm not really sure what kind of IO patern and throughput I need to sustain, I'd like to test and measure before we buy.
I'm not sure this is a supported scenario.The CVM (and the NDFS) is tailor made to host VMs (VMDK, VHD, etc.).It's not a regulat SMB/NFS server.While you may be able to store files this way onto a container, I would not expect to have them stored in way that will be relevant for a performance study.The NDFS take special measure to provide good performances to virtual disks, and storing something else will just confuse the system and may even break the carefully crafted Nutanix algorithms.For you needs I would use a regular server (or NAS) as storage target for a subset of the servers you wish to backup, then extrapolate the performance requirement.Sylvain.
So from a NTNX standpoint it would be best to use a VMDK or iSCSI container?



Doesn't the NTNX Hyper-V edition use SMB3 to present the strorage from the CVM?
If you want to store anything other than VM files on top of Nutanix, store it inside a VM that you will use as filer.If you want to access storage from another storage array, you can use iSCSI of NFS access from inside the guest to another storage array.



And yes, you are right, Nutanix support SMBv3 for Hyper-V, but again, only to store VMs, not user files or backup, etc.

Sylvain.