VxFS v6.0.01 Fails on RHEL 6.3
I am unable mount the VxVM volumes with VxDF file ystems on RHEL 6.3 (2.6.32-279.11.1.el6.x86_64). # rpm -q VRTSvxfs VRTSvxfs-6.0.100.200-RHEL6.x86_64 # mount /vol01 UX:vxfs mount.vxfs: ERROR: V-3-22168: Cannot open portal device: No such file or directory UX:vxfs mount.vxfs: ERROR: V-3-25255: mount.vxfs: You don't have a license to run this program # lsmod | grep vx vxspec 3366 8 vxio 3763980 1 vxspec vxdmp 408656 5 vxspec,vxio # ls -la /dev/vxportal ls: cannot access /dev/vxportal: No such file or directory I have installed the latest patch available. Please help. Thanks RamasshSolved2.4KViews3likes10CommentsMigrating to a new SAN
We're in the process of moving to new datacenters. All servers will be moved over but the SAN won't. The SAN will be replicated to a new SAN in the new datacenters by our SAN admins. That means, the LUNs in the new SAN will be identical to the old, also the LUN numbers. Example output from'vxdisk list' on the current host shows: c1t50050768014052E2d129s2 auto:cdsdisk somedisk01 somedg online This disk will get same LUN nr, but the target name will probably differ as it's new hardware in the new DC. Will this work with Veritas SFHA? If not, is there any way to do this the way the datacenter project wants to? If I could choose to do this my way, I would presentthe LUNs on the new SANto my servers so that I could do a normal host based migration. Add the new LUN to the diskgroup and mirror the data, then remove the old LUN. However, I'm told that the hosts in the current datacenter won't be able to see the new SAN.Solved2.2KViews2likes3CommentsRUNQ values increased after upgrade to SFHA 6.1/RHEL5
Hi all, IHAC who has upgraded their SF HA 6.1 on RHEL 5 and noticed their RUNQ increased four times (0.1 avg to 0.4 avg). AFAIK, nothing has been changed during the upgrade. I'm wondering if it's an isolated case or expected behavior?Solved873Views1like3CommentsVersions of Veritas Volume manager
I am running Verias Volume manager on HPUX, version is B.05.10.01. There is embedded java that is version 1.6.0.06. Is there a more recent version that would bump up my Java to a higher version? Thanks Also, removing the embedded java would work.Solved2.3KViews1like6Comments5.1 PS1 new install on Sparc 9 VxVM4.0 MP1host having SFDB2
We are upgrading a Solaris 9 Sparc 64 bit using SFDB2 from VxVM 4.0 MP1to 5.1SP1 using DMP. From what I understand this is a new install not upgrade. EMC has remediated that VxVM is not at the expected level. We are moving from CX to VMAX.I will be editing the sd.conf and lpfc.conf accordingly. It will be an array based migration FTS. I was wondering can we just upgrade the VxVM from the CD or do we have to uninstall/install everything (all of SFDB2). If we do, then can you help me with these steps for expediency. Here are my steps: 1) vxvm config - vxprint -th (readable format) and vxprint -m (detailed attributes) save old attributes. 2) Unmount all the VxFS mounted filesystems 3. Stop all volumes and deport db2dg. 3) vxdctl stop ( to stop vxconfigd ) 3a.) mount CD with install pkgs; copy VRTS* pkgs to /tmp/veritas_5.1install dir 4) pkgrm VRTSfsman VRTSvmman VRTSvxfs VRTSvxvm VRTSvlic - old version 5) pkgadd VRTSvlic VRTSvxvm VRTSvxfs VRTSvmman VRTSfsman - new version 6) Reboot the server 7) Do SF Veritas patching showrev -p | grep 114477-04 & (122300-10 for SF&SFDB2 only) 8) Final reboot. 9) mount filesystems 10) import db2dg 10a.) use vxupgrade to upgrade the filesystem disk layout version from version 4 or 5 to -> 6 11.) vxddladm listsupport all (libvxemc.so (EMC SYMM support) should be listed because it was embedded in install (confirm)Solved972Views1like2CommentsVeritas Cluster addition
Hi All, In our environment we are having 8 node Veritas cluster sharing a Filesystem in all servers, and now we have request to add 8 more nodes to the existing cluster. So please provide the steps as well the best way to complete the setup. Thanks Rajini Nagarajan698Views1like2CommentsSF 6.0 does not recognize SF 4.1 Version 120 simple disk?
I am currently preparing to exchange two old SLES 9 systems by new SLES 11 machines. These new ones have SF 6.0 Basic and are able to see and read (dd) the disks currently being in production by the SLES9 systems (SAN FC ones). The disks are Version 120 originally created and in use by SF4.1: # vxdisk list isar1_sas_2 Device: isar1_sas_2 devicetag: isar1_sas_2 type: simple hostid: example4 disk: name=isar1_sas_2 id=1341261625.7.riser5 group: name=varemadg id=1339445883.17.riser5 flags: online ready private foreign autoimport imported pubpaths: block=/dev/disk/by-name/isar1_sas_2 char=/dev/disk/by-name/isar1_sas_2 version: 2.1 iosize: min=512 (bytes) max=1024 (blocks) public: slice=0 offset=2049 len=33552383 disk_offset=0 private: slice=0 offset=1 len=2048 disk_offset=0 update: time=1372290815 seqno=0.83 ssb: actual_seqno=0.0 headers: 0 248 configs: count=1 len=1481 logs: count=1 len=224 Defined regions: config priv 000017-000247[000231]: copy=01 offset=000000 enabled config priv 000249-001498[001250]: copy=01 offset=000231 enabled log priv 001499-001722[000224]: copy=01 offset=000000 enabled # vxdg list varemadg | grep version version: 120 But when I look in the new systems SF6.0 does not recognize the diskgroups at all: # vxdisk list isar1_sas_2 Device: isar1_sas_2 devicetag: isar1_sas_2 type: auto info: format=none flags: online ready private autoconfig invalid pubpaths: block=/dev/vx/dmp/isar1_sas_2 char=/dev/vx/rdmp/isar1_sas_2 guid: - udid: Promise%5FVTrak%20E610f%5F49534520000000000000%5F22C90001557951EC site: - When I am doing a hexdump of the first few sectors it looks pretty much the same on both machines. According to articles like TECH174882 SF6.0 should be more than happy to recognize any disk layout between Version 20 and 170. Any hints what I might be doing wrong?Solved4.6KViews1like18CommentsAnnouncing Storage Foundation High Availability Customer Forum 2012
We are excited to announce Storage Foundation High Availability Customer Forum 2012, a free learning event by the engineers for the engineers. Registration is open, register now to get on the priority list. The forum will take place at our Mountain View, CA offices on March 14th and 15th 2012. Join your peers and our engineers for two days of learning and knowledge sharing. The event features highly technical sessions tohelp you get more out of your days. Learn and share best practices from your peers in the industry and build a long lasting support network in the process Become a Power User by significantly increasing your troubleshooting and diagnostic skills as well as your product knowledge Engage with the engineers who architected and wrote the code for the products Please see here for event agenda and sessions details. More questions? See our events page.676Views1like0CommentsEOSS for Veritas File System 5.0 MP3 RP3
We have been encouraged to upgrade from VFS 5.0 MP3 RP3 to VFS 5.1 SP1 RP1. This is going to be a costly upgrade, so we are trying to determine the best time to do this. We are trying to find out the end of support for VFS 5.0 MP3 RP3 on the Symantec web site with no success. Does anyone know the EOSS for this product? Thanks...vwSolved1.2KViews1like6Comments