Active IQ Unified Manager Discussions
Active IQ Unified Manager Discussions
Hi,
Pardon me if this has ever come up before, but is it possible to mount a volume via NFS to the AIQUM VMware virtual appliance for AIQUM to place backups, instead of on it's own filesystem?
Solved! See The Solution
I used to run OVA UM back in it's "infancy", and I did just what you are asking about. We had to "break into" the instance due to company security policies, which was fine with me anyway. What I did, and what I still do for my "native Linux" installs that I rather rapidly switched to once they became available, was to NFS mount a filesystem to another path (as opposed to right on top of the UM backup path), then create a symlink from /opt/netapp/data/ocum-backup to the desired folder under the NFS mounted filesystem. If you so desire, there is nothing to prevent you from mounting said folder directly on top of this UM path, though I would be careful to delete or move its current contents since one you mount to it they will be hidden, not only making them inaccessible, but consuming local disk space needlessly. You will need to ensure that the UM "jboss" user can write to the NFS filesystem in order to ensure that this succeeds, and also ensure that there is plenty of free space since unfortunately the current backup process creates large files in that filesystem during the backup that then get compressed to create the backup, at which time the large files are (thankfully) deleted. I will be submitting an RFE at some point in the future to allow the specification of an alternate path for these temp files, as the biggest caveat of using an NFS-mounted filesystem to contain UM backups is that it takes a lot longer for the backup to complete. If the temp space was local and only the backup destination was NFS, the backup would be a whole lot faster.
I hope that this helps.
For Virtual application (vApp), the underlying operating system is locked, and there is no user access to the file system or to the operating system components. However, if the OCUM/AIQM binary is installed on Windows/Linux (Guest/Physical), user retains control of the operating system and therefore backup destination path can be defined as NAS path (CIFS/NFS).
You can mount a LUN or NFS share on the backup path (Not applicable to vApp) (Page-11)
https://www.netapp.com/media/13504-tr4621.pdf
I used to run OVA UM back in it's "infancy", and I did just what you are asking about. We had to "break into" the instance due to company security policies, which was fine with me anyway. What I did, and what I still do for my "native Linux" installs that I rather rapidly switched to once they became available, was to NFS mount a filesystem to another path (as opposed to right on top of the UM backup path), then create a symlink from /opt/netapp/data/ocum-backup to the desired folder under the NFS mounted filesystem. If you so desire, there is nothing to prevent you from mounting said folder directly on top of this UM path, though I would be careful to delete or move its current contents since one you mount to it they will be hidden, not only making them inaccessible, but consuming local disk space needlessly. You will need to ensure that the UM "jboss" user can write to the NFS filesystem in order to ensure that this succeeds, and also ensure that there is plenty of free space since unfortunately the current backup process creates large files in that filesystem during the backup that then get compressed to create the backup, at which time the large files are (thankfully) deleted. I will be submitting an RFE at some point in the future to allow the specification of an alternate path for these temp files, as the biggest caveat of using an NFS-mounted filesystem to contain UM backups is that it takes a lot longer for the backup to complete. If the temp space was local and only the backup destination was NFS, the backup would be a whole lot faster.
I hope that this helps.
RFE is best bet. Yes it *can* be done, but can and should are two different things.
If this feature is a deal breaker, discuss with account team.
I will definitely bring it up with them!
Ah-ha! This is what I suspected, but hadn't tried from the diag shell yet. Thank you!