vparmodify -p vpar1 -d io:2.0.0 does not work on integrity server

[pedliz11]

the above command does not work the error it return with is 2.2.0 is not an io device but if you dor a ioscan -fnC disk it is still there.
what do i do?

[Michael Steele_2 · Accepted solution]

When using vparmodify only the LBA device instance can be used from ioscan. Can you copy and paste in your ioscan. Here's an example of where to find the LBA:

ba 0 3/0/0 lba CLAIMED BUS_NEXUS Local PCI Bus Adapter (1054)

[Noble Sebastian]

hi

Vapr we can create only separate LBA only . so kindly put out of ioscan .

Regards
Noble

[pedliz11]

the system will not let me remove it see attched file for ioscan

[pedliz11]

also sending u a ioscan of lan need to remove the lan 13 2/0/0/1/0

[Michael Steele_2]

Use this ioscan format:

ioscan -fndlba

lba = local bus adapter
sba = system bus adapter

[pedliz11]

here it is

[pedliz11]

here is the error

[Michael Steele_2]

cross reference by instance number which appears under I column. Looks like I=3 and 4 for lbas 1/0/2 and 1/0/4.

"...trying to remove the above 2/0/0/2/0.6.0 and 2/0/0/3/0.6.0 ..."


disk 3 2/0/0/2/0.6.0 sdisk CLAIMED DEVICE HP 146 GST3146855LC
/dev/dsk/c6t6d0 /dev/rdsk/c6t6d0
disk 2 2/0/0/2/1.2.0 sdisk CLAIMED DEVICE Optiarc DVD RW AD-5170A
/dev/dsk/c7t2d0 /dev/rdsk/c7t2d0
disk 4 2/0/0/3/0.6.0 sdisk CLAIMED DEVICE HP 146 GST3146855LC
/dev/dsk/c8t6d0 /dev/rdsk/c8t6d0


ba 3 1/0/2 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 4 1/0/4 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)

[pedliz11]

so what would be the vparmodify command?

[Michael Steele_2]

vparmodify -p vpar1 -d io:2.0.0

...becomes

vparmodify -p vpar1 -d io:1.0.2 / 1.0.4

[pedliz11]

Ok looking at the output below.
I need to understand how to define the hardware path for removing the internal system lan card.

I know ioscan -fnC lan will give me the hardware path but I need help in understanding how to tie this all together to remove resources on a vpar....Many Thanks

ioscan -fnC lan
lan 12 1/0/14/1/0/6/1 iether CLAIMED INTERFACE HP AB545-60001 PCI/PCI-X 1000Base-T 4-port 1000B-T Adapter
lan 13 2/0/0/1/0 igelan CLAIMED INTERFACE HP PCI-X 1000Base-T Built-in

ioscan -fndsba
Class I H/W Path Driver S/W State H/W Type Description
============================================================
ioa 0 1/0 sba CLAIMED BUS_NEXUS System Bus Adapter (12eb)
ioa 1 2/0 sba CLAIMED BUS_NEXUS System Bus Adapter (12eb)

# ioscan -fndlba
Class I H/W Path Driver S/W State H/W Type Description
============================================================
ba 0 1/0/0 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (122e)
ba 1 1/0/1 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 3 1/0/2 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 4 1/0/4 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 5 1/0/6 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 7 1/0/8 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 8 1/0/10 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 9 1/0/12 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 10 1/0/14 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 13 2/0/0 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (122e)
ba 14 2/0/1 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 15 2/0/2 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 16 2/0/4 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 17 2/0/6 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 19 2/0/8 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 20 2/0/10 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 21 2/0/12 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)
ba 23 2/0/14 lba CLAIMED BUS_NEXUS Local PCI-X Bus Adapter (12ee)

by the way many thanks

[Michael Steele_2]

That's a big 10 pointer before any thing else

[pedliz11]

you got it buddy

[James R. Ferguson]

Hi:

>Michael: That's a big 10 pointer before any thing else

Ransom?!? This is NOT the spirit upon which this community was built!

...JRF...

[Michael Steele_2]

JRF - Still the same, humorless, controlling. Its a public forum. Not the JRF forum.

[Duncan Edmonstone]

... Michael, I'm not sure about your logic here - an 'ioscan -fnCdisk' is going to show ine instance numbers for the devices of class 'disk' - in this casze the instance IDs are 3 and 4. But those instance IDs don't relate at all to the instance IDs 3 and 4 of the devices of class 'lba' as you seem to have related them here.

In all my experience with vPars, the path you see is the path you enter for the command, so I can't see how you would enter an IO resource name for a device that is clearly on hardware path 2/0 as 1/0/2 or 1/0/4.

or am I missing something? - quite happy to be shown to be wrong here...

I'd be more interested in seeing the output of 'vparstatus -p vpar1 -v' for this box, so we can check what actual IO paths *are* included in the vPar database for this partition.

HTH

Duncan

[Michael Steele_2]

Duncan:

OK. Got you. So the instance numbers on the host machine are going to be different than the guest. This I can see. But Pedliz11's ioscan's are all from the guest. I'm assuming.

I've never seen instance numbers vary from one use of ioscan to another. In 20 years they've always been reliable landmarks to work with.

Do you have an example? I'd like to see more on this.

Pedliz11, can you verify success or failure with your vpar commands?

[pedliz11]

here is the output thanks

[Torsten.]

The resources for your vPar are assigned below the lba level, have a look:

...
[IO Details]
1.0.2.1.0
1.0.2.1.1
...

If you want to remove them, you must use these values.

# vparmodify -p vpar1 -d io:1.0.2.1.0

[Torsten.]

Some more explanation:

normally you do the IO assignment at the LBA level, but you can do this even below (like you did).

This is the lba as an example:

1.0.1

but your assignments are

1.0.1.1.0.6.0
1.0.1.1.0.6.1


So if you want to remove, you need to specify this complete path.



If you have for example a 2 port LAN card, you can only assign 1 port to the vPar.
But the other port will remain unused, because you cannot assign it to another vPar (it is below the lba level).

It makes IMHO not much sense to do this, but is is possible.

[Eric SAUBIGNAC]

Bonsoir pedliz11,


What exactly you want to do is not very clear to me. Anyway.

First we must clarify some things. Unless for BOOT and ALTBOOT you DO NOT need to specify a path below LBA level. As said Torsten you can do it but I think that is not very clean.

So your vPar should be configured like this :

[IO Details]

1.0.0
1.0.1
1.0.2
2.0.0
1.0.0.2.0.6.0 BOOT
1.0.0.3.0.6.0.0.0.0.0,ALTBOOT

1.0.0 --> Core access to builtin NIC and internal boot disks

1.0.1 ---> access to your 4 NIC port cards (Torsten : "If you have for example a 2 port LAN card, you can only assign 1 port to the vPar". Sorry but IMHO I can't agree with this. You can do access all the ports of the card in a given vPar)

1.0.2 --> access to your 2 port FC card

2.0.0 --> access to the core IO of an other cell : disks, dvd and builtin lan.

After writing that, I think that I understand now what you want to do : you want to remove all reference to the other cell/IO in order, perhaps, to reduce the nPar you build vPar in ?

So you want to remove 2/0/0 as said in the title of this thread ?

As torsten said you must remove hardware with the path in the same way they have been entered to build the VM. So I guess that :

vparmodify -p vpar1 -d io:2.0.0.2.1.2.0

will be enough to free all ressources from LBA 2/0/0.

Regards

Eric

[Michael Steele_2]

Eric and Torsten:

You're following up on a solution that Duncan has raised a question too. This question was related to the Instance numbers assigned in ioscan and whether or not Instance numbers are a reliable landmark / reference between ioscan -fnkC disk and ioscan -fndlba. (* the hw paths were different but the instances were the same. *)
Pedliz11 verified that the instances appear to be reliable and can close the thread.

Capiche?

Thanks Pedliz11. Do you still have questions? Could you open a new thread if you do? This one's maxing out.

[Eric SAUBIGNAC]

Well, well, well ...

I am probably idiot but certainly confused.

--> Michael you said "This question was related to the Instance numbers assigned in ioscan and whether or not Instance numbers are a reliable landmark / reference between ioscan -fnkC disk and ioscan -fndlba."

<-- My english is poor (unfortunatly I was not born in USA) but what I can see in the first post is a question around "vparmodify" on IO. In my knowledge, instance numbering as no link with adding/removing lba from a vPar. Of course adding/removing lba has a direct impact on instance numbers in the vPar itself. But instance numbers themselves have no role in adding/removing lba. So I don't understand why you are speaking of instance while the problem is clearly to remove an IO.

--> You also said in a previous post "But Pedliz11's ioscan's are all from the guest. I'm assuming."

<-- When I see output of vparstatus I really wonder. ioscan on lba shows all the possible lba in chassis 1 and 2. vparstatus shows only a small subset. If the vPar is really configured as shown in vparstatus, ioscan from the vPar should not show lba like 2/0/10 or 1/0/8 ... or there is a defect somewhere.

--> Also "Pedliz11 verified that the instances appear to be reliable and can close the thread"

<-- Once again this thread has been opened to remove an LBA from a vPar. As far I can see, there is still no validated solution for that.

Regards

A demain, Eric