VxVM vxdg Error - cannot be added to a CDS disk group ERROR V-5-1-6478

Issue

Not able to add a disk on shared disk group.
VxVM vxdg ERROR V-5-1-6478 Device disk_1 cannot be added to a CDS disk group


Solution:

You are not executing command on master node !

- Find which node is mater node
vxdctl -c mode

- Initialize disk
vxdisksetup -i disk_1

- Add disk is diskgroup

vxdg -g diskgroup_name adddisk   a_good_disk_name=disk_1


Isn't simple ?

Rehat satellite satellite-sync fails with ORA-00001: unique constraint (RHNSAT.RHN_PACKAGE_FILE_PID_CID_UQ) violated

Problem

Redhat satellite 5.4.1 satellite-sync fails while syncing of one software channel with below erroe

10:00:00    Importing *relevant* package metadata: rhel-some-channel-name (99)

SYNC ERROR: unhandled exception occurred:

(Check logs/email for potentially more detail)


(54, 'ORA-00001: unique constraint (RHNSAT.RHN_PACKAGE_FILE_PID_CID_UQ) violated\n', '\n     Package Upload Failed due to uniqueness constraint violation.\n     Make sure the package does not have any duplicate dependencies or\n     does not already exists on the server\n     ')

Solution

1- Enable debug in rhn.conf

# echo 'debug = 7' >> /etc/rhn/rhn.conf


2- Run satellite sync for failed software channel

# satellite-sync -c rhel-some-channel-name


3- See package ID causing issue in log - say package-id causing problem is 12345

# less /var/log/rhn/rhn_server_satellite.log


4- Take DB backup and delete package_id

sqlplus $(spacewalk-cfg-get default_db)
SQL > delete from rhnPackageFile where package_id=12345 ;
SQL > commit;
SQl> quit


5- Repeat steps 2,3,4 until satellite-sync for rhel-some-channel-name is complete.


6- Run full satellite sync

satellite-sync


It's rare issue. Did it help you?

Error V-3-20005 and V-3-24996 while mounting VVR replicated filesystem as read only on secondary

Are you getting below error when trying to mount Veritas VVR replicated volume on secondary in read only mode?

root@secondary ~]# mount -t vxfs -o ro /dev/vx/dsk/product_dg  /mnt
UX:vxfs mount.vxfs: ERROR: V-3-20005: read of super-block on /dev/vx/dsk/product_dg/product_vol failed: Input/output error
UX:vxfs mount.vxfs: ERROR: V-3-24996: Unable to get disk layout version


Solution

Error is misleading !

Check RVG status. Most probably it is in DISABLE state. volume group is an object of replicated RVG. If RVG is disable, even volumes are started (ENABLED), it is not usable.

root@secondary ~]# vxprint -rt |grep ^rv
rv product_rvg      1            DISABLED CLEAN    secondary 3        srl_vol

Actions

1- Start RVG

vxrvg -g product_dg start product_rvg


2- Verify if rvg is enabled

root@secondary ~]# vxprint -rt |grep ^rv
rv product_rvg      1            ENABLED CLEAN    secondary 3        srl_vol


3-Mount filesystem as read only . NOTE- it is not recommended to mount replicated volume in even read-only on secondary )

root@secondary ~]# mount -t vxfs -o ro /dev/vx/dsk/product_dg  /mnt
root@secondary ~]#


Did this post help you ?

Rename Veitas Shared Disk Group

How do you rename a shared disk group cfs_group_name configured under SFCFSHA ?

Assumptions:

- cfs_group_name is VCS cluster group importing DG on multiple nodes at same time.
- Shred filesystem is mounted on all cluster nodes in read-write mode

• Bring cfs_group_name offline on all nodes. Repeat below for each node

         hagrp -offline cfs_group_name -sys node1

• Confirm cfs_group_name is offline on all nodes

          hastatus -sum

• Fine out which node is master node

         vxdctl -c mode

• From master node, deport DG on one node. It will deport on on all other node

        vxdg deport old_dg_name

•     Import DG on master node with new name

    vxdg -n app_data_dg -s import old_dg_name ## -s == shared

• Update Veritas config file

           haconf -makerw
     hares -modify cvmvoldg1 CVMDiskGroup app_data_dg
     hares -modify cfsmount1 BlockDevice /dev/vx/dsk/app_data_dg/appvol
     haconf -dump -makero  ## it will update config on all nodes

• Bring cfs_group_name online on all nodes (repeat below on each node)

          hagrp -online cfs_group_name -sys node1

• Verify shared filesystem has been monted sucessfully and there is no error in log

           df -hP ; tailf /var/VRTSvcs/log/engine_A.log

• On related note : How to rename volume of shared disk group ?

   Offline colume resource, rename volume, change cluster config using hares -modify and bring resource online.


     /usr/sbin/vxedit -g  diskgroup rename oldname newname

Veritas Volume Replication - VVR - commands

To see primary and secondary replicated data set (RDS) details

    vradmin printvol
    vradmin -l printrvg

To see replication status

    vradmin -g dg_name -l repstatus rvg_name

To check free space in a DG

    vxdg -g dg_name free

To see basic RVG configuration including RVG roles and states, rlink names and states, data/srl volume names and states

    vxprint –ht 
    vxprint -Pl
   
To see current status of the rlink  - what mode its currently in, and how much data is currently being logged for the rlink (run on a primary node)

    vxrlink -g disk_group status rlink_name

To see how many messages secondary RVG is behind the primary (run on secondary)

    vxrlink -g disk_group -T updates rlink_name

To see extended statistics for the rlink such as how many blocks have been sent over the network, the round trip time, the current replication speed, any errors etc.

    vxrlink -g disk_group stats rlink_name


To displaying port numbers (ports should be identical on primary and secondary)

    /usr/sbin/vrport


To change port numbers (values stored persistently in /etc/vx/vvrports. Restart affected daemon)

    /usr/sbin/vrport daemon new_port_number 


To recover from SRL Overflow (dcm_logging flag shown on primary rlink). Performing a DCM replay will set rlinks to inconsistent until the replay is complete. As such good practice would be to create snapshots of data volumes on the secondary node before starting the replay (hence the cache/cachesize attributes for the vradmin resync command).

    vxrvg –g disk_group resync rvg_name   OR

    vradmin –g disk_group resync rvg_name [cache=cache_object|cachesize=size]

Extending Veritas Volume Replication Group and filesystem by adding a new disk

Let see how to add 1 TB disk in an existing Veritas RVG (Replicated Volume Group). Assume that there is only one secondary node.

(0) If you need to remove a volume to free up space, see article : 

Veritas VVR - removing a volume from VVR and deleting it from disk group

(1) Confirm Volume Group is replicating.

vradmin -g PrimaryHost_dg -l repstatus PrimaryHost_rvg # Check replication status

(2) Add 1 TB disk in dg on Primary host and confirm free space in dg

vxdisk scandisks  
vxdisk -e list     # Find new disk name - say it is new_disk1
vxdisk list new_disk1 # see detail of new disk
vxdisksetup -i new_disk1
vxdg -g PrimaryHost_dg adddisk PrimaryHost_disk_9=new_disk1  
vxdg -g PrimaryHost_dg  -u h free     # Check free space
vxassist -g PrimaryHost_dg maxsize     # Maximum possible extension (same as above)
vxprint -hrt -g SecondaryHost_dg -u g|grep -i ^v # Check RVG existing size


(3) Add 1 TB disk in dg on Secondary host and confirm free space in dg

vxdisk scandisks  
vxdisk -e list     # Find new disk name - say it is new_disk2
vxdisk list new_disk2 # see detail of new disk
vxdisksetup -i new_disk2
vxdg -g SecondaryHost_dg adddisk SecondaryHost_disk_9=new_disk2 
vxdg -g SecondaryHost_dg  -u h free # Check free space
vxassist -g SecondaryHost_dg maxsize # Maximum possible extension (same as above)
vradmin -g PrimaryHost_dg -l repstatus SecondaryHost_rvg # Check replication status
vxprint -hrt -g SecondaryHost_dg -u g|grep -i ^v # Check RVG existing size

(4) Pause replication, extend RVG and and filesystem, resume replication and verify it

vradmin -g PrimaryHost_dg pauserep PrimaryHost_rvg SecondaryHost-vvr.com   
vradmin -g PrimaryHost_dg resizevol PrimaryHost_rvg Volume_Name +g         
vradmin -g PrimaryHost_dg resumerep PrimaryHost_rvg SecondaryHost-vvr.com  
vradmin -g PrimaryHost_dg -l repstatus PrimaryHost_rvg # Check replication status
df -hP  # check filesystem size

Note: If you get following "WARNING: DCM log size is smaller than recommended due to increased volume size" in above step, you may do following:

  vxedit -g PrimaryHost_dg set srlprot=off  
  vxassist -g PrimaryHost_dg  remove log Volume_Nam
  vxassist -g PrimaryHost_dg remove log Volume_Name
  vxassist -g PrimaryHost_dg addlog Volume_Name logtype=dcm
  (vxassist will allocate the proper DCM size as per new volume size)

  vxedit -g PrimaryHost_dg set srlprt=dcm
Refer : https://support.symantec.com/en_US/article.TECH21427.html

ganglia : gmond, gmetad, ganglia-web

See how it looks : http://ganglia.wikimedia.org/latest/

Latest  download: http://ganglia.info