Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
fyi. This case is approved in today's psarc meeting.
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
I spoke to Chris and the case is amended for minor binding only. Chris will send out an update to the init(1M) manpage shortly. Thanks. On 01/27/10 11:39, Garrett D'Amore wrote: On 01/27/10 11:23 AM, Sherry Moore wrote: Thank you guys for the great work! When I filed 2008/382 I requested minor binding only. This case is requesting patch/micro release binding. Will the binding difference need to be reflected in case 2008/382? Will there be compatibility concerns as 2008/382 added devo_quiesce to dev_ops? Oh, I didn't see Patch binding. I'd like to retract my +1 if this is Patch. If its *Minor* binding, then I'm very happy. - Garrett Sherry On Tue, Jan 26, 2010 at 04:52:48PM -0800, Huay-Yong Wang wrote: I am sponsoring this fasttrack for Chris Kiick. This project implements fast reboot support for SPARC. Specifically, the -f and -p options in reboot(1M) is now supported on SPARC. Previously these options are only available for x86 platforms (See PSARC 2008/382 Fast Reboot) Note that the -e option (boot environments) is not yet supported on SPARC. This project introduces no new interface and I believe this qualify as self-review. I will be marking the case closed approved automatic. If anyone feels that this need to be promoted to a fast track please let me know. The project team is requesting a patch/micro release binding. An updated reboot(1M) manpage is included here. --- cut here --- System Administration Commands reboot(1M) NAME reboot - restart the operating system SYNOPSIS /usr/sbin/reboot [-dlnq] [-f | -p] [boot_arguments] /usr/sbin/reboot [-f [-e environment] | -p] [-dlnq] [boot_arguments] DESCRIPTION The reboot utility restarts the kernel. The kernel is loaded into memory by the PROM monitor, which transfers control to the loaded kernel. On x86 systems, when the -f flag is specified, the running kernel will load the next kernel into memory, then transfer control to the newly loaded kernel. This form of reboot is shown in the second synopsis, above. Although reboot can be run by the super-user at any time, shutdown(1M) is normally used first to warn all users logged in of the impending loss of service. See shutdown(1M) for details. The reboot utility performs a sync(1M) operation on the disks, and then a multi-user reboot is initiated. See init(1M) for details. On x86 systems, reboot may also update the boot archive as needed to ensure a successful reboot. The reboot utility normally logs the reboot to the system log daemon, syslogd(1M), and places a shutdown record in the login accounting file /var/adm/wtmpx. These actions are inhibited if the -n or -q options are present. Normally, the system reboots itself at power-up or after crashes. OPTIONS The following options are supported: -d Force a system crash dump before rebooting. See dumpadm(1M) for information on configuring system crash dumps. SunOS 5.11 Last change: 26 Jan 20101 System Administration Commands reboot(1M) -e If -f is present, reboot to the specified boot environ- ment. This option is currently available only on x86 systems. -f For x86 systems: Fast reboot, bypassing firmware and boot loader. The new kernel will be loaded into memory by the running kernel, and control will be transferred to the newly loaded ker- nel. If disk or kernel arguments are specified, they must be specified before other boot arguments. For SPARC systems: Speeds up rebooting by skipping some POST tests. The service svc:/system/boot-config:default is enabled by default. It requires solaris.system.shutdown as action_authorization and value_authorization. When the config/fastreboot_default property is set to true, reboot will behave as reboot -f. The value of this pro- perty can be changed using svccfg(1M) and svcadm(1M), to control the default reboot behavior. See EXAMPLES for details. -l Suppress sending a message to the system log daemon, syslogd(1M) about who executed reboot. -n Avoid calling sync(2) and do not log the reboot to syslogd(1M) or to /var/adm/wtmpx. The kernel still attempts to sync filesystems prior to reboot, except if the -d option is also present. If -d is used with -n, the kernel does not attempt to sync file systems. -p
SPARC support for Fast Reboot [PSARC/2010/030 Self Review]
I am sponsoring this fasttrack for Chris Kiick. This project implements fast reboot support for SPARC. Specifically, the -f and -p options in reboot(1M) is now supported on SPARC. Previously these options are only available for x86 platforms (See PSARC 2008/382 Fast Reboot) Note that the -e option (boot environments) is not yet supported on SPARC. This project introduces no new interface and I believe this qualify as self-review. I will be marking the case closed approved automatic. If anyone feels that this need to be promoted to a fast track please let me know. The project team is requesting a patch/micro release binding. An updated reboot(1M) manpage is included here. --- cut here --- System Administration Commands reboot(1M) NAME reboot - restart the operating system SYNOPSIS /usr/sbin/reboot [-dlnq] [-f | -p] [boot_arguments] /usr/sbin/reboot [-f [-e environment] | -p] [-dlnq] [boot_arguments] DESCRIPTION The reboot utility restarts the kernel. The kernel is loaded into memory by the PROM monitor, which transfers control to the loaded kernel. On x86 systems, when the -f flag is specified, the running kernel will load the next kernel into memory, then transfer control to the newly loaded kernel. This form of reboot is shown in the second synopsis, above. Although reboot can be run by the super-user at any time, shutdown(1M) is normally used first to warn all users logged in of the impending loss of service. See shutdown(1M) for details. The reboot utility performs a sync(1M) operation on the disks, and then a multi-user reboot is initiated. See init(1M) for details. On x86 systems, reboot may also update the boot archive as needed to ensure a successful reboot. The reboot utility normally logs the reboot to the system log daemon, syslogd(1M), and places a shutdown record in the login accounting file /var/adm/wtmpx. These actions are inhibited if the -n or -q options are present. Normally, the system reboots itself at power-up or after crashes. OPTIONS The following options are supported: -d Force a system crash dump before rebooting. See dumpadm(1M) for information on configuring system crash dumps. SunOS 5.11 Last change: 26 Jan 20101 System Administration Commands reboot(1M) -e If -f is present, reboot to the specified boot environ- ment. This option is currently available only on x86 systems. -f For x86 systems: Fast reboot, bypassing firmware and boot loader. The new kernel will be loaded into memory by the running kernel, and control will be transferred to the newly loaded ker- nel. If disk or kernel arguments are specified, they must be specified before other boot arguments. For SPARC systems: Speeds up rebooting by skipping some POST tests. The service svc:/system/boot-config:default is enabled by default. It requires solaris.system.shutdown as action_authorization and value_authorization. When the config/fastreboot_default property is set to true, reboot will behave as reboot -f. The value of this pro- perty can be changed using svccfg(1M) and svcadm(1M), to control the default reboot behavior. See EXAMPLES for details. -l Suppress sending a message to the system log daemon, syslogd(1M) about who executed reboot. -n Avoid calling sync(2) and do not log the reboot to syslogd(1M) or to /var/adm/wtmpx. The kernel still attempts to sync filesystems prior to reboot, except if the -d option is also present. If -d is used with -n, the kernel does not attempt to sync file systems. -p Reboot to prom. This flag can be used to reboot the sys- tem through firmware without changing the default reboot SunOS 5.11 Last change: 26 Jan 20102 System Administration Commands reboot(1M) behavior as denoted by the config/fastreboot_default property setting in system/boot-config service. The -p and -f options are mutually exclusive. -q Quick. Reboot quickly and ungracefully, without shutting down running processes first. OPERANDS The following operands are supported: boot_arguments An optional boot_arguments specifies arguments to the uadmin(2) function that are passed to the boot program and kernel upon restart. The form and list of arguments is described in the boot(1M) and kernel(1M) man
Logical Domains Information API and ldminfo [PSARC/2010/004 FastTrack timeout 01/14/2010]
I am sponsoring this fasttrack for Michael Christensen. The project team is requesting a patch/micro release binding. The 3 manpages (ldminfo.1m, libldom.3lib ldoms_capabilities.3ldoms) and the libldoms.h include file are placed in the case directory. The timer is set to expire on 1/14/10. --- 1. Introduction 1.1 Project/Component Working Name Logical Domains Information API and ldminfo program 1.2 Name of Document Author/Supplier Michael Christensen 1.3 Date of This Document 18-DEC-2009 1.4 Name of Major Document Customer(s)/Consumer(s) 1.4.1 The PAC or CPT you expect to review your project 1.4.2 The ARC(s) you expect to review your project PSARC 1.4.3 The Director/VP who is sponsoring this project jerriann.meyer at sun.com 1.4.4 The Name of Your Business Unit Solaris Core OS 1.5 Email Aliases 1.5.1 Responsible Manager: jay.jayachandran at sun.com 1.5.2 Responsible Engineer: michael.christensen at sun.com 1.5.3 Marketing Manager:duncan.hardie at sun.com 1.5.4 Interest List:ldoms-internal at sun.com 2. Project Summary 2.1 Project Description This project will implement Logical Domains Information API and ldminfo program on Solaris. The API and ldminfo program will provide information about the currently running domain. Among the items that may be provided are: - Domain type (control, guest, I/O, service, root) - LDom Manager's LDom name for this domain (Domain name) - Domain Universally Unique ID (UUID) - Domain's control domain network nodename - Chassis Serial Number the domain is running on. None of the above items are currently easily obtainable from within a guest domain. As an example, many customers have expressed a desire to run LDom manager scripts on the control domain initiated from a guest domain. However, there is no easy way to either identify the network nodename of the control domain or to identify the LDom Manager's name for the current domain, which would be required for LDom Manager commands. Further, many customers have requested a means of uniquely identifying each domain and also identifying the hardware platform that the domain is running on for accounting or resourcing. On the Solaris operating system, the Logical Domains Information API will be implemented as a library (libldoms) using information from the Guest Domain's Machine Description provided by FWARC 2005/115 (sun4v machine description), the sun4v MD uuid property from FWARC 2009/680 (Domain UUID property), the libds library provided by PSARC 2008/568 (Logical Domain's Domain Services) and using domain services provided by the logical domain agent daemon provided by PSARC 2009/459 (Logical Domains Agents on Solaris) and FWARC 2009/426 (Logical Domains Agents). The ldminfo program will utilize the libldoms library to display the various items of information provided. 2.2 Risks and Assumptions None. 3. Business Summary 3.1 Problem Area In an LDoms system, a user program or user has no easy way to identify what type of domain the program is being run on (e.g. control domain, guest domain, I/O domain, service domain). Also a guest domain has no easy way to identify the network nodename of its control domain, what name the LDoms Manager running on the control domain uses to identify this domain, what is the domain's Universally Unique Identifier that The LDoms Manager uses to identify this domain or what the Chassis Serial Number of the platform it is currently running on. 3.2 Market/Requestor See FWARC 2005/633. 3.3 Business Justification See FWARC 2005/633. 3.4 Competitive Analysis The problems listed in 3.1 have been the subject of bug reports from customers. Virtualization solutions provided by competitors have equivalent functionality. 3.5 Opportunity Window/Exposure See FWARC 2005/663. 3.6 How will you know when you are done? The work will be completed when the final code changes to implement Logical Domains Information API and ldminfo program are integrated into the Solaris Nevada gate and Solaris 10 Update gates. 4. Technical Description 4.1 Overview On the Solaris operating system, Logical Domains Information API will be implemented as a user library libldoms.so.1 and a user program ldminfo will be provided to display this information. This information will be provided either via the sun4v Machine Description (FWARC/2005/115 and FWARC 2009/680)
Sun4v faulted SP events extension [PSARC/2009/389 Self Review]
I am sponsoring this case for Anthony Yznaga. This case seeks Patch binding for a Solaris Update release. The case delivers extension to support Sun4v faulted SP events and is a minor extension to the existing PSARC/2008/744 case. I am filing this case as self-review and is marking it Closed Approved Automatic. If any ARC members have questions or believe that the case is above the automatic approval threshold, please let me know and I'll put a timer on it. Sun Proprietary: Need-to-Know 1. Introduction 1.1. Project/Component Working Name: Sun4v faulted SP events extension 1.2. Name of Document Author/Supplier: Anthony Yznaga 1.3. Date of This Document: June 9 2009 4. Technical Description: Exported Hardware Component NameDescriptionStability ------ spa service processorSun Private Exported InterfaceStability ----- sun4v faulted SP Events Sun Private The Event definitions themselves will be archived persistently in the FMA Event Registry. An 'ercheck' summary of the new events is included in the case directory as events_summary.html and the approved FMA portfolio information can be found here: http://wikihome.sfbay.sun.com/fma-portfolio/Wiki.jsp?page=2009.011.faultedSP 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Libvirt APIs for relative paths [PSARC/2008/577 FastTrack timeout 09/22/2008]
resending to psarc-ext I am sponsoring this project for Ryan Scott. The timer for this fasttrack is set to expire 9/22/08. libvirt Relative Paths == 1. Background A domU under xVM can be effectively described by an XML file describing the machine, and a disk image containing the root disk. Libvirt and virsh(1M) provide (among other services) printing the XML description of the domU and defining a new domU based on that API. These descriptions currently provide the full path to the root disk. While this works well with a single domU, the problem comes when trying to copy a domU to a different path on a machine or to a separate machine. The path to the root disk often must change. Currently, this requires manually editing the XML description. 2. Relative Paths This RFE will introduce two libvirt APIs to allow relative paths in the XML description, as well as a base path for the relative paths. 3. Library Interfaces char *virDomainGetRelativeXMLDesc(virDomainPtr domain, int flags, const char *relPath); Similar to virDomainGetXMLDesc(), except with a new relPath argument. All disk descriptions in the XML will be relative to this path. virDomainPtr virDomainDefineRelativeXML(virConnectPtr conn, const char *xml, const char *relPath); Similar to virDomainDefineRelativeXML(), but the relPath argument is new. When creating a domain, xml may contain relative paths, which will be defined relative to relPath. 4. virsh(1M) Command Line Changes Both 'virsh dumpxml' and 'virsh define' will grow --relative-path arguments: # virsh dumpxml --relative-path /export/guests file.xml # virsh define file.xml --relative-path /expor/guests Example usage: # virsh dumpxml solaris-pv-0 [snip] disk type='file' device='disk' driver name='file'/ source file='/export/guests/disks/solaris-pv-0.img'/ target dev='0'/ /disk [snip] # virsh dumpxml solaris-pv-0 --relative-path /export/guests/ [snip] disk type='file' device='disk' driver name='file'/ source file='./disks/solaris-pv-0.img'/ target dev='0'/ /disk [snip] # virsh define /export/guests/xml/solaris-pv-0.xml.rel --relative-path /export/guests Domain solaris-pv-0 defined from /export/guests/xml/solaris-pv-0.xml.rel # virsh dumpxml solaris-pv-0 [snip] disk type='file' device='disk' driver name='file'/ source file='/export/guests/disks/solaris-pv-0.img'/ target dev='0'/ /disk [snip] Diffs to virsh(1M) will be deposited in the case directory. 5. Interface Stability - | Interface | Stability | Comments | +---+---+---+ | virDomainGetRelativeXMLDesc | Committed | | | virDomainDefineRelativeXML| Committed | | | virsh(1M) --relative-path | Committed | | |options| | | +---+---+---+ 6. Manual pages Diffs of new virsh.1m proposed. *** virsh.1m.orig Tue Sep 9 13:28:10 2008 --- virsh.1m.newTue Sep 9 13:52:29 2008 *** *** 175,184 Directly editing XML configuration is not recommended. ! define file Define (but do not start) a domain from the specified !XML file. destroy domain --- 175,186 Directly editing XML configuration is not recommended. ! define file [--relative-path path] Define (but do not start) a domain from the specified !XML file. If the disk paths in the XML contain relative !paths, the domain will be created with those paths relative !to path, if provided. destroy domain *** *** 236,247 file specified by file for analysis. ! dumpxml domain Output the configuration of the given domain in XML for- mat. Captured in a file, this data can be used as the argument to a subsequent create subcommand. list [domain...] --- 238,252 file specified by file for analysis. ! dumpxml domain [--relative-path path] Output the configuration of the given domain in XML for- mat. Captured in a file, this data can be used as the argument to a subsequent create subcommand. +By default, all paths in the XML will be absolute. Adding +the --relative-path option will make all disk paths relative +to path. list [domain...] 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
PSARC/2008/098 Lockstat: Changing spin count to spin time
This case was approved during the 2/20/08 PSARC meeting. I am marking this case approved and closed.
