Unsolved
This post is more than 5 years old
12 Posts
0
731
HPVM and open replicator
Hi, folks, it seems there's not many people out there that use HPVM but maybe the forums will surface an answer.
I've used Open Replicator (OR) successfully for migrating from one array to another and want to use it for some new HPVM hosts. In HPVM, the host is the physical host that owns the HBA and luns. This host then creates guests VMs, which act like your typical VM. For all intents and purposes, both the host and its guests run HPUX, at least in our environment.
When you create a guest, you give it an entire lun. There's other ways to pass the storage up to the guest but they're irrelevant to my post so I won't bore you. So, host creates a guest VM and gives it an entire lun. As an example, the host ioscan sees symdev 100 as c5t3d2. It gives guest os "guest1" access to c5t3d2. When you do this, you must specify the scsi address that the guest should see. Let's say we specify 0,0,0. If you telnet to the guest and do ioscan -fnC disk, you'll see a disk at c0t0d0. As you can see, the host has the accurate picture of the storage while the guest just sees what it's told to see.
Assume further that the guest OS has been installed onto symdev 100. Since this is IA64 and not PA-RISC, that lun is partitioned into 3 slices. Don't ask; that's just what happens to a boot drive in HPUX on Itanium. So now, an ioscan -fnC disk at the host reveals c5t3d2, as well as c5t3d2s1, c5t3d2s2, and c5t3d2s3. The "s#" reflects the partitions created as part of the install.
We need to migrate off this array for tech refresh, so we have to migrate data from symdev 100 to a lun on another array, say symdev 200 and the ctd is c8t0d0. We use Open Replicator, which has worked great in the past, but we run into a glitch. Here's what we do in a nutshell:
1) Give host access to symdev 200; ioscan; insf
2) shut down guest
3) use hpvmmodify to tell the guest its c0t0d0 device now points to c8t0d0 (symdev 200)
4) modify masking to remove host access to symdev 100
5) symrcopy ¿file or_file ¿hot ¿pull ¿copy create; symrcopy ¿file or_file activate
6) start up guest
The problem we run into is in step 6. If you look at the console while the guest is starting up, it shows that it gets into the EFI ok (this is equivalent to the ISL in PA-RISC). It shows that the primary boot path 0/0/0/0.0.0 (in other words device c0t0d0). When it tries to run ¿hpux¿, it errors out with ¿Cannot open device 0x000002¿. Then it restarts itself.
An ioscan at the host shows c8t0d0 is there but no s1, s2 or s3. We believe this is the crux of the problem. The host does not see the partitions, even though Open Replicator brought them over. We tried running ioscan again. We tried removing the c8t0d0 device files and re-running insf -e. None of this got the host to recognize the partitions on c8t0d0.
Anybody run into this before or have any ideas?
Thanks in advance,
stc
I've used Open Replicator (OR) successfully for migrating from one array to another and want to use it for some new HPVM hosts. In HPVM, the host is the physical host that owns the HBA and luns. This host then creates guests VMs, which act like your typical VM. For all intents and purposes, both the host and its guests run HPUX, at least in our environment.
When you create a guest, you give it an entire lun. There's other ways to pass the storage up to the guest but they're irrelevant to my post so I won't bore you. So, host creates a guest VM and gives it an entire lun. As an example, the host ioscan sees symdev 100 as c5t3d2. It gives guest os "guest1" access to c5t3d2. When you do this, you must specify the scsi address that the guest should see. Let's say we specify 0,0,0. If you telnet to the guest and do ioscan -fnC disk, you'll see a disk at c0t0d0. As you can see, the host has the accurate picture of the storage while the guest just sees what it's told to see.
Assume further that the guest OS has been installed onto symdev 100. Since this is IA64 and not PA-RISC, that lun is partitioned into 3 slices. Don't ask; that's just what happens to a boot drive in HPUX on Itanium. So now, an ioscan -fnC disk at the host reveals c5t3d2, as well as c5t3d2s1, c5t3d2s2, and c5t3d2s3. The "s#" reflects the partitions created as part of the install.
We need to migrate off this array for tech refresh, so we have to migrate data from symdev 100 to a lun on another array, say symdev 200 and the ctd is c8t0d0. We use Open Replicator, which has worked great in the past, but we run into a glitch. Here's what we do in a nutshell:
1) Give host access to symdev 200; ioscan; insf
2) shut down guest
3) use hpvmmodify to tell the guest its c0t0d0 device now points to c8t0d0 (symdev 200)
4) modify masking to remove host access to symdev 100
5) symrcopy ¿file or_file ¿hot ¿pull ¿copy create; symrcopy ¿file or_file activate
6) start up guest
The problem we run into is in step 6. If you look at the console while the guest is starting up, it shows that it gets into the EFI ok (this is equivalent to the ISL in PA-RISC). It shows that the primary boot path 0/0/0/0.0.0 (in other words device c0t0d0). When it tries to run ¿hpux¿, it errors out with ¿Cannot open device 0x000002¿. Then it restarts itself.
An ioscan at the host shows c8t0d0 is there but no s1, s2 or s3. We believe this is the crux of the problem. The host does not see the partitions, even though Open Replicator brought them over. We tried running ioscan again. We tried removing the c8t0d0 device files and re-running insf -e. None of this got the host to recognize the partitions on c8t0d0.
Anybody run into this before or have any ideas?
Thanks in advance,
stc
SKT2
2 Intern
2 Intern
•
1.3K Posts
1
March 4th, 2008 18:00
so your primary boot path is still the old disk..
Also unmasking the old LUN need to be done once you confirm that the youa are able to boot from new LUN.
soncao01
12 Posts
0
March 5th, 2008 11:00
other words device c0t0d0). When it tries to run
¿hpux¿, it errors out with ¿Cannot open device
0x000002¿. Then it restarts itself"
so your primary boot path is still the old disk..
Also unmasking the old LUN need to be done once you
confirm that the youa are able to boot from new LUN.
Hi, Santhosh,
No, the primary boot path is switched to the new device c8t0d0 because of step 3 in the procedure. The guest will see whatever address the host tells it. In this case, the guest sees address 0,0,0 because step three tells the guest 0,0,0. It's just that underneath, when the guest access 0,0,0 it physically to the new lun of c8t0d0 and not the old lun.
Son