Backup of system disk through Command View EVA snapclone

[Ana M. García Olivencia]

Hi all.

I was wondering if it's possible to backup an OpenVMS system disk making a snapclone through Command View. The versions are:

OpenVMS 8.3 with the latest patches.
Command View 7.00.01

The steps I've followed are:

1. Shutdown of the system.
2. Make a snapclone of the system disk.
3. Make the snapclone bootable through the writeboot utility.
4. Boot from the snapclone disk. At the beginning it seems ok but a warning message appears and, at the end, a bugcheck follows. These are the messages:

********************************
P00>>>b
(boot dga1.1001.0.4.0 -flags 0)
kgpsaa0.0.0.4.0 Link is down.
block 0 of dga1.1001.0.4.0 is a valid boot block
reading 1226 blocks from dga1.1001.0.4.0
bootstrap code read in
base = 200000, image_start = 0, image_bytes = 99400
initializing HWRPB at 2000
initializing page table at 1f2000
initializing machine state
setting affinity to the primary CPU
configuring I/O adapters...
ncr0, hose 1, bus 0, slot 1
isp0, hose 1, bus 0, slot 3
isp1, hose 1, bus 2, slot 0
floppy0, hose 0, bus 1, slot 0
pks0, hose 0, bus 0, slot 3
kgpsa0, hose 0, bus 0, slot 4
tulip0, hose 0, bus 0, slot 5
jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.3
� Copyright 1976-2007 Hewlett-Packard Development Company, L.P.


%SMP-I-SECMSG, CPU #01 message: P01>>>START
%SMP-I-CPUTRN, CPU #01 has joined the active set.
%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port

%DK-W-PORT_WAIT, Waiting for port


**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****

** Bugcheck code = 0000019C: INCONSTATE, Inconsistent I/O data base
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: VSCI0
** Supported CPU count: 00000004
** Active CPUs: 00000000.00000003
** Current Process: SWAPPER
** Current PSB ID: 00000001
** Image Name:


**** Starting compressed selective memory dump at 15-JAN-2009 10:21...
................
...Complete ****

halted CPU 0

halt code = 5
HALT instruction executed
PC = ffffffff80087b24

CPU 0 booting

(boot dga1.1001.0.4.0 -flags 0)
.........

*****************************

I have been looking for this error (PORT_WAIT) but I haven't found anything.

Any advice will be very appreciated.

Thanks in advance.

Regards.

Ana

[Jon Pinkley]

Ana,

A snapclone is an identical copy of the original disk. So yes it is possible to make a backup with a snapclone. I.e. it is equivalent to a backup/physical to another disk.

I am not sure why you used writeboot; as long as the original disk was bootable, the snapclone will be (assuming wwidmgr has made the device available to SRM).

Are you booting the snapclone on the same machine or some other Alpha?

Jon

[Ana M. García Olivencia]

Jon.

I used writeboot because, although I haven't told you before, the first time after making the snapclone, I booted the snapcloned disk WITHOUT executing the writeboot utility, and with the same error message. Thinking that this could be the reason, I executed the utility, but with the same result.

And, yes, I am booting from the same system (it's a test system).

Thanks.

Ana

[Jon Pinkley]

Ana,

Was the snapclone presented with the same o/s unit id, or did you present it using a different one. I.e. was the original system disk $1$dga1 or was it something else?

Did you use wwidmgr so SRM is seeing the new device?

If it is a test system, here is what I would try.

P00>>>wwidmgr -clear all
P00>>>wwidmgr -quickset -udid 1

If you have dump off system disk, then you need to use quickset to that unit too
P00>>>wwidmgr -quickset -udid P00>>>init
P00>>>b

Jon

[Ana M. García Olivencia]

Jon.

The original system disk is presented as os_unit_id 1; the snapclone disk is presented as os_unit_id 4444, and these setting have not been changed during the tests. Os_units_id 8883, 2 and 9999 below have nothing to do with this topic.

At console, each time I booted from the snapclone disk, I have followed these steps:

***********************************
P00>>>wwidmgr -clear all

P00>>>init

P00>>>wwidmgr -show wwid
[0] UDID: 1 WWID:01000010:6005-08b4-0006-cb32-0000-c000-01f5-0000 (ev:none)
[1] UDID:8883 WWID:01000010:6005-08b4-0001-1e88-0000-a000-037a-0000 (ev:none)
[2] UDID: 2 WWID:01000010:6005-08b4-0006-cb32-0000-c000-0217-0000 (ev:none)
[3] UDID:9999 WWID:01000010:6005-08b4-0006-cb32-0000-c000-0204-0000 (ev:none)
[4] UDID:4444 WWID:01000010:6005-08b4-0006-cb32-0000-c000-021d-0000 (ev:none)

P00>>>wwidmgr -quickset -item 4 -unit 1

Disk assignment and reachability after next initialization:


6005-08b4-0006-cb32-0000-c000-021d-0000
via adapter: via fc nport: connected:
dga1.1001.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebd8 Yes
dga1.1002.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebdc Yes

>>>init

>>>show bootdef_dev
bootdef_dev dga1.1001.0.4.0 dga1.1002.0.4.0

>>>boot

(The messages you know)

***************************************

When I want to boot from the original system disk, I repeat the same steps but this time, the command I execute is:

.....
P0>>>wwidmgr -quickset -item 0 -unit 1
....

and all works ok.

Thanks.

Ana

[Martin Vorlaender]

Ana,

>>>
[4] UDID:4444 WWID:01000010:6005-08b4-0006-cb32-0000-c000-021d-0000 (ev:none)

P00>>>wwidmgr -quickset -item 4 -unit 1
<<<

AFAIK, the unit number and the UDID must be the same for VMS. So, try it with '-unit 4444'.

>>>
When I want to boot from the original system disk, I repeat the same steps but this time, the command I execute is:
.....
P0>>>wwidmgr -quickset -item 0 -unit 1
....

and all works ok.
<<<

...because unit number and UDID are the same.

HTH,
Martin

[Uwe Zessin]

How about:

>>>> wwidmgr -quickset -udid 4444

[Jon Pinkley · Accepted solution]

Ana,

Can you back up and give us a bit of info about the purpose of the "backup"? Is it so you will have a fallback position for an upgrade, for testing something, etc?

Short answer: The o/s unit id must match the unit number device name you boot from at the SRM >>> prompt.

In other words: if the following is true

6005-08b4-0006-cb32-0000-c000-021d-0000
via adapter: via fc nport: connected:
dga1.1001.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebd8 Yes
dga1.1002.0.4.0 kgpsaa0.0.0.4.0 5000-1fe1-500f-ebdc Yes

>>>init

>>>show bootdef_dev
bootdef_dev dga1.1001.0.4.0 dga1.1002.0.4.0

>>>boot

Then the o/s unit id associated with vdisk with wwid 6005-08b4-0006-cb32-0000-c000-021d-0000 must be 1. If it is not, you will see the bugcheck.

You have two options:

1. If it is important to maintain the same physical device name $1$DGA1:, then you need to unpresent the original disk (I like to change the o/s unit id as well, although I don't know that it is a requirement as long as it is not presented). Then create a snapclone specifying 1 as o/s unit id. After the snapclone copy starts, you can present the vdisk to the VMS host. I don't think you will be able to change the o/s unit id until the copy operation completes. You will need to run wwidmgr to associate the new wwid with the udid (I am pretty sure udid == o/s unit id, is that correct Uwe?) Then boot as usual. This operation is analogous to putting a different CD in the same drive.

2. If you aren't in a cluster or using DOSD (dump off system disk), then you should be able to make all your operations "physical disk name independent" and "system disk label name independent" by using names like sys$sysdevice instead of $1$DGA1: or DISK$APLHASYS:. Then after presenting the snapclone vdisk, run wwidmgr to associate the new o/s unit id with the device unit, and boot form the new device name. for example:

>>> wwidmgr -quickset -udid 4444
>>> init
>>> show dev dga
>>> b dga4444.whatever show device displayed

Alternatively set SRM environment variable bootdef_dev to dga4444... and >>>b

Good luck,

Jon

[Robert Atkinson]

I though VMS had problems with presented unit numbers above 255?

Rob.

[Uwe Zessin]

I think that that was a limitation on CI.

It's quite common to have a served device like $1$DKA500 or $1$DGA301.