vPar Hardware Paths


 
Thread Tools Search this Thread
Operating Systems HP-UX vPar Hardware Paths
# 1  
Old 09-02-2009
vPar Hardware Paths

I wonder if anyone could assist with this.

We have taken over administration of an rp8440 that has been split into 2 nPars and has 4vPars per nPar.

I have to add a network card into one of the vPars that was missed at the time the vPar was created. That bit i have no problem with.

The issue i have is that i do not know which of the available resources relates to this i/o slot, so i wonder if anyone could give me any ideas on how to find this out. I am sure there must be a way of working it out, but i cannot figure it out.

I know the card is in chassis 0, slot 1

Available resources from vparstatus -A command

[Available I/O devices (path)]: 0.0.1
0.0.2
0.0.8
0.0.10
0.8.1
Login or Register to Ask a Question

Previous Thread | Next Thread

10 More Discussions You Might Find Interesting

1. HP-UX

How to shutdown a vpar from another vpar?

Hi, How can I shutdown a vpar from another vpar ? Please provide the command. Thanks. (0 Replies)
Discussion started by: snchaudhari2
0 Replies

2. HP-UX

VPAR Resource Capacity Limit

Hello Guys Could you please let me know the command to find the resource (vCPU & Memory) capacity limit for the VPAR's (HPUX 11.23) on integrity Virtual host servers running HPUX 11.31 OS. For eg. I want to know what is the max vCPU and memory that I can assign to one VPAR. The Base Virtual... (0 Replies)
Discussion started by: prvnrk
0 Replies

3. HP-UX

VPar hardware migration - ERRATA document

Hi guys, I'm moving some vPars from BL860c I2 and BL870c I2 using the DRD clone and relocation. In some case, as instance to upgrade to BL870c I2, the ERRATA document reports some additional driver to be added to the image made by the DRD and then recompile the kernel before the move to the... (0 Replies)
Discussion started by: cecco16
0 Replies

4. Programming

Can't find paths.h

I wasn't sure which forum to post this in. I am trying to compile logsurfer. After I run configure and the make, I get a complaint that paths.h is not found. I see three places where there is a paths.h: /usr/include/pgsql/server/optimizer/paths.h... (3 Replies)
Discussion started by: brownwrap
3 Replies

5. Solaris

Hardware faulty, but which hardware?

Hi folk, I have this hardware faunty message, but dont know which hardware is this ? can you guide me ? --------------- ------------------------------------ -------------- --------- TIME EVENT-ID MSG-ID SEVERITY ---------------... (9 Replies)
Discussion started by: dehetoxic
9 Replies

6. HP-UX

vPar Boot Error

Hi All, Please help me out in below issue in creating vPar. We have one nPar in which we have to create 2 vPars, out of which first vPar is already created and it is running well which have local disk as a boot device.Now we have to create 2nd vPar which need to use SAN disk for booting.... (3 Replies)
Discussion started by: laxmikant
3 Replies

7. HP-UX

vpar ignite

Hi Can I use a vpar as an ignite server? (1 Reply)
Discussion started by: mahlathini
1 Replies

8. UNIX for Advanced & Expert Users

Spoofing paths.

There is a program that I am trying to run on a shell account. It depends on another program, which I have also copied to the shell account. Both are in my home directory, yet the first program has a different path hardcoded into it, which I cannot use because of permissions problems. How can I... (3 Replies)
Discussion started by: fahadsadah
3 Replies

9. UNIX for Dummies Questions & Answers

create paths

Hello! If I have file like that: AAA ->bbb ->ccc ->ddd ->eee how to create full paths like: AAA->bbb AAA->ccc->ddd AAA->ccc->eee ? (I'm sorry for mistakes - english is not my native language) :) (4 Replies)
Discussion started by: alias47
4 Replies

10. UNIX for Dummies Questions & Answers

paths

Hi there! People, i'm a new unix user, and i'm having some problems... I'm updating some scripts (korn shell) in different servers. I use telnet to access these servers and emacs to write the scripts. One of them is an HP, and there´s no problem. But the other one is an AIX, and when i call... (1 Reply)
Discussion started by: caiohn
1 Replies
Login or Register to Ask a Question
vparresources(5)						File Formats Manual						  vparresources(5)

NAME
vparresources - description of virtual partition resources and their requirements DESCRIPTION
Hardware resources are the most important property of a virtual partition (vPar). These resources are divided into four major categories, or types: o CPUs o Memory o I/O devices, such as disks, terminals, tapes and printers. o Cells, hardware containers of processors (CPUs), memory, and I/O devices. The essence of virtual partitions is the allocation and distribution of a set of resources among multiple instances of the HP-UX operating system, each running in its own software environment. Resources, once assigned to a vPar, belong only to that vPar and are not visible or accessible to other virtual partitions except through the use of vPars commands such as to view them, or to change the assignment of one or more resources or attributes. For example, if the I/O device at hardware path 0.1.2.3.4.5 is assigned to vPar A, it cannot be accessed by vPar B. A user on vPar B can use the command to display the configuration of vPar A, including this device, but can not otherwise use the device. Note: The command displays hardware paths as a list of numbers separated by forward slashes and dots. The command displays all hardware path elements separated only by dots. Either form can be supplied to the or command when configuring a virtual partition. The command can display either legacy or agile hardware paths depending on the options used. It can also display mapping information between legacy and agile hardware paths. Refer to the ioscan(1M) manpage for more information. The Virtual Partition Database File Virtual partition configurations (attributes and resources) are kept in a database file. The default filename is but other names may be specified. You can create the file in any path, but to be used by the vPar monitor, the file must reside in On Itanium(R)-based platforms, there must also be a soft link between the database file and an identically named file in the directory. The link is not required on PA platforms. The command creates this link for you when you create the database file in the directory. If you create it in a different directory and later move it to or if you create it on one system but copy it to another for use, you must man- ually create the link. When the monitor is loaded, it reads the specified (or default) file into its memory. Any configuration changes while the monitor is run- ning are made to this memory copy and then written to the disk copy of all running virtual partitions. Requested and Effective Resources Because the monitor requires a database file, you must first create one with the command while running in a full hard partition (nParti- tion) or on a supported non-partitioned system. Any resources you specify at this time (or at any time when the monitor is not running) are termed because they are not checked for existence. For example, vPars will allow you to distribute 16 GB of memory among your virtual partitions even if the nPartition has only 8 GB. This is because you may be configuring the database for use on another nPartition. vPars only ensures that you do not assign the same specific resource to more than one vPar. When the monitor loads this database file, it checks the existence of all the specified resources, adjusting any that require it. The result of this validation step is a set of resources. In a running vPars environment, the monitor checks both existence and duplicate assignment for every proposed resource change. When you use the command when the monitor is not running, or if you specify a database other than the one currently loaded into the moni- tor, it displays resources. Otherwise it displays resources. Resources described in this manpage are resources unless noted otherwise. RESOURCES
Different resource types call for different resource management. Each resource type and its management is described below. CPUs The min/max specification, bound CPUs: In addition to defining the limits of the number of CPUs assigned to a vPar, in HP-UX Release 11i, Version 1, the min specification also defined the number of bound CPUs, those capable of processing I/O interrupts. This number could not be changed while the vPar was running. In HP-UX Release 11i, Version 2 (and later releases), all CPUs are capable of processing I/O interrupts, and they may be added or deleted while the vPar is running, except for the boot processor, described later. Therefore, the concept of "bound CPU" no longer has meaning. min and max now define only the upper and lower limits of CPU assignment. The relation is always strictly enforced. Although you can mod- ify each value, you will get an error if this relationship is ever violated, even in mid-command. This means o You cannot delete CPUs such that o You cannot add them such that o You cannot modify min if that would exceed total CPUs, o You cannot modify max to a value less than total CPUs. If you do not specify min or max when creating a vPar, the following defaults apply: o min = 1. o max = number of Enabled CPUs in the nPartition. Although CPUs can be added to and deleted from a running vPar, the values for min or max can only be changed if the vPar is For the rest of this section, we assume that any CPU operation does not violate a min or a max requirement. CPUs can be added (assigned) to a vPar in one of three ways. The result of the assignment can depend on whether the vPar is running or not running o Non-cell-specific, or generic, assignment, The monitor is free to assign any available CPUs authorized by the iCAP product to satisfy num. See the section later in this manpage for more information on iCAP. If the vPar is the CPUs are assigned immediately, and, after a short initialization period, are available for use. During initialization, a command will show them as If the vPar is num CPUs are allocated to the vPar if available and authorized, but the monitor assigns specific CPUs only when the vPar is booted. o Specific assignment by hardware path, If this operation succeeds, the specified CPU is assigned to the vPar. The CPU is permanently associated with the vPar unless it is deleted by hardware path. The command shows such CPUs as "User assigned". The CPU must be available, that is, it must exist and not be assigned to another vPar. Also all CPUs from the cell must not have already been reserved to either this or another vPar. If the operation increases the total number of assigned CPUs, it must also be authorized by iCAP. If the vPar is a specific assignment does not change the total number of CPUs assigned to the vPar, hence iCAP does not need to autho- rize the action. But it also means that a specifically assigned CPU must replace a previously allocated generic CPU. If there is none, the assignment fails. Example: You have configured a vPar with The vPar is Now you enter This works because the monitor assigns CPUs only when the vPar is booted, so it will then use the specific two you assigned by path. But your total allocation is still two CPUs. At this point, if you enter the request will fail because you have not allocated a third CPU. If the vPar is the result varies as follows: o If path is that of a generically-allocated CPU that the monitor assigned to the vPar when it was booted, it changes to be specifi- cally assigned. It will remain associated with the vPar until deleted by specific path. But the total CPU count does not change, hence iCAP need not authorize the operation. o If the specified CPU is not assigned to a vPar, it is added to your vPar and remains associated with it until deleted. The total CPU count increases by 1, so iCAP must authorize the addition. Hewlett-Packard recommends that users configure specific CPUs only when required for performance, and that you do not mix user-assigned CPUs and cell-local processors (next bullet) in the same database. Where performance is not a consideration, specify only generic assignments and allow the monitor to manage assignment of CPUs. o Assignment by specifying a cell, The monitor is free to assign any num available CPUs from cell cell_id. CPUs assigned in this way are referred to as cell-local processors or CLP. As with generic assignment, if the vPar is the CPUs are assigned immediately. If it is they are allocated, but specific CPUs are only assigned when the vPar is booted. In either case, the CPUs must be available and their addition authorized by iCAP. Hewlett-Packard recommends that users configure CLPs only when required for performance, and that you do not mix CLPs and user-assigned processors (previous bullet) in the same database. Where performance is not a consideration, specify only generic assignments and allow the monitor to manage assignment of CPUs. Any CPU assigned to a running vPar can be deleted by specifying its hardware path. Except for that condition, if a CPU is to be deleted later, it must be deleted the same way it was assigned. For example, if you have configured a vPar as follows: you will have six CPUs in your configuration. (Recall that the total CPU count does not change when adding a user assigned CPU to a vPar.) In this case, you have replaced one generically specified CPU with a user assigned CPU, leaving three generically assigned. With this configuration, you are only allowed to delete three CPUs generically, using You will get a command error if you specify a higher number. Similarly, the two CLP CPUs can only be deleted via a CLP deletion. No matter how you choose to add and delete CPUs, the total must always remain between the min and max specification for the vPar. To help you manage these limitations, the command displays the count of CPUs in the various categories when the or the options are used. Here is the CPU portion of the detailed display for the above configuration: [CPU Details] Min/Max: 1/8 User assigned [Path]: Boot processor [Path]: 0.12 Monitor assigned [Path]: 2.10 2.11 2.12 3.10 3.11 Non-cell-specific: User assigned [Count]: 1 Monitor assigned [Count]: 3 Cell-specific [Count]: Cell ID/Count 3 2 Note that in the path displays, the user assigned CPU is also the boot processor, and so has been shown in the line rather than the line. The boot processor is meaningful only when a vPar is running. When a vPar is or in an alternate database, the line or subfield is empty. The boot processor is the first processor to be activated when the vPar is booted, and is the one on which all boot time activity takes place. It is assigned this responsibility by the vPar monitor. Due to the special requirements of the boot processor in an OS, it cannot be deleted while the vPar is running. Each vPar OS assigns a processor number of zero for its boot processor irrespective of the proces- sor's hardware path or what its processor number would have been if the OS had booted in the nPartition. Certain designs of CPUs are fabricated such that they share common low-level hardware. Each such CPU is termed a The set of common hard- ware that they share is termed a CPUs that share a socket are called In a vPars environment, each CPU is managed as a separate resource. So, it is possible to assign siblings to different virtual partitions. The vPars monitor will attempt to assign siblings to the same vPar whenever possible. Further discussion of multiple-core CPU sockets is beyond the scope of this manpage. However, the command will display any sibling rela- tionship that might exist. CPUs that are added to or deleted from a running vPar undergo a process termed This is the period between when the configuring vPar's command terminates and the operation is actually complete. When adding a CPU, the CPU must undergo a short setup period during which supporting low-level resources are added and activated in the vPar. It is then placed on the kernel's list of active processors so that work may be scheduled on it. At this point, migration in is complete. A CPU to be deleted is normally performing useful activity for its vPar. Before the CPU can be released to the monitor, making it avail- able for assignment to other virtual partitions, this activity must be terminated in an orderly fashion. When this process is finished, migration out is complete. In terms of vPars assignment, a CPU is removed from the monitor's Available list and assigned to a running vPar by the command. It is assigned throughout the migration in period. When deleting a CPU from a vPar the CPU remains assigned to the vPar until migration out is complete. The various forms of the command (summary, detailed, machine-readable) indicate CPUs undergoing migration in or out. Refer to the vparsta- tus(1M) manpage for details. Every HP-UX operating system includes CPU diagnostics which run in the background. Their purpose is to detect incipient errors in CPU hardware. As part of this operation, they manage several co-existing CPU states: These states are displayed by the command. Detailed descriptions of these states are beyond the scope of this manpage, but their effects on vPars configuration/oper- ation are described next. vPars does not allow the boot processor to enter the state. This is because any CPU in a running vPar that enters either of these states is not allowed to continue processing beyond the time needed to move any current work to another CPU. The OS cannot allow the boot proces- sor to cease execution, so these states are disallowed for that CPU. The monitor may not boot a vPar whose configuration includes a CPU in either the state. Nor will it silently modify a vPar's configuration to reduce CPU count by the number of defective CPUs. Therefore, the ability to boot depends on how the ailing CPU has been configured: o If the defective CPU was assigned by the monitor, whether as a CLP or as a non-CLP, and a replacement processor is available, the moni- tor will assign it in place of the defective CPU and boot the vPar. o If a replacement processor is not available, the vPar configuration is not changed and the monitor does not allow the vPar to boot. You must use the command to delete a CPU from the vPar's configuration. Or, you can make a replacement CPU available by deleting one from another vPar. o If you assigned the CPU specifically by hardware path, it remains assigned to that vPar even when the vPar is shutdown. The monitor will not allow that vPar to boot until the user has deleted the CPU by specific hardware path, Since the vPar is this operation does not change the total CPU count of the vPar. At that point, the ability to boot depends on the availability of a replacement processor, as before. Once the defective CPU has been removed from its vPars environment, it no longer appears in the monitor's list of Available CPUs. The iCAP product manages a hardware complex (all nPartitions in a server) that has one or more unlicensed components. It prevents the use of those unlicensed components. Such a complex is said to be Compliance is determined at the complex level and enforced at the nPartition level. Systems in which all components are licensed are fully compliant. iCAP does not restrict their use in any way. In a vPars environment, iCAP restricts CPU assignments to a vPar such that the total number of CPUs assigned to all virtual partitions in an nPartition must not exceed that displayed by the command as the Intended Active number for the nPartition. iCAP enforces this restric- tion when you try to add processors, either to an existing vPar or when creating a new vPar. The Intended Active number cannot be changed as the result of a vPars command. You must use the command to change this value. Refer to the icod_modify(1M) manpage and to the iCAP document referenced at the end of this section. The vPars product interacts with iCAP as follows to maintain compliance: o In a running vPars environment, any number of processors may exist in the pool of unassigned (Available) CPUs in the vPar monitor. A will display them. But a command that would cause the total CPU configuration of all virtual partitions, whether or to exceed the Intended Active number will not be authorized by iCAP and will result in a command error. o Whenever you attempt to add CPUs when creating or modifying a vPar in an alternate database (one not loaded into the monitor, or when the monitor is not running), iCAP tests the CPU configuration of that database against the Intended Active number in the hard partition in which you run the command. An excessive CPU configuration is allowed here, but is reported as a warning. o If you try to load such a database into the monitor when it is booted, iCAP reboots any initially launched virtual partitions and noti- fies the monitor. The monitor will then not allow any virtual partitions to launch. You must reboot in nPar (non-vPar) mode, adjust either the Intended Active number or the database configuration as an alternate database, then reboot the monitor. A detailed discussion of iCAP is beyond the scope of this manpage. Refer to "Using Instant Capacity to Manage Processing Capacity" chapter in the available at and to the icod(5) manpage for more information. Memory There are two major types of memory designation, Cell Local Memory, (CLM), and InterLeaved Memory, (ILM). With CLM, entire contiguous mem- ory address ranges are found on a single cell. ILM is an address range of memory whose adjacent addresses reside on one or more cells in the underlying hard partition (nPartition). Both have their advantages. In this topic, we confine ourselves to the mechanics of managing each memory type. Memory is normally assigned to virtual partitions in units called Exceptions are described below. The granule values for CLM and ILM can be different. However, both are subject to the following rules: o MOST IMPORTANT, READ CAREFULLY. Granularity, the value of a granule specification, is not a resource. Resource assignments can be mod- ified, even if some resource modifications require that a vPar be Granularity can only be specified when creating a new database. It cannot be changed thereafter. o The minimum values (ILM and CLM) are 64 MB. o The default values are 128 MB. Refer to the section for more details. o The recommended specifications are described below. o Any chosen granularity must be an integral power of 2, not just a multiple of 64. For example, 256 is a legal value, but 192 is not. o Although a granularity must be an integral power of 2, memory can be assigned in any multiple of that value. For example, if the CLM granularity is 128 MB, it is legal to assign 384 MB of CLM to a vPar. o There is a limit on the number of granules specified on the command line for online memory addition/deletion. In such cases the user can retry with lesser options/granules on the command line. o Itanium-based platforms have a platform-dependent limit to the number of CLM granules per cell or ILM granules that may be configured. You can determine specific limits for your installation by using the command and examining the "The maximum possible xLM granules..." messages. These values, combined with your total memory of each type, determine the minimum granularities you should specify in order to allow your virtual partitions to boot. For example, if you are allowed 1024 ILM granules and your total memory is <= 128 GB, you can use the default ILM granularity of 128 MB. Or if you are allowed 16 CLM granules per cell, and your nPartition configuration includes two cells each configured with 8 GB of CLM, your CLM granularity must be >= 512 MB. If the total ILM memory or CLM memory per cell exceeds that which can be configured in the maximum number of granules using your speci- fied granularity, the vPar monitor will not boot any vPar. In this case, you must increase one or both granularities appropriately so that all available memory can be accommodated. This will require a complete reconfiguration of your database. Careful configuration planning will avoid this situation. Granularity limitations do not apply to PA-RISC platforms. However, there are guidelines that do apply to both PA-RISC and Ita- nium-based platforms. These are described next. o Recommendations for ILM and CLM granularity specifications: On PA-RISC platforms, each vPar needs ILM below 2 GB to load and launch its kernel. However, portions of the first granule (starting at address 0) are used for the monitor's code and data, therefore will not be used for the kernel. Hence, excluding the first granule, there should be at least one granule below 2 GB for each partition. So if ILM granularity is 128 MB, the first 2 GB will consist of 16 granules. Therefore, it will be possible to load and launch the maximum supported 8 virtual partitions. If ILM granularity is 256 MB, there are only 8 granules in the first 2 GB. The monitor uses portions of the first one. So it will only be possible to load and launch 7 or fewer virtual partitions. On Itanium-based platforms, there is no similar constraint on the maximum ILM granularity. o For an Itanium-based platform, the chosen granularity values must also be written to system firmware storage. When the monitor is started and a vPar database is loaded, the values in the database must match those in firmware, or the monitor will not allow the data- base to be used. While in nPar mode, you should use the and commands to verify that the database and firmware granularities are identical. If not, you must either create a new database with the correct granularities using the command, or change the firmware granularities with the com- mand. Although memory is normally allocated in integral granules, some memory ranges are withheld for use by the monitor or by firmware. The command displays these ranges. Other ranges of address space are simply non-existent. Because of this fragmentation, the monitor may assign your vPar slightly more or less than an integral granule of memory when the vPar boots. When memory is deleted from an active partition, the kernel makes the decision on which granules of memory is easier to delete. Hence, the granules that get deleted may not add upto the memory that was requested. For example, if the granule size is 1024MB and there are two floating memory granules 1024MB and 580MB (a granule with memory hole) and the user requested delete of 580MB, after aligning the request the kernel/monitor might pick either 1024MB or 580MB granule to delete. If all or some of the deleted memory happens to fall within a user- specified floating range, the remainder of the range is converted from user-specified to monitor-assigned range. The default memory granularity chosen by the vPars software is based on the total memory in the hard partition. The minimum default value is 128MB which is same as the default value in A.04.01. However, if the memory in the hard partition is too large to fit into the supported number of memory granules for the hard partition, then the next higher supported memory granularity value is chosen as the default memory granularity. This is done at the time of a new database creation. For example, If a hard partition contains 64G of interleaved memory and the maximum number of supported ILM memory granules on the system is 1024, then the default memory granularity chosen is 128MB. If a hard partition contains 192G of interleaved memory and the maximum number of supported ILM memory granules on the system is 1024, then the default memory granularity chosen is 256MB. The above default value is determined by the vPars software when the vpar database is created for the first time. When new memory is added to the hard partition, memory granularity is not automatically recalculated. In certain scenarios, vPar command may not be able to calculate the default granularities accurately. In these cases, a default of 128MB will be chosen and a warning message asking the user to validate the granularity manually will be issued. This section applies only for Itanium-based platforms. There are no OS boot time performance issues in HP-UX Release 11i, Version 3 related to the memory granularity chosen for the system. Dif- ference in OS boot time on the same system with 128MB granularity and 1024MB granularity is close to insignificant. Hence, you do not have to set a higher memory granularity value for large memory systems with A.05.01 running HP-UX Release 11i, Version 3. However, if any of the vPars is running HP-UX Release 11i, Version 2, then higher memory granularity value may have to be chosen to improve the boot time for the HP-UX Release 11i, Version 2 vPar. This section applies only for Itanium-based platforms. When new memory is added to the hard partition and if the number of memory granules on the system based on the current memory granularity value exceeds the maximum supported memory granules on the system, then the vPar database has to be manually recreated. At the time of man- ual database recreation, a new memory granularity value will be chosen by the vPars software which works with the total memory on the sys- tem. For example, If you added 32G to a 64G system and the memory granularity was 128MB, there is no change required, since the total number of granules based on 128MB is still under 1024. If you added 64G to a 96G system and the memory granularity is 128 MB, you are exceeding the 1024 limit for the maximum number of granules supported for the system and you have to recreate the database. The new granularity chosen by the vPars software will be 256MB for this case. The above examples are assuming that memory is added as ILM for a system having 1024 as the supported maximum number of ILM memory gran- ules. Similar adjustments have to be made if new memory is added as CLM. The option is used to assign size MB of base or floating ILM to a vPar. The option assigns size MB of base or floating CLM from cell cell_id to a vPar. If base (or b) or floating (or float or f) is not specified, memory added or deleted will be treated as base memory. Base memory (default) cannot be deleted when the vPar is Up. Floating memory can be deleted when the vPar is Up. If size is not an integral multiple of the gran- ularity of the specified memory type, vPars normally adjusts it upward to the next granule boundary. However, vPars will allow you to con- figure a sub-granular quantity of memory if doing so exhausts available memory. Consider a configuration with 4 GB granules and two gran- ules of unassigned memory. Due to fragmentation, 2 GB of one granule are not available. The monitor will allow you to assign either 4 GB (one granule) or 6 GB (all remaining memory). In a vPar environment, either of the above command line options cause the monitor to reserve the indicated memory, if it is available. However, actual memory ranges are only assigned to the vPar when it is booted. These ranges may be different from boot to boot. Changes to memory size specifications can be made when a vPar is or or when it is in an alternate database. If changes are made when the vPar is and if the attribute is not specified, the memory is added as base memory. Base memory cannot be deleted when the vPar is If the memory is added as "floating" memory, it can be deleted even when the vPar is If the memory is added when the vPar is the operation may not complete immediately. In such cases, the output will display the tag In a non-vPar environment, or when configuring an alternate database, existence of the specified memory (including the cell for CLM) cannot be verified. The specification is placed in the database as a entry. When the database is loaded into the monitor, the monitor may adjust the specified amounts to correspond to existing memory resources. If sufficient resources cannot be found, the monitor may not boot the vPar. The command displays actual available memory ranges. Ranges that are lost to fragmentation are not shown. You can assign specific memory address ranges to your vPar, but Hewlett-Packard recommends that you not do this except when required for performance reasons. o If the target vPar is Down, assigning a range does not change the total memory allocation. It simply reserves a specific address range within that allocation. Therefore, you must first allocate an amount of memory, and then assign ranges. o If the target vPar is Up, adding a range will increase the total memory allocation of that type. Therefore, it is not necessary to first allocate the amount of memory. However, the amount of memory required from the type for the range should be available and free in the monitor. Sometimes, the operation may not complete immediately. In such cases, the output will display the tag o A specific address range is unique on the system, and so may be a part of ILM or CLM. You cannot tell from the address alone if it is ILM or CLM. Therefore, you always use the command to list all available memory ranges and their type before attempting to assign a spe- cific range. If you do not need specific memory ranges, configure only amounts of memory and allow the monitor to manage the assignment of specific ranges. On PA, memory below 2GB is used for loading and launching kernel of each partition. Kernel requires memory where it is loaded to be base memory. Hence, a partition should not contain any user-specified floating ranges below 2GB. If a partition has a user-specified floating range below 2GB, the monitor will not boot the partition until the user removes the floating range. If needed, the range can be added back as a user-specified base range. The kernel requires some amount of base memory to boot and run. Typically, the kernel expects the low end of the memory to be base memory. To satisfy this expectation, the monitor-assigned base memory ranges are at low end during boot. If the virtual partition has less overall base memory or less base memory at the low end, some of the floating memory gets converted to base memory during boot. If the floating mem- ory range that got converted to base memory happens to fall within a user-specified floating range, the range is converted from user-speci- fied to the monitor-assigned range. If a memory range specification (either base or range) is not granule- aligned, but you have specified the entire range, the monitor does not allow you to assign it. If you do not specify the entire range, the monitor the base as required to the base of the available range or to the next lower granule boundary, whichever is reached first. The monitor the range as required, starting from the original endpoint, to the end of the available range or the next higher granule boundary, whichever is reached first. If the monitor is able to assign this mod- ified range, you will get a warning that your request has been modified. If the increased memory range cannot be assigned, for example because it exceeds the total allocation of that type of memory to the vPar, the warning is suppressed. Instead you will see the relevant error message. Assignment of ranges that are not granule aligned is not supported. Hence this is not recommended. Here are some examples of memory range specifications. For simplicity, all examples show memory range addition, but operation is similar when deleting memory ranges. Also note that when no base or floating attribute is specified, the add is treated as base memory add. Sup- pose that the ILM granularity is 128 MB, you have configured 1GB of ILM as base and 1GB of ILM as floating in your vPar and the following ILM ranges are available: [Available ILM (Base /Range)]: 0x4080000000/128 (bytes) (MB) 0x40C0000000/1536 Each of the following examples starts from this initial condition. You have specified the entire granule aligned range to be added as base memory, and the request does not exceed your total ILM con- figuration. The request is granted. No message is displayed. You have specified the entire granule aligned range to be added as floating memory, and the request does not exceed your total floating ILM configuration. The request is granted. No message is displayed. The "0x40800a0000" is adjusted downward to the start of the available range and the "20" is adjusted upward to the next granule boundary which is within the end of the available range. The result is the same as in the first example. The request is granted, but the command displays a warning of the modification. You have specified a range exceeding that which is available. The request is denied and the command displays an error. You have specified one granule starting on a granule boundary. The request is granted. This range gets added as a base range. The base is adjusted downward to 0x40C0000000 and the range is adjusted upward to 128, the granule boundary. The request is granted and the command displays a warning. Here, the request straddles a granule boundary. The base is adjusted downward to 0x40C0000000 as in the previous example. The is adjusted upward to the next granule boundary. The resulting 256 MB request does not exceed your total base ILM configuration. The request is granted and the command displays a warning. You have specified a memory range for your entire base ILM allocation. The request is granted. The range is adjusted upward to 1024. The request is granted and the command displays a warning. Again the request straddles a granule boundary. The base is adjusted downward and the original endpoint is adjusted upward, as in a previous example. This makes the adjusted request equivalent to 0x40C0000000:1152. Although this is still within the range of available memory, the request exceeds your total base ILM configuration. The request is denied and the command displays an error, not a warning. Changes to memory range specifications can be made when a vPar is or or when it is in an alternate database. If changes are made when the vPar is and if the attribute is not specified, the memory is added as base memory. Base memory range cannot be deleted when the vPar is If the range is added as "floating" memory, it can be deleted even when the vPar is For online deletion of ranges, the base or floating attribute is not enforced. If the user specifies a floating range but does not specify the "floating" attribute, the deletion will still succeed. Irrespective of the attribute specified, online deletion of base ranges will always fail. As with CPUs, once a specific memory address range is assigned to a vPar, it remains assigned to the vPar, even when that vPar is not run- ning. Memory allocated to the vPar, but not specified explicitly, is assigned by the monitor when the vPar is booted. As with CPUs, moni- tor-assigned memory ranges may be different each time the vPar is booted. The command displays the monitor-assigned CLM and ILM memory ranges of each running vPar when either the or the option is used. Since vPars cannot tell if a specified memory range would be ILM or CLM, and the two granularities can be different, there is no way that vPars can adjust a non-granular range specification. I/O I/O resources are all resources other than CPUs and memory. Disks, LAN cards and terminals all qualify as I/O devices. vPars manages them as non-shareable resources. A minimally-configured vPar requires one CPU, sufficient memory, and a disk device to boot from. In addition, if a LAN card is not configured, the only terminal access to the vPar is through the serially-connected console. The first three hierarchical levels of I/O resource specification are the cell, the System Bus Adapter (SBA), and the Logical Bus Adapter (LBA). (On non-cellular systems, the first of these is not present.) LBAs and lower are assigned to a specific vPar. LBAs and devices below that level cannot be shared with any other vPar. For example, cell 1 might include the following SBAs: 1/0 and 1/2. LBAs attached to these SBAs can be assigned to different virtual partitions. With this configuration, 1/0/0 (or any lower path element can be assigned to vPar A, 1/0/4 can be assigned to vPar B, 1/2/0 can be assigned to vPar C. This means that the disk at 1/0/0/3/0.6.0 is assigned to vPar A, because it is attached to LBA 1/0/0. A LAN card at 1/0/0/1/0 cannot be assigned to vPar B because it is attached to LBA 0 which is assigned to vPar A. I/O resources can only be assigned to or deleted from a vPar when the vPar is (not running). A vPar requires a bootable device. Usually this is a disk. The BOOT and ALTBOOT attributes allow you to specify the device vPars should use when booting your vPar. vPars will try to boot the vPar from this device unless overridden with the option of the or command. vPars does not verify that a device with the [ALT]BOOT attribute is actually a bootable device. If a vPar has a non-bootable boot device assigned to it, the vPar will not boot when requested. You specify an attribute using an optional additional field on an I/O resource specification. For example: adds the specified device to your vPar, while adds both the device and the BOOT attribute. Attributes can be added or deleted independently of the device itself. You could specify the first example above. Later you could specify the second example. The only change would be to add the attribute to the existing I/O configuration. Deletion is similar. If you specify you are only deleting the attribute. The underlying I/O resource remains assigned. If you specify the entire resource is deleted. Finally, if you add an attribute to a resource, it is silently deleted from any existing resource it may be attached to. HP-UX Release 11i, Version 3 introduced additional types of hardware paths to I/O devices: lunpath hardware paths and LUN hardware paths. The original format of hardware path is now referred to as a legacy hardware path. Support for agile hardware paths has been added to Virtual Partitions in the A.05.03 release. Agile hardware paths can now be used to specify I/O devices when using the vparcreate and vparmodify commands. For example: adds the specified device to your vPar. The vparstatus command will also be able to display agile hardware paths. An example of how an agile hardware path is displayed by the vparstatus command follows. [IO Details] 1.0.12.1.0.0x500805f3000ff771.0x400e000000000000 BOOT Note that virtual partitions running older versions of the product will not be able to specify agile hardware paths, nor they will be able to properly display them. Virtual partitions running older versions will be able to co-exist with virtual partitions booting from agile hardware paths, so long as legacy mode is not disabled in any virtual partition. Cells Cells are container objects. They do not exist on systems that do not support hard partitioning, so this discussion does not apply to those systems. Cells consist of CPUs, memory, and (optionally) I/O devices. In HP-UX Release 11i, Version 2 (and later releases), cells themselves are not assignable resources. They cannot be added to or deleted from virtual partitions in their entirety. CPU and memory resources on cells can be allocated among different virtual partitions. For example, given a cell containing four CPUs, one CPU can be allocated to each of four virtual partitions, all four to one vPar, or any other possible combination. Two additional syntax forms allow you to specify that available resources should be allocated from a specific cell: allocates num CPUs on cell_id to the target vPar. The monitor is allowed to assign any subset of CPUs on cell_id, and this subset may vary from boot to boot. allocates size MB of base or floating CLM from cell_id to the target vPar. If the attribute is not specified, the memory added will be treated as base memory. If size is not an integral number of granules, it is first rounded upward to the next integral value. Whether rounded upward or not, the memory must have been previously configured as CLM by the or commands in nPar mode. See parmgr(1M) and parmod- ify(1M). In a non-vPars environment or alternate database, availability is not checked, so the memory specified becomes a attribute. It will be validated and may be modified when the database is loaded into the vPar monitor. COMMANDS AND THEIR RESOURCE SPECIFICATIONS
Each vPar can be configured with a subset of total system hardware resources such that any given physical resource is assigned to at most one vPar. This job is managed by two of the virtual partition commands: o used when creating a new vPar. (Resources can only be added) o used when modifying an existing vPar configuration. (Resources can be added, modified, or deleted) Each command has specific resource syntax and semantic requirements. For example, some resource changes can only be made if the target vPar is not running. Some syntax forms can be specified once. Additionally, beginning in vPars version A.02.02, there are specific hardware path format rules to follow that did not exist when using previous versions of vPars. All of these are described in the tables below. The general form of a resource specification is up to six positional fields delimited by colons (":"). No whitespace is allowed within any field. Table I summarizes the three categories (CPU, I/O, and memory) and all the allowable forms for each. Table II specifies which forms are allowed for each of the three tasks (add, modify, or delete). Table III is a detailed description of each syntax form and the conditions required for its use. Table IV is a description of the hardware path format rules. Table I. Resource syntax summary +---------+----------------------------------------+-------------------+ |Resource | Form | # times/command | +---------+----------------------------------------+-------------------+ |CPU | cpu:path | Multiple | | | cpu::num | Once | | | cpu:::[min][:[max]] | Once | | | cell:cell_id:cpu::num (CLP) | Once per cell_id | +---------+----------------------------------------+-------------------+ |I/O | io:h/w path[:attr1[,attr2]] | Multiple | +---------+----------------------------------------+-------------------+ |Memory | mem::size[:base|floating] (ILM) | Multiple | | | mem:::base:range[:base|floating] | Multiple | | | cell:cell_id:mem::size[:base|floating] | Twice per cell_id | | | (CLM) | | +---------+----------------------------------------+-------------------+ The first field is always one of the (case-insensitive) strings or num, min, and max are all positive integers. cell_id must be greater than or equal to 0. size and range are positive 64-bit integers in units of megabytes. base is an unsigned 64-bit integer in units of bytes. The commands round each of them upward as required to the granule increment in effect for that memory type. size, range, and base may each be specified in decimal or in hexadecimal. A hex specification should be preceded by as in The last optional field for the memory specification can be either or If this field is not specified, the default is type base. The attributes for the I/O specification are zero, one, or many of the following (case-insensitive) strings: and If more than one are spec- ified, then they must be separated by a comma. Each of the attributes can be assigned to no more than one I/O device. If it is already assigned to a device, a new assignment silently de-assigns it from its present device. However, one device can associate both attributes. This means it is possible for one device to own all ALTBOOT, TAPE and BOOT attributes, but it is not possible for two or more devices to own BOOT. Users must guard against assigning an attribute to an inappropriate device, for example, assigning BOOT to a tty. The commands do not check for this, nor do they prevent it. Table II. Allowed forms for each task +------------+---------------------------------+--------------+ | | | Allowed with | | Task | Form | vPar running | +------------+---------------------------------+--------------+ |-a (add) | cell:cell_id:cpu::num | Yes | | | cpu:path | Yes | | | cpu::num | Yes | | | cpu:::[min][:[max]] | N/A | | | (vparcreate only) | | | | io:path[:attr1[,attr2]] | No | | | cell:cell_id:mem::size | Yes | | | mem::size | Yes | | | mem:::base:range | Yes | +------------+---------------------------------+--------------+ |-m (modify) | cpu::num | Yes | | | cpu:::[min][:[max]] | No | | | cell:cell_id:cpu::num | Yes | | | io:path[:attr1[,attr2]] | No | | | mem::size | Yes | | | cell:cell_id:mem::size | Yes | +------------+---------------------------------+--------------+ |-d (delete) | cell:cell_id:cpu::num | Yes | | | cpu:path | Yes | | | cpu::num | Yes | | | io:path[:attr1[,attr2]] | No | | | cell:cell_id:mem::size | No | | | cell:cell_id:mem::size:base | No | | | cell:cell_id:mem::size:floating | Yes | | | mem::size | No | | | mem::size:base | No | | | mem::size:floating | Yes | | | mem:::base:range | Yes | +------------+---------------------------------+--------------+ The forms above are subject to the following semantic rules enforced by the commands. Note that according to Table II, except for the operations involving CPUs and memory, a vPar must be in the state (or in an alternate database) to apply any of the changes described below. o CPUs 1) specifies that num CPUs be added to the target vPar. If the target vPar is in the live monitor database, at least num CPUs must be available in the monitor. 2) specifies that the CPU at hardware path path be added to the target vPar. The CPU must not be already assigned to another vPar. If the target vPar is in the live monitor database, the CPU must also exist. 3) specifies that num CPUs on cell cell_id (CLPs) be added to the target vPar. If the target vPar is in the live monitor database, at least num CPUs on cell_id must be available in the monitor. 4) No matter how they are specified, the total number of CPUs assigned to a vPar must always be within the range specified by the spec- ification. 5) specifies that the total non-cell specific processors in the vPar be set to num. This operation may result in assignment or dele- tion of CPUs. 6) specifies that the total cell specific processors from cell cell_id in the target vPar be set to num. This operation may result in assignment or deletion of CPUs. 7) Defaults: When a vPar is created, the following defaults are in effect: o min: Platform dependent, usually o num: o max: If the vPar is created in an alternate database, If it is created in the live monitor database, max is equal to the total number of active CPUs in the underlying hard partition. You can modify these defaults with command line options to the or command only when the vPar is down. o Memory 1) specifies that at least size MB of base or floating ILM must be available in the monitor. If size is not an integral multiple of the ILM granularity, it is first rounded up to the next granule boundary before testing for availability. By definition, this mem- ory is of type ILM. 2) specifies that at least size MB of base or floating memory on cell cell_id must be available in the monitor. If size is not an integral multiple of the CLM granularity, it is first rounded up to the next granule boundary before testing for availability. By definition, this memory is of type CLM. 3) specifies that the total base or floating memory in the target vPar be set to size MB. This operation may result in assignment or deletion of base or floating memory. Deletion of base memory can be done only when the target vPar is Down. The option is inter- nally mapped to either a or option. The difference in the current memory size and the specified memory size is rounded up before the addition or deletion. This may sometimes result in the new memory to be more than the specified value if is internally mapped to or less than the specified value if is internally mapped to Here are a few examples to illustrate the above. Example 1: Suppose the current memory value of the target vPar is 1024MB and the specified new memory value using -m is 1000MB. Also assume that the ILM granule size is set to 256MB. Since the new specified value is less than the current value, the operation will be determined to be a "deletion". Current value - Specified value == Value to be deleted. 1024 - 1000 == 24. So the command deletes 256MB from the current value resulting in 768MB which is less than what the user asked for. Example 2: Suppose the current memory value of the target vPar is 1024MB and the specified new memory value using -m is 1025MB. Also assume that the ILM granule size is set to 256MB. Since the new specified value is greater than the current value, the operation will be determined to be an "addition". Specified value - Current value == Value to be added. 1025 - 1024 == 1. So the command adds 256MB to the current value resulting in 1280MB which is more than what the user asked for. 4) specifies that the total base or floating CLM from cell cell_id in the target vPar be set to size MB. This operation may result in assignment or deletion of base or floating CLM. Deletion of base memory can be done only when the target vPar is Down. The option is internally mapped to either a or option. The difference in the current memory size and the specified memory size is rounded up before the addition or deletion. This may sometimes result in the new memory to be more than the specified value if is internally mapped to or less than the specified value if is internally mapped to Refer to the examples above. 5) Explicit address ranges are assigned to both the CLM and ILM memory types. When you use the option to specify an explicit memory range, that range must not only be available for assignment, but must reside entirely within one memory type. In addition, if the target vPar is Down the total amount of memory specified in explicit memory ranges must be less than or equal to the total memory of that type assigned to the vPar using the or specifications. However there is no such restriction if the target vPar is Up. Adding/deleting a range to/from an Up vPar increases/decreases the total memory assigned to that vPar. When you specify an explicit range of memory (whether adding or deleting), to a Down vPar, you do not change the total amount of memory assigned to the vPar. When adding, you merely specify that the particular range you specify be one part of the total amount of that memory type (CLM or ILM) assigned to your vPar. When deleting, the specific range is returned to the pool of total CLM or ILM memory assigned to the vPar. Hewlett-Packard recommends that users configure specific memory ranges only when required for performance reasons. In other situa- tions, specify only total memory and allow the monitor to manage the actual ranges allocated. Command Examples If more than one task is specified in a command, they are processed in the order (left-to-right) in which they are encountered on the com- mand line. Some tasks will affect the outcome of others. Here is an example of correct usage, as well as counterexamples within the description. At creation time, before any options are processed, min is equal to as is num. Assume that the default max is sufficiently high, and that the specified resources are available for allocation. succeeds because num(2) is within the range of the min and the max. then succeeds because num(2) is still within the required range. Note that if the two options were reversed the command would return an error due to left-to-right option processing, and the desired min would exceed the default num. Finally, the specification of the two CPUs at explicit paths and succeeds because we have previously assigned two non-cell-specific CPUs for them to replace. Note that without the first two options, the option would fail, because there would only be room for one user-assigned CPU. The allocation of 128 MB of specific memory at address succeeds only because the total allocated memory was first set to 1280 MB. The 128 MB is taken from that 1280 MB; no new memory is added as a result of the option. The following command adds two non-CLP CPUs to a vPar that has the Static attribute set. The Static attribute is then restored. Table III. Detailed resource specifications +-------------+------------------------------------------------+ |Explanation | Adds num CLPs from cell cell_id to the | | | vPar's configuration. | +-------------+------------------------------------------------+ |Values | cell_id: A positive integer or 0 | | | num: A positive integer | +-------------+------------------------------------------------+ |Usage | If the target vPar is in an | |Restrictions | alternate database file: | | | o Total number of CPUs <= max | | | | | | In addition, if the target vPar is in the | | | live monitor database: | | | o cell_id must exist in the configuration, | | | o num CPUs must exist on the cell, | | | o They must be available (not assigned to | | | any vPar). | | | o Assignment must not cause iCAP's | | | Intended Active number to be | | | exceeded. | +-------------+------------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Assigns a CPU resource at a specific path to the | | | vPar's configuration. | +-------------+-------------------------------------------------------+ |Value | A text string of the form returned by the | | | ioscan command, such as "0/13" | +-------------+-------------------------------------------------------+ |Usage | If the vPar is Down or in an alternate database, | |Restrictions | a non-CLP must have been previously specified. | | | This CPU replaces the non-CLP. | | | | | | In addition, if the monitor is running: | | | o A CPU must exist at path, | | | o It must be assigned to the target vPar, or it | | | must be available (not assigned to any vPar). | | | o If the vPar is Up, addition of the CPU must | | | not cause the total to exceed max. | | | o If the vPar is Up, the addition must not | | | cause iCAP's Intended Active number | | | to be exceeded. | +-------------+-------------------------------------------------------+ |Usage | If the vPar is not Up, the addition does not | |Guidelines | increase the number of total CPUs allocated to | | | the vPar. Instead, it replaces a non-CLP which has | | | been allocated (reserved) by the monitor. | | | | | | If the vPar is Up, and the CPU has been assigned by | | | the monitor, this operation converts it to a user- | | | specified CPU without increasing the total CPU count. | | | | | | If the vpar is Up, the CPU is Available in the | | | monitor, and the addition is authorized by iCAP, | | | it is added to the vPar as a user-specified | | | CPU, and the total CPU count is incremented. | | | | | | Hewlett-Packard recommends that users configure | | | specific CPUs only when required for performance | | | reasons. In other situations, specify only the | | | total number of CPUs (num), and allow the | | | monitor to manage the actual CPUs allocated. | +-------------+-------------------------------------------------------+ +-------------+--------------------------------------------------+ |Explanation | Adds num non-CLPs to the vPar's configuration. | | | The CPUs are drawn from a systemwide pool of | | | available CPUs. | +-------------+--------------------------------------------------+ |Value | A positive integer | +-------------+--------------------------------------------------+ |Usage | If the target vPar is in an | |Restrictions | alternate database file: | | | o Total number of CPUs <= max | | | | | | In addition, if the target vPar is in the | | | live monitor database: | | | o num CPUs must exist in the hard partition. | | | o They must be available (not assigned to | | | any vPar). | | | o Assignment must not cause iCAP's | | | Intended Active number to be exceeded. | +-------------+--------------------------------------------------+ +-------------+---------------------------------------------------+ |Explanation | Specifies the minimum and maximum number of | | | CPUs allowed for the vPar. This operation | | | does not allocate any CPUs, but specifies the | | | limits of other allocation tasks. | | | | | | Both min and max are optional. The default | | | min is platform-dependent but is currently = 1. | | | The default max is 32767 if creating a vPar in an | | | alternate database. If creating a vPar in the | | | monitor database, the default max is the total | | | number of active CPUs in the hard partition. | +-------------+---------------------------------------------------+ |Value | If specified, min and max must be positive | | | integers such that min <= total CPUs <= max. | +-------------+---------------------------------------------------+ |Usage | This option is allowed only in the vparcreate | |Restrictions | command. | | | | | | min cannot exceed the total number of CPUs. The | | | default total when the vPar is created is 1. Use | | | the -a cpu::num or the -a cell:cell_id:cpu::num | | | option to change the total before setting a min | | | other than 1. | | | | | | max cannot be less than the total. | +-------------+---------------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Adds the I/O resource at path to the vPar. | | | If attributes are specified, they are associated | | | with the resource. If the vPar already owns the | | | resource, any specified attributes are added to | | | its configuration. | | | | | | This option only adds any specified attributes. | | | The state of unspecified attributes is not changed. | +-------------+-------------------------------------------------------+ |Value | path: A text string of the form returned | | | by the ioscan command, | | | such as "0/0/6" | | | | | | attr: One or many of these case-insensitive | | | attribute strings ALTBOOT, TAPE | | | and BOOT. | | | If more than one are specified, then they | | | must be separated by a comma (","). | +-------------+-------------------------------------------------------+ |Usage | The target vPar must not be running. | |Restrictions | | | | The I/O resource must either be unassigned or | | | (when adding attributes to an already assigned | | | resource) be assigned to the target vPar. | +-------------+-------------------------------------------------------+ |Usage | At most one device can be assigned the ALTBOOT, | |Guidelines | TAPE and BOOT attributes. Assigning one of | | | these attributes to a device silently deletes it from | | | its former device, if any. | | | | | | Caution: You should assign attributes to appropriate | | | devices, but this is not checked. For example, | | | ALTBOOT and BOOT should be assigned to a disk or | | | DVD and TAPE should be assigned to a tape device. | | | Failure to do this may result in an unbootable | | | partition. | +-------------+-------------------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Specifies the increase, in megabytes rounded | | | upward to the next CLM granule multiple, in the | | | total amount of Cell Local Memory to be allocated | | | to the vPar. This memory is taken from | | | unspecified ranges of unassigned CLM on cell_id | | | when the vPar boots. | +-------------+-------------------------------------------------------+ |Values | cell_id: A positive integer or 0 | | | size: A positive 64-bit integer <= | | | (0x100000000000 - CLM granularity) | +-------------+-------------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | If the vPar is in the live monitor database, both the | | | cell and memory must physically exist and be | | | available after the memory requirements of all | | | other virtual partitions have been satisfied. | | | | | | If the vPar is in an alternate database file, | | | the assignment always succeeds. The amount | | | of memory actually allocated if the database | | | is loaded into the monitor may be less if | | | some or all of it is needed in other virtual | | | partitions, or 0 if cell_id does not | | | exist. | +-------------+-------------------------------------------------------+ +-------------+------------------------------------------------+ |Explanation | Specifies the increase, in megabytes rounded | | | upward to the next ILM granule multiple, in | | | the total amount of ILM to be allocated to the | | | vPar. This memory is taken from unspecified | | | ranges of unassigned ILM when the vPar boots. | +-------------+------------------------------------------------+ |Values | size: A positive 64-bit integer <= | | | (0x100000000000 - ILM granularity) | +-------------+------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | If the vPar is in the live monitor database, | | | this memory must physically exist and be | | | available after the memory requirements of | | | all other virtual partitions have been | | | satisfied. | | | | | | If the vPar is in an alternate database file, | | | the assignment always succeeds. The amount | | | of memory actually allocated if the database | | | is loaded into the monitor may be less if | | | some or all of it is needed in other virtual | | | partitions. | +-------------+------------------------------------------------+ +-------------+---------------------------------------------------------+ |Explanation | Specifies an explicit address space of memory | | | starting at base bytes and extending for | | | range megabytes. If the target vPar is in the | | | live monitor database, both quantities are | | | rounded upward as required to be aligned on a granule | | | boundary. | +-------------+---------------------------------------------------------+ |Values | base: An unsigned 64-bit integer <= | | | (0x1000000000000000 - appropriate granularity) | | | range: A positive 64-bit integer <= | | | (0x100000000000 - granularity) | +-------------+---------------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | No part of the range may be already owned by this | | | or another vPar. | | | | | | If the vPar is in the live monitor database, the entire | | | range (after rounding upward if necessary) must | | | exist in the system. | | | | | | The entire range must exist within one memory type. | | | CLM ranges can span cells. For base and range | | | calculations, use the granularity in effect for | | | the memory type of the address range. | | | | | | If the target vPar is Down, the total memory | | | allocated in specific ranges must not exceed | | | the vPar's memory size specification for | | | memory of that type. | | | | | | If the vPar is not in the live monitor database, base | | | must lie on either a CLM or ILM granule boundary, or | | | the command fails. | +-------------+---------------------------------------------------------+ |Usage | If the target vPar is Down, addition of specific | |Guidelines | memory ranges does not increase | | | the total amount of memory allocated to the vPar. | | | Any such memory is a part of that total amount. | | | | | | Caution: It is possible to specify memory ranges | | | and sizes such that none of the virtual partitions | | | will launch. Hewlett-Packard recommends that | | | users configure specific memory ranges only when | | | required for performance reasons. In other | | | situations, specify only total memory and allow | | | the monitor to manage | +-------------+---------------------------------------------------------+ +-------------+-----------------------------------------------+ |Explanation | Sets the total number of non-CLPs to num. | +-------------+-----------------------------------------------+ |Value | A positive integer | +-------------+-----------------------------------------------+ |Usage | If the vPar is in an alternate database file: | |Restrictions | o num must be between min and max. | | | | | | In addition, if the vPar is in the live | | | monitor database and num increases the total: | | | o num active CPUs must exist in the hard | | | partition. | | | o They must be available (not assigned to | | | any vPar). | | | o iCAP must authorize their addition. | +-------------+-----------------------------------------------+ +-------------+------------------------------------------------+ |Explanation | Sets the number of CLPs from cell cell_id | | | in the vPar's configuration to num. | | | | |Values | cell_id: A positive integer or 0 | | | num: A positive integer | +-------------+------------------------------------------------+ |Usage | If the vPar is in an alternate database file: | |Restrictions | o num must be between min and max. | | | | | | In addition, if the vPar is in the live | | | monitor database and num increases the total: | | | o num active CPUs must exist in the hard | | | partition. | | | o They must be available (not assigned to | | | any vPar). | | | o iCAP must authorize their addition. | | | | | | If the vPar is in the live monitor database | | | and num decreases the total: | | | o cell_id must exist in the configuration. | | | o num CPUs from cell_id must | | | currently be assigned to the vPar. | +-------------+------------------------------------------------+ +-------------+-----------------------------------------------+ |Explanation | Specifies the minimum and maximum number of | | | CPUs allowed for the vPar. This operation | | | does not allocate any CPUs, but specifies the | | | limits of other allocation tasks. | | | | | | You can change only min or max by not | | | specifying the other field. | +-------------+-----------------------------------------------+ |Value | If specified, min and max must be positive | | | integers such that min <= total CPUs <= max. | +-------------+-----------------------------------------------+ |Usage | min cannot exceed the total number of CPUs. | |Restrictions | | | | max cannot be less than the total. | +-------------+-----------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Changes the attributes of the resource to | | | those specified in the option. Omitted | | | attributes are removed from the attribute | | | set. To retain an attribute, it must be | | | specified. | +-------------+-------------------------------------------------------+ |Value | path: A text string of the form returned | | | by the ioscan command, | | | such as "0/0/6" | | | | | | attr: One or both of the case-insensitive | | | attribute strings ALTBOOT, TAPE and BOOT. | | | If more than one are specified, then they | | | are separated a comma (","). | +-------------+-------------------------------------------------------+ |Usage | The vPar must not be running. | |Restrictions | | | | The I/O resource must be assigned to the | | | target vPar. Only attributes may be modified. | +-------------+-------------------------------------------------------+ |Usage | At most one device can be assigned the ALTBOOT, | |Guidelines | TAPE and BOOT attributes. Assigning one of | | | these attributes to a device silently deletes it from | | | its former device, if any. | | | | | | Caution: You should assign attributes to appropriate | | | devices, but this is not checked. For example, | | | ALTBOOT and BOOT should be assigned to a disk and | | | TAPE should be assigned to a tape device. Failure to | | | do this may result in an unbootable partition. | +-------------+-------------------------------------------------------+ +-------------+----------------------------------------------------+ |Explanation | Specifies the total amount of ILM, in megabytes | | | rounded upward to the next ILM granule multiple, | | | to be allocated to the vPar. This memory is taken | | | from unspecified ranges of unassigned ILM when the | | | vPar boots. | +-------------+----------------------------------------------------+ |Value | size: A positive 64-bit integer <= | | | (0x100000000000 - ILM granularity) | +-------------+----------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | A decrease in total ILM allocation must not | | | result in a total less than that of all memory | | | allocated in specific ILM memory ranges. | | | | | | If the vPar is in the monitor database and the | | | specification results in an increased memory | | | allocation, the memory must physically exist | | | and be available after the memory requirements | | | of all other virtual partitions have been | | | satisfied. | | | | | | If the vPar is in an alternate database file | | | and total memory is increased, the assignment | | | always succeeds. The amount of memory actually | | | allocated if the database is loaded into the | | | monitor may be less if some or all of it is | | | needed in other virtual partitions. | +-------------+----------------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Specifies total amount of base or floating Cell | | | Local Memory, in megabytes rounded upward to the next | | | CLM granule multiple, from cell cell_id to be | | | allocated to the vPar. | +-------------+-------------------------------------------------------+ |Values | cell_id: A positive integer or 0 | | | size: A positive 64-bit integer <= | | | (0x100000000000 - CLM granularity) | +-------------+-------------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | If the specification results in a decrease, | | | the vPar must own at least the specified amount | | | after rounding) of CLM located on cell cell_id. | | | | | | The decrease must not result in a total less than | | | that of all CLM allocated to the vPar in specific | | | memory ranges. | | | | | | If the vPar is in the monitor database and the | | | specification results in an increased memory | | | allocation, the memory must physically exist | | | and be available after the memory requirements | | | of all other virtual partitions have been | | | satisfied. | | | | | | If the vPar is in an alternate database file | | | and total memory is increased, the assignment | | | always succeeds. The amount of memory actually | | | allocated if the database is loaded into the | | | monitor may be less if some or all of it is | | | needed in other virtual partitions. | +-------------+-------------------------------------------------------+ +-------------+------------------------------------------------+ |Explanation | Deletes num CLPs on cell cell_id from the | | | vPar's configuration. | +-------------+------------------------------------------------+ |Values | cell_id: A positive integer or 0 | | | num: A positive integer | +-------------+------------------------------------------------+ |Usage | If the target vPar is in an alternate | |Restrictions | database file: | | | o Total number of CPUs >= min | | | o num CPUs from cell_id must | | | currently be assigned to the vPar. | | | | | | In addition, if the target vPar is in the | | | live monitor database: | | | o cell_id must exist in the configuration. | | | o num CPUs from cell_id must | | | currently be assigned to the vPar. | +-------------+------------------------------------------------+ +-------------+--------------------------------------------------+ |Explanation | Releases the path binding of a CPU at the | | | specified hardware path, or deletes the CPU | | | from the vPar. | +-------------+--------------------------------------------------+ |Value | A text string of the form returned by the | | | ioscan command, such as "0/13" | +-------------+--------------------------------------------------+ |Usage | If the vPar is Down, the CPU must have been | |Restrictions | previously assigned by path to the | | | vPar using the -a cpu:path option. | | | | | | If the vPar is Up: | | | o A CPU must exist at path, | | | o It cannot be the boot processor, | | | o Deleting the CPU cannot lower the total | | | CPU count below min. | +-------------+--------------------------------------------------+ |Usage | If the vPar is Down, the deletion does not | |Guidelines | reduce the number of total CPUs assigned to | | | the vPar. Instead, the CPU becomes a non-CLP, | | | meaning any CPU can be assigned by the monitor | | | when the vPar next boots. | | | | | | If the vPar is Up, the CPU is deleted from the | | | vPar, unless it is the boot processor, or the | | | deletion would reduce total CPU count below | | | min. The CPU need not have been | | | user-assigned by path. | | | | | | Hewlett-Packard recommends that users configure | | | specific CPUs only when required for performance | | | reasons. In other situations, specify only the | | | total number of CPUs (num) and allow the | | | monitor to manage the actual CPU allocation. | +-------------+--------------------------------------------------+ +-------------+--------------------------------------------+ |Explanation | Deletes num non-CLPs from the vPar's total | | | configuration. | +-------------+--------------------------------------------+ |Value | A positive integer | +-------------+--------------------------------------------+ |Usage | The vPar must be assigned at least num | |Restrictions | non-CLP, non-user-specified CPUs. | | | | | | The new total number of CPUs >= min | +-------------+--------------------------------------------+ +-------------+-------------------------------------------------------+ |Explanation | Removes the specified attributes of the resource | | | leaving any previously assigned attributes | | | unchanged and the resource itself assigned to the | | | vPar. If no attribute is specified, removes the | | | resource and all its attributes. | +-------------+-------------------------------------------------------+ |Value | path: A text string of the form returned | | | by the ioscan command, | | | such as "0/0/6" | | | | | | attr: One or both of the case-insensitive | | | attribute strings ALTBOOT, TAPE and BOOT. | | | If more than one are specified, then they | | | must be separated by a comma (","). | +-------------+-------------------------------------------------------+ |Usage | The vPar must not be running. | |Restrictions | | | | The I/O resource must be assigned to the target vPar. | +-------------+-------------------------------------------------------+ |Usage | Deleting an attribute from an I/O device does | |Guidelines | not cause it to be assigned to another. You | | | must do that in a separate option or command. | | | | | | At most one device can be assigned the ALTBOOT, TAPE | | | and BOOT attributes. | | | | | | Caution: You should assign attributes to appropriate | | | devices, but this is not checked. For example, | | | ALTBOOT and BOOT should be assigned to a disk and | | | TAPE should be assigned to a tape device. Failure to | | | do this may result in an unbootable partition. | +-------------+-------------------------------------------------------+ +-------------+----------------------------------------------------------+ |Explanation | Specifies the decrease, in megabytes rounded | | | upward to the next CLM granule multiple, in the | | | total amount of base or floating Cell Local Memory to be | | | allocated from cell cell_id to the vPar. | +-------------+----------------------------------------------------------+ |Values | cell_id: A positive integer or 0 | | | size: A positive 64-bit integer <= | | | (0x100000000000 - CLM granularity) | +-------------+----------------------------------------------------------+ |Usage | The target vPar can be Up or Down. | |Restrictions | | | | The vPar must own at least the specified amount | | | after rounding) of CLM located on cell cell_id. | | | | | | The decrease must not result in a total less than | | | that of all CLM allocated to the vPar in specific | | | memory ranges. | +-------------+----------------------------------------------------------+ +-------------+-------------------------------------------------+ |Explanation | Specifies the decrease, in megabytes rounded | | | upward to the next ILM granule multiple, in | | | the total amount of ILM to be allocated | | | to the vPar. | +-------------+-------------------------------------------------+ |Values | size: A positive 64-bit integer <= | | | (0x100000000000 - ILM granularity) | +-------------+-------------------------------------------------+ |Usage | The vPar can be Up or Down. | |Restrictions | | | | The vPar must own at least the specified amount | | | (after rounding) of ILM. | | | | | | The decrease must not result in a total less | | | than that of all ILM allocated in specific | | | memory ranges. | +-------------+-------------------------------------------------+ +-------------+--------------------------------------------------------+ |Explanation | De-assigns an explicit address space of memory | | | starting at base bytes and extending for | | | range megabytes. Both quantities are rounded | | | upward as required to be aligned on a granule | | | boundary. If rounding is required, the granularity | | | used is that of the memory type (CLM or ILM) | | | determined by the specified base. | +-------------+--------------------------------------------------------+ |Values | base: An unsigned 64-bit integer <= | | | (0x1000000000000000 - appropriate granularity) | | | range: A positive 64-bit integer <= | | | (0x100000000000 - granularity) | +-------------+--------------------------------------------------------+ |Usage | The vPar can be Up or Down. | |Restrictions | | | | The vPar must own the entire range. | | | | | | Either the start or end point of the | | | specified range must match the start or end | | | point of an existing range. | +-------------+--------------------------------------------------------+ |Usage | If the vPar is Down, de-assigning specific memory | |Guidelines | ranges does not decrease | | | the total amount of memory allocated to the vPar. | | | | | | Caution: It is possible to specify memory ranges | | | and sizes such that none of the virtual partitions | | | will launch. | | | Hewlett-Packard recommends that users configure | | | specific memory ranges only when required for | | | performance reasons. In other situations, specify | | | only total memory and allow the monitor to manage | | | the actual ranges allocated. | +-------------+--------------------------------------------------------+ Table IV. Hardware Path Specifications Beginning with vPars A.02.02, the way to specify hardware paths has changed. This was done so that older vPars configuration databases remain compatible with additional hardware that is being supported. For example, given a path whose sequential digits are it is not possi- ble to determine whether this path means a device at or a device at The former structure is and the latter structure is where pci_bridge has the format Therefore, the following rules have been created. These rules apply when using either Virtual Partition Manager or the command-line interface. When entering a legacy hardware path, the sequence and number of slashes and dots in the hardware path that you input determines the resul- tant hardware path as follows: +------------------------+---------+------------------------------+ | | | What the vPars commands will | |Path Format Description | Example | do with the entered path | +------------------------+---------+------------------------------+ |one or more occurrences | 0/1. | | |of both / and . | | Path will be padded | +------------------------+---------+------------------------------+ | | 1/0 | | |only / used | 1/0/1 | | +------------------------+---------+ Path will not be padded | | | 1.0 | | |only . used | 1.0. | | +------------------------+---------+------------------------------+ In the above table, padding means to pad using ".0" up to six elements after the first dot. For the example shown in the first line of the table, the resulting path, as displayed by will be EXAMPLES
If a path was entered using slashes and dots using pre-A.02.02 software, you cannot enter the same path format using A.02.02 or later soft- ware. You must enter the path using the exact same digits but with dots instead of slashes as delimiters. For example, if a path using A.02.01 software was entered as then would show the path as To do the same command above but using A.02.02 or later, the command would be To change the above path to be the ALTBOOT setting, the command is To change the above path to be the TAPE setting, the command is Using vPars A.02.02, when setting a path, you can either use one or more occurrences of the and in the path so that the resultant path is the correctly padded path (this path is the same as the path shown in the output) OR use the exact path, correctly padded, using only dots (this path is the same as the path shown in the output). In the former case above, the output for a combo-card (combination of SCSI and LAN PCI card) may show Then, the vPars command would be Note that this path of becomes correctly padded to according to the table above. Subsequently, the output would show this path as which can be used if you wish to cut and paste the path as in In the latter case above, the output for a combo-card may be Then, the vPars command would be SEE ALSO
ioscan(1M), parmgr(1M), parmodify(1M), vparadmin(1M), vparboot(1M), vparconfig(1M), vparcreate(1M), vpardump(1M), vparefiutil(1M), vparenv(1M), vparextract(1M), vparmodify(1M), vparreloc(1M), vparremove(1M), vparreset(1M), vparstatus(1M), vparutil(1M), icod(5), vparti- tion(5), vpmon(5). vparresources(5)