VM4.x offers dymanic lun resizing. vxdisk resize
- Original Message
From: Jarkko Airaksinen <[EMAIL PROTECTED]>
To: veritas-vx@mailman.eng.auburn.edu
Sent: Thursday, 29 March, 2007 12:33:20 AM
Subject: [Veritas-vx] resizing a device
Hello,
After one volume faile
>>> ess I pay for some extra license).
>>>
>> yes, between diskgroups is sticky. The easiest way is with the flashsnap
>> ($$) license.
>> But you can do it manually. However, you can't do it without causing
>> downtime for the
>> user.
>>
>
> Even with the license, I would still ex
> > # vxdg move cd_testdg01 cd_testdg02 cd_testvol01
> > VxVM vxdg ERROR V-5-1-4597 vxdg move cd_testdg01 cd_testdg02 failed
> > move failed : License has expired or is not available for operation
> >
> > I got as far as vxassist moving stuff from concat disks to one single
> > disk but then this l
Jarkko Airaksinen wrote:
> I think I can answer this myself...
>
> # vxdg move cd_testdg01 cd_testdg02 cd_testvol01
> VxVM vxdg ERROR V-5-1-4597 vxdg move cd_testdg01 cd_testdg02 failed
> move failed : License has expired or is not available for operation
>
> I got as far as vxassist moving stuff f
Hughes; [EMAIL PROTECTED]
Subject: Re: [Veritas-vx] resizing a device
Hey,
One more thing.
I would be moving data from file systems that are spread over two (or
more) disks in the group. Moreover I'd like to move the data from a disk
group to another.
I think the procedure would be some
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
e the data online
24/7.
I'll definitely use the 'vxassist move + vxresize' method instead.
Thanks, man!
-j-
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Doug
Hughes
Sent: jueves, 12 de abril de 2007 17:57
To: [EMAIL PROTECTED]
Subject: Re
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 another
> will require the same I/O regardless of the
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!
&
Jarkko Airaksinen wrote:
> 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 th
abril de 2007 19:18
To: [EMAIL PROTECTED]
Subject: Re: [Veritas-vx] resizing a device
> 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 in
> 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 occurs with EVA. When I move a
> dis
big
the temp disk must be? At least privlen?
-j-
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren
Dunham
Sent: jueves, 29 de marzo de 2007 19:03
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] resizing a device
> Actually my first
Hello,
The volume manager requires additional disk for two reason.
- Perform the operation online (without stopping application).
- Ensure data is not lost (parition and config data can get lost
making it difficult to access FS even though data is present.
As Daren says if you hav
> When you resize a lun on the array the only thing that changes from
> the host's perspective is the lun size. The device files do not
> change. To make the OS see the larger size you can select the disk in
> format and select "type" then "autotype" and that will relabel the lun
> with a vtoc refl
Airaksinen
Sent: Thursday, March 29, 2007 12:20 PM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] resizing a device
Hello,
Yeah I'm pretty sure that this is more an OS problem than a Veritas problem.
However the resize in OS has to be made before vxresize so I thought you
-Original Message-
From: Jeff Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 1:07 PM
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
Vx
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
> Actually my first live-and-learn experience with VVM was due to moving a
> disk back and forth between servers (fast, easy and dangerous way to
> move 4T of data);
Why dangerous? Deporting/importing disks to migrate data is a pretty
normal thing.
> the id's got mixed, VVM reported "already ini
-j-
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Dunham
Sent: miércoles, 28 de marzo de 2007 21:26
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] resizing a device
> You've got to resize the volume first and then resize
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
> With this scheme only the resizing is not yet solved. After resizing
> the disk in EVA I've tried 'vxresize', 'vxdisk resize' and 'vxfs/fsadm
> -b ' in the OS but no luck yet. Vxresize and fsadm fail because the
> LUN is still the old size in the OS and vxdisk resize fails because it
> wants to h
MAIL PROTECTED] On Behalf Of Darren Dunham
Sent: miércoles, 28 de marzo de 2007 21:26
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] resizing a device
> You've got to resize the volume first and then resize the filesystem. =
> vxresize should work.
True, but 'vx
> You've got to resize the volume first and then resize the filesystem. =
> vxresize should work.
True, but 'vxresize' does not resize the LUN, which is what the OP is
discussing. You have to either use dynamic lun resizing (VxVM 4.1 or
higher), or you have to fiddle around with things (remove t
You've got to resize the volume first and then resize the filesystem. vxresize
should work. Having said that, I have no idea what an EVA is?
-jrj
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarkko Airaksinen
Sent: Wednesday, March 28,
EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Doug
Hughes
Sent: Wednesday, March 28, 2007 10:40 AM
To: Jarkko Airaksinen
Cc: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] resizing a device
Jarkko Airaksinen wrote:
>
> Hello,
>
> After one volume failed in a concate
Jarkko Airaksinen wrote:
>
> 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 resi
27 matches
Mail list logo
