Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

VSM 7.5 on NFS

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?

Thanks,

Jonathan

4 REPLIES
Silver

As far as I'm aware, the

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.

Scott Olsen Solutions Specialist Bulletproof Solutions Inc. Web: www.bulletproofsi.com
New Member

Scott,Thanks for your reply.

Scott,

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.

Silver

Interesting... so was the

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!

Cheers :-)

(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?)

 

Scott Olsen Solutions Specialist Bulletproof Solutions Inc. Web: www.bulletproofsi.com
New Member

I'll have to test that, too.

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.

135
Views
15
Helpful
4
Replies
CreatePlease to create content