On 30.05.2017 20:53, Mauro Souza wrote:
Try vmcp detach 1234 (if your dasd is 1234). It "physically" detaches the
device from the guest, so vgscan should lose track of it.
But please, before detaching the device from z/VM set the device offline
in Linux using chccwdev -d or whatever tool
On 05/30/2017 02:50 PM, Marcy Cortes wrote:
> Did you do a "vgreduce VGname /dev/dasd*"
>
> If you missed that step, you can probably fix it with "vgreduce
> --removemissing VGname"
Hi Marcy,
Yes, I did that followed by pvremove on each device.
> You'll want to get rid of them from linux too if
Try vmcp detach 1234 (if your dasd is 1234). It "physically" detaches the
device from the guest, so vgscan should lose track of it.
On May 30, 2017 15:48, "Jorge Fábregas" wrote:
> Hi,
>
> We have a situation with two SLES11 servers. We had to migrate the
> underlying PVs used for the swap log
Did you try chccwdev -d xxx (xxx is the virtual address)?
Scott Rohling
On Tue, May 30, 2017 at 11:46 AM, Jorge Fábregas
wrote:
> Hi,
>
> We have a situation with two SLES11 servers. We had to migrate the
> underlying PVs used for the swap logical volume (we used pvmove to move
> fr
Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Jorge
Fábregas
Sent: Tuesday, May 30, 2017 11:47 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Remove DASD device
Hi,
We have a situation with two SLES11 servers. We had to migrate the underlying
Hi,
We have a situation with two SLES11 servers. We had to migrate the
underlying PVs used for the swap logical volume (we used pvmove to move
from DASD to FCP LUNs) and then we removed the DASD PVs from the volume
group (followed by pvremove on them to wipe LVM metadata). After that I
called m
