I'm currently setting up a test environment for VSM 7.5.1 and would like to deploy the media volumes on NFS. We've done this in the past by mounting an NFS datastore within VMware and building our VMDKs for the media volumes on that datastore. The OS disks are stored on FC datastores. In the next rendition, we expanded on this by linking all of the media volumes together in one LVM. This has all worked great, with a slight overhead with VMware/NFS resulting in a little latency, but the system is useable and stable. We would like to build on this further.
In our next rendition, we are trying to figure out how to attach an NFS mount directly to the media server for use as a media volume - effectively taking out any VMware overhead (as little as it may be) from the equation as far as the mount point is concerned. However, when we make our mount, the media server does not recognize it as a valid mount point. I'm assuming that this is because the system is looking for a partition labeled "media1" (or media#) instead of a folder "/media1", but I truly don't understand how the system decides what is a valid media volume and what is not, so that is a big assumption. I do know that mounting my NFS to the VM (and creating the fstab entry) is not enough to make it appear as a media volume in VSOM. In theory, writing directly to the NFS storage should be quicker than writing to an LVM based on VMDKs built in VMware on NFS storage.
Granted, this is not a supported configuration. [Cisco put this on our Christmas wish list. :) ] But we would still like to get this working as a proof of concept. Any ideas on how to bridge the missing link?
As far as I'm aware, the /mediaXX repositories are *required* to be an XFS based filesystem. This is why (from SuSE/RedHats perspective) the storage device needs to be a block device... so an XFS filesystem can exist on it.
Wish I had better news for you.
Bulletproof Solutions Inc.
Thanks for your reply. I decided to test your theory. Here's what I came up with. I mounted four media volumes as follows:
/media1 - a xfs partition labeled media1. Stored as a vmdk on an NFS datastore /media2 - an ext3 partition labeled media2. Stored as a vmdk on an NFS datastore. /media3 - a xfs partition labeled mymedia. Stored as a vmdk on an NFS datastore. /media4 - a NFS volume mounted directly to the media server.
All mount points were defined in fstab and were verified to connect on startup. VSOM saw all media volumes except for /media4. So, the system did not seem to care about about the partition label or the partition type, but it did want some type of block storage presented to RedHat - virtual or otherwise.
Interesting... so was the ext3 FS actually functional? I'll admit I haven't tried any media repo experimentation past 6.X, but I was fairly certain that it wouldn't leverage a filesystem other than XFS on a block dev.
Previously there was a file (/usr/BWhttpd/conf/system.cfg) that defined the repo's 'under the hood':
#----------------- PARTITION MOUNTS ------------------------ # usage: PARTITION:mount # example - PARTITION:/dev/hda3 # Define the partition mounts that will be used for archives. # Each mount must have it own PARTITION declaration. These # partitions mounts will be verified to see if the system has # mounted them during start up of IMS.
Good to know. Thanks for the feedback with your results in VSM7!
(Edit: My worry is that if the raw block dev is being referenced directly as in the original .conf config in 6.X, the ext3 FS that exists in your test case may initially appear functional, but the VSM recorder daemon (xvcr?) may make some assumptions about its structure that aren't necessarily correct? Could always try running it and filling it with some video data then stopping services, unmounting, and running a fsck against it?)
Bulletproof Solutions Inc.
I'll have to test that, too. I didn't make it past the point of verifying that the software saw the media volume from within the Server Configuration web page. I set the media volume to accept recordings, but didn't have a camera at the time to do a write. I'll find a camera soon and see if we can actually record. I'll let you all know the results. Thanks, Scott.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :