From gjelinek@sac.sfbay.sun.com Fri Dec 12 06:18:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBCEID1k023108 for ; Fri, 12 Dec 2008 06:18:13 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBCEIASb014022; Fri, 12 Dec 2008 22:18:12 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBR0040HP2BN400@brm-avmta-1.central.sun.com>; Fri, 12 Dec 2008 07:18:11 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBR00KCFP2B4O80@brm-avmta-1.central.sun.com>; Fri, 12 Dec 2008 07:18:11 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBCEIBiQ056564; Fri, 12 Dec 2008 06:18:11 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBCEI91D023103; Fri, 12 Dec 2008 06:18:09 -0800 (PST) Received: (from gjelinek@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mBCEI9Si023099; Fri, 12 Dec 2008 06:18:09 -0800 (PST) Date: Fri, 12 Dec 2008 06:18:09 -0800 (PST) From: Gerald Jelinek Subject: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] To: PSARC-ext@sun.com Cc: gerald.jelinek@sun.com Message-id: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6731 I'm sponsoring this fast-track for myself. Thanks, Jerry Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: native zones p2v 1.2. Name of Document Author/Supplier: Author: Gerald Jelinek 1.3 Date of This Document: 12 December, 2008 4. Technical Description SUMMARY: This fast-track enhances the Solaris Zones [1] subsystem to address an existing RFE [2] requesting a "physical to virtual" (or p2v) capability for installing native-branded zones based on an existing system image. This capability is very similar to what already exists for solaris8 and solaris9 branded zones [3,4], which are installed using an archive of an existing system image, but in this case there is no brand module and the zone brand is 'native'. To the user, this simply looks like a new way to install a zone, using an image of a physical system. Patch binding is requested for this native p2v capability. The stability of these interfaces is documented in the interface table below. DETAILS: This new feature is primarily an extension to the native-brand zone installation code so that the zone can be installed using an archive of a system, as is already done with the solaris8 and solaris9 brands. However, because there is no brand module, part of the installation process uses the zone "update on attach" [5] feature to sync the zone image up so that it is usable as a native-branded zone on the system. Because "update on attach" does not allow zone downgrades, the system image being installed and p2v-ed must not be newer than the host OS release or the installation will fail with an error. The system image is intended to be from the same minor release as is running on the host system. That is, a nv system image for installing into an nv-based zone or an S10 system image for installing into an S10-based zone. We do not currently support updating an earlier system image (e.g. Solaris 8) into a zone. While zone 'update on attach' can currently update S10 images onto nv, its unclear how long that will continue to work as nv evolves. If the system image does not match the same minor release as is running in the global zone, the zone installation will result in an error. Hosting a zone from a different minor release is a different project [6] from this proposal. In addition to the "update on attach" during zone installation, there are a variety of other modifications which must be applied to the image so that it is usable within a zone. Again, this is very similar to what happens today with the solaris8 and solaris9 brands during installation. The image modifications that are automatically performed fall into the following areas: 1) SMF services that are not usable within a zone should be deleted or disabled as necessary. The information about which SMF services to disable is primarily driven by the manifests that are delivered in SVr4 pkgs with the SUNW_PKG_HOLLOW=true attribute. 2) Network configuration must be adjusted depending on if the zone is shared-stack or exclusive. 3) NFS serving must be disabled [7]. 4) The vfstab must be adjusted so that local file systems from the original system are disabled. 5) Any zones installed on the original system will be uninstalled and deleted from the image (zones do not nest). All of these modifications happen transparently as part of the zone installation, as is the case with the solaris8 and solaris9 brands. Information about all of these customizations to the zone is also logged into the zone's installation log file, which is saved as /var/tmp/{zonename}.install.{pid}.log. Depending on what the original system did, the sysadmin may need to perform other, manual, customizations to the zone after it has been installed. For example, the privileges assigned to the zone may need to be modified. This is not done automatically. Because not all system services work inside zones, not every physical system is a good candidate for migration into a zone. The main user-visible interfaces are new native-brand zone installation options. These options are the same as with the solaris8 and solaris9 brands. The native brand installer will accept the following new arguments: -a {path} - specifies a path to an archive to unpack into the zone -d {path} - specifies a path to a tree of files (representing a system's root) as the source for the installation. -p - preserve system configuration (either -p or -u required). -s - install silently -u - sys-unconfig(1M) the zone after installing it -v - verbose output from the install process The -a and -d options are mutually exclusive. The -p, -s, -u and -v options are only allowed when -a or -d is provided. If -a or -d is not given, then the zone is installed using the existing mechanism. As with the solaris8 and solaris9 brands, the archive can be a flar, cpio (optionally compressed), UFS dump, or pax (xustar) format. Also, as with the solaris8 and solaris9 brands, the zone must be configured as a whole-root zone to be installed using a system image. === Interface Table === Exported Interfaces Stability ---------------------------------------------------------------------- For the native brand brand-specific install options Committed documented in this case Imported Interfaces Stability ---------------------------------------------------------------------- flar(1m) Evolving svccfg(1M), svcadm(1M) Evolving [8] ______________________________________________________________________________ REFERENCES ______________________________________________________________________________ 1. PSARC 2002/174 Virtualization and Namespace Isolation in Solaris 2. 6667924 physical to virtual utility for native zones 3. PSARC/2007/350 Etude: Migration Technology 4. PSARC/2008/125 Etude Part Deux 5. PSARC/2007/621 zone update on attach 6. 6666646 Solaris 10 zones on OpenSolaris binary (supported) distributions 7. 4964859 RFE: Zones should be able to be NFS servers 8. PSARC 2002/547 Greenline 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 From carlsonj@phorcys.east.sun.com Fri Dec 12 09:40:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBCHenbD013839 for ; Fri, 12 Dec 2008 09:40:50 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBCHei8e024906 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Sat, 13 Dec 2008 01:40:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBR00J1NYFX2H00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 12 Dec 2008 09:40:45 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBR001BNYFWCGF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 12 Dec 2008 09:40:44 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBCHehAt027471; Fri, 12 Dec 2008 12:40:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBCHeh7j027468; Fri, 12 Dec 2008 12:40:43 -0500 (EST) Date: Fri, 12 Dec 2008 12:40:43 -0500 From: James Carlson Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> To: Gerald Jelinek Cc: PSARC-ext@sun.com Message-id: <18754.41499.51634.784604@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> Status: RO Content-Length: 483 Gerald Jelinek writes: > This fast-track enhances the Solaris Zones [1] subsystem to address an > existing RFE [2] requesting a "physical to virtual" (or p2v) capability > for installing native-branded zones based on an existing system image. +1 -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@sun.com Sun Dec 14 19:48:44 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBF3milW010711 for ; Sun, 14 Dec 2008 19:48:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBF3mf3N001136 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 14 Dec 2008 19:48:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBW00G0PFX64I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 14 Dec 2008 20:48:42 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBW004JHFX4D340@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 14 Dec 2008 20:48:41 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBF3meWa010879 for ; Mon, 15 Dec 2008 03:48:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBW00G01FUG4B00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 03:48:40 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBW00IZOFX20310@fe-emea-10.sun.com>; Mon, 15 Dec 2008 03:48:39 +0000 (GMT) Date: Mon, 15 Dec 2008 03:48:38 +0000 From: Darren J Moffat Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Gerald Jelinek Cc: PSARC-ext@sun.com, Gerald.Jelinek@sun.com Message-id: <4945D396.2050200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 157 What happens with the hostid on x86 ? when a p2v is done ? Does the hostid of the created zone match the hostid of the original host ? -- Darren J Moffat From Gerald.Jelinek@sun.com Mon Dec 15 06:34:07 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBFEY71X008633 for ; Mon, 15 Dec 2008 06:34:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBFEY3GU028264 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 15 Dec 2008 06:34:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBX00B199STOS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 06:34:05 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBX002AI9SSWMA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 06:34:04 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBFEY4fX012133 for ; Mon, 15 Dec 2008 14:34:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBX008019AA1900@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 07:34:04 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBX003WP9SQTB50@mail-amer.sun.com>; Mon, 15 Dec 2008 07:34:03 -0700 (MST) Date: Mon, 15 Dec 2008 07:34:02 -0700 From: Jerry Jelinek Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <4945D396.2050200@Sun.COM> Sender: Gerald.Jelinek@sun.com To: Darren J Moffat Cc: Gerald Jelinek , PSARC-ext@sun.com Message-id: <49466ADA.5010504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> <4945D396.2050200@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 586 Darren J Moffat wrote: > What happens with the hostid on x86 ? when a p2v is done ? Does the > hostid of the created zone match the hostid of the original host ? Darren, No, by default a zone's hostid is the same as the global zones hostid, unless the zone is configured to use a different hostid as per: PSARC/2008/647 Configurable Hostids for Non-Global Zones The hostid is more of a zone configuration issue so it is very possible that as part of the process of consolidating a physical system into a zone, you would want to configure the original hostid onto the zone. Jerry From Darren.Moffat@sun.com Mon Dec 15 14:40:33 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBFMeWbr027969 for ; Mon, 15 Dec 2008 14:40:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBFMeWxZ015215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 15 Dec 2008 14:40:32 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBX00307WBK8M00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 15:40:32 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBX00GNVWBI8E80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 15:40:31 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBFMeUAF016333 for ; Mon, 15 Dec 2008 22:40:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBX00G01W6EIS00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 22:40:30 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBX00151WBHJ620@fe-emea-10.sun.com>; Mon, 15 Dec 2008 22:40:30 +0000 (GMT) Date: Mon, 15 Dec 2008 22:40:29 +0000 From: Darren J Moffat Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <49466ADA.5010504@sun.com> Sender: Darren.Moffat@sun.com To: Jerry Jelinek Cc: Gerald Jelinek , PSARC-ext@sun.com Message-id: <4946DCDD.2080304@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> <4945D396.2050200@Sun.COM> <49466ADA.5010504@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 1174 Jerry Jelinek wrote: > Darren J Moffat wrote: >> What happens with the hostid on x86 ? when a p2v is done ? Does the >> hostid of the created zone match the hostid of the original host ? > > Darren, > > No, by default a zone's hostid is the same as the global zones > hostid, unless the zone is configured to use a different hostid > as per: > > PSARC/2008/647 Configurable Hostids for Non-Global Zones > > The hostid is more of a zone configuration issue so it is > very possible that as part of the process of consolidating > a physical system into a zone, you would want to configure > the original hostid onto the zone. Given this case is about physical to virtual I fully expected the hostid of the zone to match the physical machine in the default case. In fact I think I'd almost insist on that being the case unless you can explain why it is bad to do this (I can only see good from it as it eases the migration from apps running on the physical machine dependent on its hostid to running in the zone). I think requiring an explicit step to enable to hostid to machine when doing a p2v is unnecessary and will lead to confusion. -- Darren J Moffat From Gerald.Jelinek@sun.com Mon Dec 15 14:51:25 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBFMpOvh028309 for ; Mon, 15 Dec 2008 14:51:24 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBFMpN7a039408 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 15 Dec 2008 15:51:24 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBX00I09WTO9V00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 14:51:24 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBX007QAWTMHDC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 14:51:23 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBFMpMqq005955 for ; Mon, 15 Dec 2008 22:51:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBX00601WNOX600@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 15:51:22 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBX005ZKWT9C000@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 15:51:10 -0700 (MST) Date: Mon, 15 Dec 2008 15:51:09 -0700 From: Jerry Jelinek Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <4946DCDD.2080304@Sun.COM> Sender: Gerald.Jelinek@sun.com To: Darren J Moffat Cc: Jerry Jelinek , PSARC-ext@sun.com Message-id: <4946DF5D.1050901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> <4945D396.2050200@Sun.COM> <49466ADA.5010504@sun.com> <4946DCDD.2080304@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 2466 Darren J Moffat wrote: > Jerry Jelinek wrote: >> Darren J Moffat wrote: >>> What happens with the hostid on x86 ? when a p2v is done ? Does the >>> hostid of the created zone match the hostid of the original host ? >> >> Darren, >> >> No, by default a zone's hostid is the same as the global zones >> hostid, unless the zone is configured to use a different hostid >> as per: >> >> PSARC/2008/647 Configurable Hostids for Non-Global Zones >> >> The hostid is more of a zone configuration issue so it is >> very possible that as part of the process of consolidating >> a physical system into a zone, you would want to configure >> the original hostid onto the zone. > > Given this case is about physical to virtual I fully expected the hostid > of the zone to match the physical machine in the default case. In fact > I think I'd almost insist on that being the case unless you can explain > why it is bad to do this (I can only see good from it as it eases the > migration from apps running on the physical machine dependent on its > hostid to running in the zone). I think requiring an explicit step to > enable to hostid to machine when doing a p2v is unnecessary and will > lead to confusion. Darren, The sysadmin manages the zone configuration independently of the zone installation. While we could change the zone configuration to match what is being installed into the zone, that might mean that we would be changing something that the sysadmin had explicitly intended, so we never change the zonecfg. Instead, what we do is try to adapt the data inside the zone to match the configuration. For example, we don't change the zonecfg to match the IP address of the original system, instead we change the config files inside the zone to match the IP address that the sysadmin put on the zonecfg. We take a similar approach for the hostid. While changing the zonecfg for the hostid is obviously less drastic than changing some of the other properties, it seems clearer to tell the sysadmin that the zonecfg they explicitly set up is what is used. This is consistent with the way the S8 and S9 brands work. We don't change those zonecfgs to add the hostid of the original system, that is left to the sysadmin if that is what they really want. I think making a change so that the zonecfg is modified based on a zone install operation would be setting a bad precedent. I guess I'm curious if other ARC members feel differently. Thanks, Jerry From Darren.Moffat@sun.com Mon Dec 15 16:10:32 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBG0AW6A024064 for ; Mon, 15 Dec 2008 16:10:32 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBG0ARaa023133 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 15 Dec 2008 16:10:31 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBY00B1R0HJXV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:10:31 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBY00B6M0HHGS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:10:30 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBG0ATdX019245 for ; Tue, 16 Dec 2008 00:10:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBY00I010H24A00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Dec 2008 00:10:29 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBY007C00HG9U10@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 16 Dec 2008 00:10:29 +0000 (GMT) Date: Tue, 16 Dec 2008 00:10:28 +0000 From: Darren J Moffat Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <4946DF5D.1050901@sun.com> Sender: Darren.Moffat@sun.com To: Jerry Jelinek Cc: PSARC-ext@sun.com Message-id: <4946F1F4.8050407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> <4945D396.2050200@Sun.COM> <49466ADA.5010504@sun.com> <4946DCDD.2080304@Sun.COM> <4946DF5D.1050901@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081104) Status: RO Content-Length: 2853 Jerry Jelinek wrote: > Darren J Moffat wrote: >> Jerry Jelinek wrote: >>> Darren J Moffat wrote: >>>> What happens with the hostid on x86 ? when a p2v is done ? Does the >>>> hostid of the created zone match the hostid of the original host ? >>> >>> Darren, >>> >>> No, by default a zone's hostid is the same as the global zones >>> hostid, unless the zone is configured to use a different hostid >>> as per: >>> >>> PSARC/2008/647 Configurable Hostids for Non-Global Zones >>> >>> The hostid is more of a zone configuration issue so it is >>> very possible that as part of the process of consolidating >>> a physical system into a zone, you would want to configure >>> the original hostid onto the zone. >> >> Given this case is about physical to virtual I fully expected the >> hostid of the zone to match the physical machine in the default case. >> In fact I think I'd almost insist on that being the case unless you >> can explain why it is bad to do this (I can only see good from it as >> it eases the migration from apps running on the physical machine >> dependent on its hostid to running in the zone). I think requiring an >> explicit step to enable to hostid to machine when doing a p2v is >> unnecessary and will lead to confusion. > > Darren, > > The sysadmin manages the zone configuration independently of > the zone installation. While we could change the zone configuration > to match what is being installed into the zone, that might mean > that we would be changing something that the sysadmin had explicitly > intended, so we never change the zonecfg. Instead, what we do is try > to adapt the data inside the zone to match the configuration. For > example, we don't change the zonecfg to match the IP address of the > original system, instead we change the config files inside the zone > to match the IP address that the sysadmin put on the zonecfg. We > take a similar approach for the hostid. While changing the zonecfg > for the hostid is obviously less drastic than changing some of the > other properties, it seems clearer to tell the sysadmin that the > zonecfg they explicitly set up is what is used. This is consistent > with the way the S8 and S9 brands work. We don't change those zonecfgs > to add the hostid of the original system, that is left to the sysadmin > if that is what they really want. I think making a change so that > the zonecfg is modified based on a zone install operation would be > setting a bad precedent. I guess I'm curious if other ARC members > feel differently. I'm happy with that explanation. I think what is "wrong" here is the split between zonecfg and installation is a little at odds with a p2v conversion. However I don't think this case should attempt to address any of that. The case can go forward as specified as far as I'm concerned. -- Darren J Moffat From Gerald.Jelinek@Sun.COM Mon Dec 15 16:14:06 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBG0E53x017050 for ; Mon, 15 Dec 2008 16:14:06 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBG0E25N024861 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 16 Dec 2008 08:14:04 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBY00C130NEAH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:14:02 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBY00BDE0NEGO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:14:02 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBG0E1Tw004206 for ; Tue, 16 Dec 2008 00:14:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBY00G010DYKQ00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:14:02 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBY00HTY0NA1T80@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 15 Dec 2008 17:13:59 -0700 (MST) Date: Mon, 15 Dec 2008 17:13:58 -0700 From: Jerry Jelinek Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <4946F1F4.8050407@Sun.COM> Sender: Gerald.Jelinek@Sun.COM To: Darren J Moffat Cc: PSARC-ext@Sun.COM Message-id: <4946F2C6.6040605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> <4945D396.2050200@Sun.COM> <49466ADA.5010504@sun.com> <4946DCDD.2080304@Sun.COM> <4946DF5D.1050901@sun.com> <4946F1F4.8050407@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 460 Darren J Moffat wrote: > I'm happy with that explanation. I think what is "wrong" here is the > split between zonecfg and installation is a little at odds with a p2v > conversion. However I don't think this case should attempt to address > any of that. > > The case can go forward as specified as far as I'm concerned. Darren, Thanks for the response. This split can be awkward at times and this is certainly one of those cases. Thanks again, Jerry From Gerald.Jelinek@sun.com Fri Dec 19 07:45:25 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBJFjPUl007149 for ; Fri, 19 Dec 2008 07:45:25 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBJFjN35013808 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 19 Dec 2008 07:45:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KC40010BRROOZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 19 Dec 2008 07:45:24 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KC400M0QRRNWW20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Fri, 19 Dec 2008 07:45:23 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBJFjNjq008917 for ; Fri, 19 Dec 2008 15:45:23 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC400101QJ5PF00@mail-amer.sun.com> (original mail from Gerald.Jelinek@Sun.COM) for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 19 Dec 2008 08:45:23 -0700 (MST) Received: from [192.168.0.11] ([206.53.29.107]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC400MXYRRC8W30@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Fri, 19 Dec 2008 08:45:13 -0700 (MST) Date: Fri, 19 Dec 2008 08:45:12 -0700 From: Jerry Jelinek Subject: Re: native zones p2v [PSARC/2008/766 FastTrack timeout 12/18/2008] In-reply-to: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> Sender: Gerald.Jelinek@sun.com To: PSARC-ext@sun.com Message-id: <494BC188.4080706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200812121418.mBCEI9Si023099@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081023) Status: RO Content-Length: 97 This fast-track timed out with no objections, so I am marking it closed approved. Thanks, Jerry