Is it possible to frig VxVM to get it to boot off a disassociated boot mirror?
nick.s...@gmail.com
then boot from the patched volume straight into Veritas. This would
save hours of downtime when patching. I don't want to use live upgrade
as I understand that this still boots into raw slices, so further
downtime is required to mirror up.
Surely there is a frig for this?
The company are looking at alternative volume managers that may be able
to do this if Veritas can't. Not sure about SDS or ZFS - if they can be
used.
Has anyone managed to do this?
Thanks,
Nick.
Darren Dunham
> In VxVM, I want to be able to split off a root mirror, patch it online,
> then boot from the patched volume straight into Veritas. This would
> save hours of downtime when patching. I don't want to use live upgrade
> as I understand that this still boots into raw slices, so further
> downtime is required to mirror up.
> Surely there is a frig for this?
'frig'?
I've done this many times, and the easiest way to do this is to ignore
VxVM. Don't split mirrors or run commands, because if you do that the
split off portions aren't immediately bootable.
My method is like this (only works if you can power or disconnect the
drives on the root mirror independently).
#1 shut down machine
#2 power off/remove/disconnect one side of mirror
#3 Boot machine (whines about missing disk, but boots)
Go only to single user and it won't try recovery procedures. That's
a nice place to do patches, also.
#4 patch. Evaluate patch. Decide what to do about mirrors.
Path A - patch okay.
#5A power on/reconnect drive.
#6A vxdctl enable to bring drive back to VxVM
#7A vxreattach (or vxdiskadm #1) to add disk back to group
#8A Verify mirrors have resynced. vxrecover if necessary. (If you are
in single user, go multi-user at this point and the vxrecover will
be run automatically).
Path B - patch not okay. Fall back.
#5B shut down machine.
#6B swap the connected drives. You *must not* have both drives be
visible to the OS at the same time yet. Simply booting from second
drive is not sufficient. It must not see the patched disk.
#7B Boot from the unpatched disk to single user
#8B Continue from step 5A. add disk, get recognized by VxVM, reattach
to disk group, recover (resync) volume.
> The company are looking at alternative volume managers that may be able
> to do this if Veritas can't. Not sure about SDS or ZFS - if they can be
> used.
ZFS isn't production and doesn't yet support booting.
SDS can do this, but you'd either have to do a temp boot during the
fallback path onto raw slices, or you'd have to create a new root
metadevice (possibly screwing up your nice numbering scheme) and
convince the other mirror to boot from it (I'm not sure how to do the
second part).
> Has anyone managed to do this?
Was a godsend on an E10000 once. Had patches that broke the system,
only had GE networks that weren't supported for jumpstart boots, and the
CDRom drive had been removed, so it was going to be a recable fest to
regain control if I truly hosed something. It let me test and retry the
patches on the system several times.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
nick.s...@gmail.com
But my company has 1000 remote Sun servers all currently with VxVM that
we patch every quarter, so I am looking for a solution that lets me
patch while a system is running, then do a single boot onto the patched
(still Veritased - I guess here is the miracle) disk to give minimal
downtime. So still searching I think...
Cheers,
Nick
nick.s...@gmail.com
Scott Howard
> In VxVM, I want to be able to split off a root mirror, patch it online,
> then boot from the patched volume straight into Veritas. This would
> save hours of downtime when patching. I don't want to use live upgrade
> as I understand that this still boots into raw slices, so further
> downtime is required to mirror up.
The answer is to throw out VxVM on your rootdisks, and use Live Upgrade.
You can even use Live Upgrade to migrate from VxVM to SVM with just a
reboot outage required.
With Live Upgrade what you're suggesting is trivial - create a new BE,
patch it, and then boot into it. Even better, the backout is also
trivial if something does go wrong.
With VxVM 4.x the need for rootdg has gone, and with it has gone the
last reason most people use encapsulated rootdisks.
Scott
nick.s...@gmail.com
Darren Dunham
> Thanks Darren,
You're not going to be able to have both the pre and post patch arenas
be bootable VxVM volumes. At least one of them needs to be a
non-volume.
Unless they've done something new in 4.x, you can only have one volume
in a disk group be bootable. So only one of your arenas can correspond
to a bootable volume.
You can unencapsulate the patched side. Assuming you weren't planning
on many patch failures, that's pretty straightforward and would require
minimal reconfiguration.
PRE PATCH
dissociate one side of mirror
Make sure all necessary slices are present for split-off disk
Mount split-off disk as a raw slice filesystem.
edit /etc/vfstab and /etc/system on split-off for non-volume root
unmount split-off disk
(optional: test boot from split-off disk)
PATCH
Patch successful:
reattach plex. Data is synced and you're done
Patch unsuccessful:
reboot from split disk. VxVM is active, but not associated with the
root volume.
Delete all root-disk volumes (you're not booted from them)
Encapsulate current root disk (will require reboots)
Re establish mirror
The reboots for this method mean that I wouldn't want to plan on it.
But if you're doing 1000 machines, I would hope that you don't have too
many failures. The short path for patch success makes this pretty
simple if your rollback rate is low.
ary...@spasu.net
> be bootable VxVM volumes. At least one of them needs to be a
> non-volume.
Yes, there is a Veritas infodoc about it:
http://seer.support.veritas.com/docs/275374.htm
However, one of my clients had a very intelligent script
that provided a volume split without detaching the plexes,
so that machine could have two bootable root volumes.
Can't remember exactly what the command was, probably something like
"vxdisk offline",
or some other crude thing that doesn't update the private region on a
disk(s) being sort of "detached" .
In a "no-go" afterpatch situation, machine would reboot to a
single-user mode
from a previously offlined disk, and the other submirror detached, and
attached again.
To make it even more reliable, this "no-go" detach after reboot can be
done by an early rcS.d script
that runs before rootvol is remounted RW.
Darren Dunham
> However, one of my clients had a very intelligent script
> that provided a volume split without detaching the plexes,
> so that machine could have two bootable root volumes.
> Can't remember exactly what the command was, probably something like
> "vxdisk offline",
> or some other crude thing that doesn't update the private region on a
> disk(s) being sort of "detached" .
Well, my suggestion of powering off a disk would do that, but I don't
know of many software ways that I would trust instead.
You could futz with /kernel/drv/sd.conf on each side of the mirror, but
I'm not sure how you'd update the non-active side. You wouldn't be able
to see the disk (both a good thing and a bad thing).
> In a "no-go" afterpatch situation, machine would reboot to a
> single-user mode
> from a previously offlined disk, and the other submirror detached, and
> attached again.
> To make it even more reliable, this "no-go" detach after reboot can be
> done by an early rcS.d script
> that runs before rootvol is remounted RW.
I'd be interested in understanding what the mechanism was.
nick.s...@gmail.com
vxdisk offline command sounds of interest - a command so it can all be
done remotely - detached but bootable - if you can remember the detail,
that would be great! Thanks, Nick.