Alta Vault Data Partition question

[georgel]

Hello Folks,

We are deploying AltaVault v-16 (16TB) Virtual Appliance and running into couple issues. First one, the back end storage for VM is Netapp NFS. But it seems that we are limited to 15.8TB max size on the file, this is according to Netapp Logical Storage guide for data Ontap 8.3.1 - max file size is 16TB. However, following NFS maximums we must subtract 1% as well. Bottom line max VMWare allowing to create 15.81 TB VMDK max. AltaVault recommends 20TB – VMDK size for 16TB model.
First question, how to add additional VMDKs into Data Partition config, is it possible at all?
Second issue, Alta Vault does not seem to recognize mounted data partition from second attached VMDK. VM has second disk attached but Storage Optimization Service keep saying: No data partition was found. Please shut down the VM and attach a second disk. This was done by the book, with VMDK created and attached before VM first time was booted. We even re-deployed appliance twice, to confirm. Is there a way to force rescan on attached disk to make it recognize VMDK? Command line options maybe?

Thanks in advance.
George

[chriswong]

Hi George,

Unfortunately, there is no way to add additional VMDK files to make up the difference in space - AltaVault only will use 1 additional disk volume currently. There is a well known ask to support multiple disk volumes at the product management level for exactly this reason (16TB limit on ONTAP), and it is planned for a future release.You'll unfortunately be a little undersized for this release, until the feature is placed into the product.

As for the issue of the VM not picking up the second disk during boot, I'm not sure why this is the case. When AltaVault boots, it should detect and mount the second disk as a part of the boot process. You can tell this happens because the first boot take a long time as it reads and formats the volume for use. I would suggest you open a support case if you can to diagnose the issue further, or look at the system log messages during the boot process (Reports > System Log).

Regards,

Christopher

[Glenn1]

I had this case on Sunday.

Checked /var/log/messages and confirmed the disk is being detected and attached to the appliance.

Here are the messages from my support call creating a 10GB Disk

sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:1:0: [sdb] 21474836480 512-byte logical blocks: (10.9 TB/10.0 TiB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Mode Sense: 61 00 00 00
sd 0:0:1:0: [sdb] Cache data unavailable
sd 0:0:1:0: [sdb] Assuming drive cache: write through

Not alot of data during boot up to work with here. http://stingray.corp.netapp.com/2006261725/sysdump-dc1vapavault1-20160425-093406/dmesg

Question, I noticed when the VM boots up vCenter reports the vmtools are not installed which makes sense. My suggestion to the customer was to use a RDM disk instead of VMDK thinking the passthrough disk would be managed by the storage layer on the appliance instead of abstracted through vmware.

Would RDM make a difference here ?

[georgel]

Hi Glenn, the documentation clearly states that we should be able to use VMDKs, RDM is not a requirement. RDM will have restrictions that are not acceptable to the proposed architecture. Thanks.

[ganwong]

Hi Christopher,

We are running into a similar situation with trying to increase our data cache to the full 16TB. Have there been any updates to the feature request? We would like to use as much of the Altavault local cache to keep slabs from being evicted before they can be deduplicated since cloud deduplication of evicted slabs isn't supported.

Thanks,

Gan

[chriswong]

Hi Gan,

AltaVault (now called Cloud Backup) had an End of Availability announcement made, and the CPC around the announcement is documented here. At this time, there are no further roadmap plans, since AltaVault will proceed into EOA at the end of CY2018. Sorry to bring you this news about AltaVault. Please note that support will still be provided for 5 years, through CY2023.

Regards,

Christopher