Sponsored Content
Operating Systems AIX Rebooting redundant VIOs and mirroring of PVs they serve to client LPARs Post 302968033 by maraixadm on Thursday 3rd of March 2016 11:08:21 AM
Old 03-03-2016
Rebooting redundant VIOs and mirroring of PVs they serve to client LPARs

need to confirm:
we have a system with two VIOs each serving a partition on a local disk to a client LPAR. That client LPAR has them both in a VG which is mirrored (exact). So each disk has a copy of the client LV that the client VG supports. This is the setup that was bequeathed to us by the vendors who set up the system originally, and which we've replicated to further systems.

I'm doing an upgrade cycle on the VIOs. If I reboot one of them after installing the upgrade, I would like
  1. the other VIO to continue serving its instance of the mirrored LV - don't see a reason to anticipate trouble with this
  2. when the rebooted VIO comes back, I expect the client LVM to deal with incongruities between the two copies of the mirrored LV appropriately.

#2 is my concern. What I read about mirror write consistency is that active MWC records writes in the MWC log and reaps that when the VG is varied back on, while passive MWC records that an LV has been opened, and forces a syncvg.

I'm trying to dig up how that applies when I shut down one VIO and thus make one of the client PVs supporting the mirrored client LV disappear for a while, then turn it back on and have it reappear in the mirrored VG. MWC is set to on/active for the mirrored LV.

Should I not worry because this is the correct configuration and this is what it was designed to support ?

Conversely, should I save myself the concern and drive risk to 0 by shutting down the client LPAR ? We have a maintenance window to work with; on the other hand it seems to me this is the kind of scenario that VIO redundancy was meant to address, so I shouldn't have to shut down client LPARs.

TIA...

---------- Post updated 03-03-16 at 11:08 ---------- Previous update was 03-02-16 at 18:09 ----------

well, it worked fine - no bobbles in the filesys

still interested in any views you may have of the above, tx
 

10 More Discussions You Might Find Interesting

1. IP Networking

to serve or be served??

I have two machines on my network - one OSX mac and one linux box. The mac is my main workhorse, and the linux box does occasional chores and webserving. Currently the mac shares (via NFS) files with the Liinux box. Would it be less demanding on the mac if I made it a client, and moved my files... (2 Replies)
Discussion started by: mistafeesh
2 Replies

2. AIX

rebooting vio client

Hi, I would like to reboot vio client but I am not able to access vio client(I am not able to get putty) , I am able to get putty of vio server, is there any command by using which from vio server I can reboot vio client? (3 Replies)
Discussion started by: manoj.solaris
3 Replies

3. AIX

DUAL VIOS & Client LPAR hangs at 25b3

I have a DUAL VIO ( IBM Virtual I/O ) setup on p 570. Two Vio server ( VIOS ) and many LPAR clients. VIO ( latest version + service pack + applied the fix ) and AIX 6.1 ML2 When both VIOs are running, and if I turn on a Client LPAR, the LPAR hangs at LED 25b3 for more than 1 hour then it... (2 Replies)
Discussion started by: filosophizer
2 Replies

4. HP-UX

How to Mirror LV and umirror after to change PVs...

Greetings Im running HP UX B 11.11 and Im not sure on how to do this request to "mirror current 5 LVs on vgSPAN to the new LUNs assigned to the VG and unmirror the LVs and finally return the 12 LUNs to SAN storage" The existing LVs were extended to accommodate a user request to extend 2 FS on... (3 Replies)
Discussion started by: hedkandi
3 Replies

5. AIX

VIOS IP address - separate vlan for vios servers ?

Hello, Lets say for simplicity that I do not use any vlan config inside my server - one lpar group use hea physical port1, another group hea physical port2. Physical port1 configured as vlan1 on external switch, physical port2 as vlan2. What is the common practice - should I isolate my vios... (0 Replies)
Discussion started by: vilius
0 Replies

6. AIX

Shared Disk in VIOS between two LPARs ?

is there any way to create shared virtual disk between two LPARs like how you can do it using Storage through Fiber on two servers ? Trying to stimulate HACMP between two LPARs (1 Reply)
Discussion started by: filosophizer
1 Replies

7. HP-UX

PVS command in HP-UX

Dear Engineer, Is there any command in HP-UX work similiar to PVS command in Linux? With Best Regards, Md. Abdullah-Al Kauser (4 Replies)
Discussion started by: makauser
4 Replies

8. UNIX for Advanced & Expert Users

Unable to install client AIX LPAR to vscsi hdisk provided from VIOS

Hi everybody, I have Power5 server with 4 internal hdisks each of 70Gb. VIOS server was installed via Virtual I/O Server Image Repository on the HMC. HMC release - 7.7.0 VIOS rootvg installed on 2 disk(these disks merged to one storage pool during VIOS install process),and 2 others hdisks... (2 Replies)
Discussion started by: Ravil Khalilov
2 Replies

9. AIX

Chef client on VIOs? How do you manage your VIO configs?

I know the VIOs are generally to be treated as an appliance and one should never drop down to oem_setup_env. In reality however, oem is a very useful tool to get the job done. So that leads me into the question of using the Chef client on a VIO. Currently a big push to manage all our *nix... (4 Replies)
Discussion started by: RecoveryOne
4 Replies

10. AIX

Need to replace a broken PV in a VIO VG used for client LPARs (and it won't release the old one)

I have a broken PV in a VIO VG that's used to support client LPARs using LVs. On the client LPAR, I reduced all PVs from the relevant client VG and thus deleted it. I.e. there is no client LPAR using the VIO VG. Yet when I try to reducevg the VIO VG, it complains that the LV hosted on the PV is... (2 Replies)
Discussion started by: maraixadm
2 Replies
lvextend(1M)															      lvextend(1M)

NAME
lvextend - increase space, increase mirrors for LVM logical volume SYNOPSIS
autobackup] le_number | lv_size | mirror_copies lv_path [pv_path ... | pvg_name ...] Remarks Mirrored disk operations require the installation of the optional HP MirrorDisk/UX software, which is not included in the standard HP-UX operating system. DESCRIPTION
The command can increase a logical volume's allocated extents, or increase its number of mirrored copies. Other logical volume characteristics can be modified with the and commands (see lvchange(1M) and lvreduce(1M)). To limit the allocation to specific physical volumes, specify the physical volume names as pv_path arguments or specify the physical volume group names as pvg_name arguments. Otherwise, all of the physical volumes in a volume group are available for allocating new physical extents. LVM always ensures that physical extent allocation can satisfy the current allocation policy or policies. If a physical volume is not suitable for use with a certain allocation policy, it is not used during physical extent allocation, even it is specified in a pv_path argument or indirectly in a pvg_name argument. The pvg_name argument is allowed only if one of the allocation policies of the logical volume is PVG-strict. Options and Arguments The option is only meaningful if the optional HP MirrorDisk/UX software has been installed. recognizes the following options and arguments: lv_path The block device path name of a logical volume. pv_path The block device path name of a physical volume. pvg_name The name of a physical volume group (see lvmpvg(4)). Set automatic backup for this invocation of this command. autobackup can have one of the following values: Automatically back up configuration changes made to the logical volume. This is the default. After this command executes, the command (see vgcfgbackup(1M)) is executed for the volume group to which the logical volume belongs. Do not back up configuration changes this time. Increase the space allocated to the logical volume, specified in logical extents. le_number is a decimal value greater than the current number of logical extents. le_number must be at least 1 and no greater than a volume group version-dependent maximum; use the command to determine the maximum number of logical extents for the volume group version. One, and only one, or option must be supplied. Increase the space allocated to the logical volume, specified in megabytes. lv_size is a decimal value greater than the current logical volume size. lv_size must be at least 1 and no greater than a volume group version-dependent maximum; use the command to determine the maximum logical volume size for the volume group version. lv_size is rounded up to the nearest multiple of the logical extent size, equivalent to the physical extent size defined for the volume group by the command (see vgcreate(1M)). One, and only one, or option must be specified. Set the number of mirror copies allocated for each logical extent. A mirror copy contains the same data as the original. mirror_copies must be at least 1 and no greater than a volume group version-dependent maximum; use the command to determine the maximum number of mirror copies for the volume group version. mirror_copies must be greater than the current value. Data in the new copies is synchronized unless the option is specified. The synchronization process can be time consuming, depending on hardware characteristics and the amount of data. One, and only one, or option must be specified. Do not synchronize the new mirror copies. This may affect data high availability so use or to synchronize the mirrors. The option must be specified along with this option. Striped Logical Volume considerations Striped and mirrored logical volumes are supported. An increase in size of a striped logical volume is done by increments of stripes logical extents. One increment corresponds to stripes physical extents if the volume is not mirrored or to stripes * (mirror_copies + 1) physical extents if the volume is mirrored. stripes is the number of disks the logical volume is striped across. It is set with the option stripes of the command. mirror_copies is the number of mirror copies allocated for each extent. It is set with the option of the and commands. LVM striped logical volumes are always allocated using the strict or PVG-strict allocation policies. Each physical extent of an increment is allocated on a different physical volume in the volume group. A size increase of a striped volume requires at least stripes (or stripes * (mirror_copies + 1) if the volume is mirrored) physical volumes with adequate free space and meeting the allocation policy. An increase of the number of mirror copies of a striped volume requires at least (stripes times the number of copies to add) physical vol- umes with adequate free space and meeting the allocation policy. Shared Volume Group Considerations For volume group version 1.0 and 2.0, cannot be used if the volume group is activated in shared mode. For volume groups version 2.1 (or higher), can be performed when activated in either shared, exclusive, or standalone mode. Note that the daemon must be running on all the nodes sharing a volume group activated in shared mode. See lvmpud(1M). If physical volume groups are passed as arguments, uses the physical volume group file of the system where the command is issued (the server). LVM shared mode is currently only available in Serviceguard clusters. EXTERNAL INFLUENCES
Environment Variables determines the language in which messages are displayed. If is not specified or is null, it defaults to "C" (see lang(5)). If any internationalization variable contains an invalid setting, all internationalization variables default to "C" (see environ(5)). EXAMPLES
Increase the number of the logical extents of a logical volume to 100: Increase the logical volume size to 400 MB: Allocate two mirrors (that is, two copies of the original) for each logical extent of a logical volume: Mirror a logical volume onto a particular physical volume. Allocate one mirror and do not synchronize the new mirror copy: Increase the size of a file system existing on a logical volume. First, increase the size of the logical volume. Unmount the file system. Extend the file system to occupy the entire (larger) logical volume. Remount the file system. WARNINGS
The creation of striped and mirrored logical volume(s) may prevent the import and activation of the volume group on an earlier HP-UX release. See lvcreate(1M) on the earlier release to see if it explicitly states that striping and mirroring is supported. If the striped and mirrored logical volumes of the volume group are removed or un-mirrored, the volume group becomes again compatible with the older HP-UX releases. SEE ALSO
lvchange(1M), lvcreate(1M), lvdisplay(1M), lvmadm(1M), lvmpud(1M), lvreduce(1M), lvsync(1M), pvchange(1M), pvdisplay(1M), vgsync(1M), intro(7), lvm(7). lvextend(1M)
All times are GMT -4. The time now is 04:08 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy