Archive for February, 2010
I came across this error after setting up and FlexVolume on a Netapp filer and trying to connect to it from vSphere ESX host.
I had run through the wizard and made sure that each of the ESX hosts had read/write access as well as “Root” access to the export/volume but I continued to get this error:
“Error during the configuration of the host: Cannot open volume: /vmfs/volumes/270c64e8-cae0114b”
Originally I thought it may be that I had underscores in my export name as described in the Vmware KB article. I changed the export name to something without an underscore but still no dice.
It turns out even if you specify Unix security when creating the export, the Netapp filer will create it using NTFS by default! Why it sets the underlying security to NTFS on a NFS export with Unix security is beyond me. It may be the version of OnTap on our old dev filer (184.108.40.206)
To change this you need to do the following:
- Logon to your filer web management interface
- Expand “Volumes”
- Expand “Qtrees”
- Click “Manage”
- Click on the “NTFS” link next to the export you need to change
- Change the security style to “Unix” and then apply
- Go back to your host and try adding the NFS volume
I recommended getting familiar with this Netapp and vSphere best practices document as well.
I have been meaning to take a look at the EMC Rainfinity product for a long time now but never got around to it. EMC have now released it as a virtual appliance which you can get from Chad’s site here. The link also provides info on the product as well as installation steps.
The VE edition is free for non production use but there is a paid version that could be a great solution for SMB clients who have data archiving requirements if the price is right. The biggest benefit I see for SMB clients is reducing the amount of data that needs to be backed up.
I’m not sure what targets and destination storage it is able to work with just yet but after having a play with it I will post again with my findings.
Detailed info of the following best practice round up can be found here.
- The SMVI server component should be installed on the vCentre server
- Transient data such as the guest operating system swap file, temp files and page files, should be moved to a separate virtual disk on a separate data store to prevent large snapshots due to high rate of change
- Set vDisks that house temp/transient data to “Independent Persistent” to ensure SMVI does attempt to snap the volume that that vDisk resides on
- Licences required for SMVI
- Any required NFS, iSCSI FC protocol licenses
- When vCentre is installed on a VM the database associated with vCenter must not be installed on a virtual machine protected by SMVI to avoid time out issues. Where possible use a physical SQL server for vCenter
- It is recommended to configure data store level backups instead of VM backups where possible to reduce admin overhead and increase restore options.
- SMI .XML configuration files need to be on shared storage or backed up often to allow for recovery
- Set the Startup of the SMVI to Manual if you do restore vCenter from an image level backup. Important because
“When the virtual machine running SnapManager for Virtual Infrastructure is backed up by SMVI, the current state of the SMVI backup workflow is captured within the Snapshot copies. Should the virtual machine be restored at a later date, SMVI within the virtual machine assumes that the host has failed in mid-workflow and attempts to resume backups at the point at which the Snapshot copy was taken. This can cause backups to run multiple times even if they were originally successful.”
- After a restore of the SMVI vm remove the contents of the PROGRAMFILES%\NetApp\SMVI\server\crash directory and start the SMVI service
- If Vmware In an environment experiencing heavy disk I/O this will greatly increase both the speed and success rate of backups. This will result in crash consistent backups only which is generally only an issue for databases or e-mail servers.
- If a VM requires an RDM ( a requirement to use SnapDrive for SQL) it should be configured in physical mode. This will enabled the non RDM virtual disks (ie system partition) to be backed up using the vmware tool VSS integration.
- Create a separate storage admin account for SMVI to interact with the filer (don’t use the root account)
- Enable and use SSL on the filer to ensure passwords are encrypted