e already tried vxdisk rm'ing the weird disk and scanning disks again
but the datype persists. Then I took the disk completely from the
server's view from EVA, removed it from vvm and redid everything but the
datype still is XP10k..
Would you have any idea why this happen
t causing conflicts?
Thanks,
Jarkko Airaksinen
___
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Hello,
As we all know the Veritas DMP can handle almost all FC SANs without
using the HBA driver from the HBA provider.
However our tape drive doesn't work that way. I need to install the HBA
driver to be able to find the tape drives and then take backups through
the FC. The adapter is a QL
over functionalities that some
vendors have included in their HBA drivers.
Also, I have never heard that "DMP" would allow tape access, it is only used
as a failover / load balancing mechanism for disk I/O to veritas disk devices.
Greetings
seb
Quoting Jarkko Airaksinen <[EMAIL PR
same (Solaris 8) server? Any help / ideas would be
appreciated.
Br,
Jarkko Airaksinen
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarkko Airaksinen
Sent: lunes, 12 de marzo de 2007 19:02
To: veritas-vx@mailman.eng.auburn.edu
Subject
let you know of the results.
-j-
From: Robinson, Greg [mailto:[EMAIL PROTECTED]
Sent: miércoles, 21 de marzo de 2007 0:31
To: Jarkko Airaksinen; veritas-vx@mailman.eng.auburn.edu
Subject: RE: dmp + driver
Hi,
We use HBA's for tape and disk acce
Hello,
One volume failed in a disk group just a moment ago. On hardware level
everything seems quite; all the paths are ok, the SAN disk is online & well and
so on. No logs show a hardware failure.
However now i see this:
# vxdisk list
DEVICE TYPEDISK GROUP
Hello,
Looks like the guid has been lost.
Veritas support has suggested to make a vxdisk rm and vxdisk define on the disk.
Has anyone done this before? What is the risk with this operation?
-j-
De: [EMAIL PROTECTED] en nombre de Jarkko Airaksinen
Enviado
Hello,
After one volume failed in a concatenated file system I've been trying
to find a solution with no concats / raids in the OS at all, and rely
solely on the safety features of the EVA.
We can resize the LUN in the SAN easily as it's an EVA. Can I resize the
vxfs volumes in Solaris 8 as
Hello again,
I'm replying to all of you who replied in one single email so it's a bit long
:).
Maybe I'll explain a bit the logic of what I'm doing here. Here's what I had in
mind when designing the file systems:
1. Must not have a logical single point of failure that might affect several
fil
Hello,
Would you have any idea why the DMP doesn't share the load over all
paths that I have to a device (A-A array)?
I have the iopolicy set to adaptive (as recommended by oracle) with
use_all_paths=yes:
# vxdmpadm getattr enclosure EVA8 iopolicy
ENCLR_NAME DEFAULTCURR
This was meant for the whole world to see (and maybe learn something
from it :)).
-Original Message-
From: Jarkko Airaksinen
Sent: jueves, 29 de marzo de 2007 18:29
To: 'Darren Dunham'
Subject: RE: [Veritas-vx] resizing a device
Yeah but that's already a bit tedious. Also
From: Jeff Jones [mailto:[EMAIL PROTECTED]
Sent: jueves, 29 de marzo de 2007 19:07
To: Jarkko Airaksinen; Veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] resizing a device
I have not used the Dynamic LUN resizing that comes with the new versions of
VxVM, but have you used the appr
Back from vacations!
So, to answer Darren:
Dangerous because I destroyed one file system because of this :)! Well,
with the help of Veritas support in Germany we were able to restore the
other part of the concat and thus restore the file system intact.
Perhaps mixing the id's is a feature that o
Hello,
I've removed some disks from the server but they keep on coming back for
example after "vxdisk scandisks':
# vxdisk list
DEVICE TYPEDISK GROUPSTATUS
EVA8_1 auto:cdsdiskpt_dwhdg146_01 pt_dwhdg146 online
nohotuse
EVA8_3 auto:cdsdis
. However at times
only some (or none) of the paths disappear when I remove the disk.
I'll play with the driver a bit and see if I can disable them manually.
-j-
-Original Message-
From: Myers, Mike [mailto:[EMAIL PROTECTED]
Sent: miércoles, 11 de abril de 2007 18:56
To: Jarkko Airak
Yes, in a way it's present as I don't disconnect the whole SAN :). I just do
the normal device removal process (umount fs, remove volume from the disk group
etc) and finally unpresent it from the SAN.
What makes this odd is that sometimes the removal works just fine.
On a slow day when there's
pics:
1. Re: removing devices (Myers, Mike)
--
Message: 1
Date: Wed, 11 Apr 2007 09:56:23 -0700
From: "Myers, Mike" <[EMAIL PROTECTED]>
Subject: Re: [Veritas-vx] removing devices
To: "Jarkko Airaksinen" <[EMAIL PROTECTED]>,
&
Summary!
In case someone else is fighting with the same problems I thought I'd
share my conclusion with you.
I've decided not to resize the LUNS / file systems at all as Solaris 8
is quite restrictive with LUN resizing. I've overcome the need for
resizing them with a bit of thinking.
Given the v
e "no user impact" sounds quite tempting.
-j-
-Original Message-
From: Doug Hughes [mailto:[EMAIL PROTECTED]
Sent: jueves, 12 de abril de 2007 14:49
To: Jarkko Airaksinen
Cc: [EMAIL PROTECTED]
Subject: Re: [Veritas-vx] resizing a device
Jarkko Airaksinen wrote:
> Summary!
&
: [Veritas-vx] resizing a device
Jarkko Airaksinen wrote:
> Hello,
>
> I see your point. Which is faster, transferring the data between two
> separate file systems (i.e. over FC, ~210MB/s), or moving stuff within
> the same disk group? I'd imagine that moving data from a LUN to
anot
bject: Re: [Veritas-vx] resizing a device
Jarkko Airaksinen wrote:
> Hello,
>
> I see your point. Which is faster, transferring the data between two
> separate file systems (i.e. over FC, ~210MB/s), or moving stuff within
> the same disk group? I'd imagine that moving data fro
but then this license thing stopped me from moving volumes between
disk groups.
So, not doable (unless I pay for some extra license).
-j-
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jarkko
Airaksinen
Sent: viernes, 13 de abril de 2007 10:26
To: Doug
ssage-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: lunes, 23 de abril de 2007 23:22
To: Jarkko Airaksinen; Veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] removing devices
what kind of output do you get with?
# cfgadm -o show_FCP_dev -al
-Original Message-
Hello all Gurus out there,
Is there any way to add specific options when remounting a mounted file
system? Looks like I can remove them but not add.
For example I mount a file system with convosync=direct:
# mount -F vxfs -o convosync=direct /dev/vx/dsk/cd_testdg01/cd_testvol01
/data2/cd_t
Brilliant!
Thank you, Sir!
-jarkko-
-Original Message-
From: Myers, Mike [mailto:[EMAIL PROTECTED]
Sent: miércoles, 25 de abril de 2007 18:06
To: Jarkko Airaksinen; Veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] remount & add parameters
Try it this way:
moun
Hello,
I'm running SF5.0 on a sol8.
I installed the mp1 patch (sxrt5.0MP1_sol_5.0MP1) on Monday. After the
patching & rebooting something apparently went wrong; some devices went
to DISABLED state in the rootdg.
This is what vxprint -ht shows for rootdg:
dg rootdg default defau
Hello,
You're right, they were empty slices that had been there for a long time
and that Veritas support recommended to delete. The system has never had
a disk failure though so i don't know what might have caused this in the
first place.
Veritas support also recommended me to leave the rootdg01P
Very good reading.
Thank you, sir!
-j-
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren
Dunham
Sent: 24 May 2007 19:47
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] state DISABLED after patching
> Veritas support also recommended
Hello,
There's something odd going on with one of the 8 paths I use for my FC
disks. It's all the time 100% busy and has huge avg service times.
Here's an output of vsar:
Disk %busy %avg avque await aserv nrd avg nwr avg rd(k)
wr(k)
c5t50001 100.00 100.001.10.08.3
t worry myself senseless because of this though. If it works, don't
fix it.
-j-
From: robertinoau [mailto:[EMAIL PROTECTED]
Sent: miércoles, 30 de mayo de 2007 14:12
To: Jarkko Airaksinen; Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas
disconnected arrays from showing
in the list I rebooted the server a moment ago but they didn't
disappear.
Any idea how to get rid of them?
Br,
Jarkko Airaksinen
__
La informacion incluida en el presente correo
Hello,
After a short connection loss at the SAN I got some write errors and
this:
dg cd_data01dg default default 11175087864.68.mdr-cadmium
dm cd_data01dg01 c3t50001FE15005E90Dd9s2 auto 65536 629047040 NOHOTUSE
dm cd_data01dg02 c3t50001FE15005E90Cd8s2 auto 65536 20961664
: Ronald S. Karr [mailto:[EMAIL PROTECTED]
Sent: jueves, 09 de agosto de 2007 22:42
To: James Slater
Cc: Cronin, John S; Jarkko Airaksinen; Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] one slice failing
"Failing" is set when VxVM gets an unrecoverable I/O error from DMP.
Hello,
The only thing that wasn't automatic in my case was the recognition of the type
of the array, i.e. A-A, A/A-A-HP, A-P etc. In my case (A-A array) I had to
manually enable all paths to the luns. I did it when I changed the multipathing
scheme to adaptive with the 'use_all_paths=yes' switc
correct driver is pgtb, so fjgi1 works.
Usually editing path_to_inst is not recommended but I feel that it's the
only way I'd get fjgi0 working by removing the first and last fjgi lines
from path_to_inst and changing the fjgi instance from fjgi1 to fjgi0.
Has anyone done this kin
Whoops,
I was supposed to send this on another mailing list instead of the
veritas list.
My deepest apologies for the inconvenience it might have caused.
Br,
Jarkko
From: Jarkko Airaksinen
Sent: lunes, 01 de octubre de 2007 13:49
To
Hello,
I've never needed to reboot my SunOS server 5.8 Generic_117350-44 sun4us sparc
FJSV,GPUZC-M with VxVM 5.0, VxDMP & VxFS when adding new (SAN) disks.
If for some reason the new disks don't show in 'vxdisk list' after presenting
them to the server, all I need to do is 'vxdisk scandisks' t
Hello,
I'm running SF 5.0 on two identical servers. Last week in the other
server the VEA somehow stopped working. I can connect to the servers
with the VEA client but on the other server there are no subelements at
all (no actionagent, storageagent, vailagent).
The processes running on bot
12:54:47 pts/70:00 egrep pal|vxsvc
2. No, it's not.
-j-
From: Frank Currie [mailto:[EMAIL PROTECTED]
Sent: jueves, 17 de enero de 2008 16:45
To: Jarkko Airaksinen; veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] VEA issue
Hi
You're right about the 'vxassist move'. I'm running Veritas Storage Foundation
Standard 5.0 and I've done successful "vxassist move"s of 250G-500G disks
within a disk group. Trying to move across disk groups results in license
warning ('You don't have a license to run this program' or something
Hello,
I'm moving stuff from a subdisk to another with "vxassist move". I had
to abort the move once because it seemed that rman + vxassist move
killed our san box.
Now the target subdisk is 89% full, so I get this.
# vxassist -g cd_backup01_tbsdg move BACKUP01_TBS \!cd_backup01_tbsdg01
cd
immediately, hence my theory that vxdmp is treating the EVA as A/P (alua?)
instead of A/A.
How could I make vxdmp understand that the array is an A/A array?
Thanks,
Jarkko Airaksinen
___
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
http
enable, vxcondigd -k & restarting it, and another vxdctl
enable.
Any ideas how to proceed? Rebooting (if it would even help) is the last option
as this is a live server.
Thanks,
Jarkko Airaksinen
-Original Message-
From: veritas-vx-boun...@mailman.eng.auburn.edu
Hello,
I have an eva & qlogic23xx hbas as well.
In (quite) a few cases, after unpresenting & removing a disk I've had to use
luxadm to remove the c#t#d#s2 device paths in os level so that the rest can be
cleared with devfsadm -C. Here's a clip from some document I got from another
sol & vvm ad
45 matches
Mail list logo
