A. Introduction

This case proposes a new facility for zones[1]: rename of non-global
zones.  Patch binding is requested for this facility.  The stability
of the interface is "evolving."

B. Motivation

Platinum Beta customers have requested this functionality [2].  We've also heard
this request on some public forums [3].   Additionally, this is a logical
extension to the zones management tools we provide today.  We expect that
customers will rename zones to track departmental organization changes or for
the repurposing of zones (for example in a shift from test to production
environments).

C. Zone Rename Details

Zone rename is exposed via the zonecfg command; the command is simply
extended such that 'zonename' becomes a settable attribute in the same
fashion as 'zonepath' or 'autoboot.'  This is probably best seen by example:

	$ zonecfg -z aaa
	zonecfg:aaa> set zonename=bbb
	zonecfg:bbb> commit
	zonecfg:bbb> info
	zonename: bbb
	zonepath: /tmp/z
	autoboot: false
	...

This is a straightforward and compatible extension to the zonecfg command.
Rename is permitted only when a zone is not running; while "live rename"
(i.e.  rename of an active zone) might in theory be possible, it would be quite
complex to implement and no customers have requested it.  To be precise:
only zones in the "configured", "incomplete" or "installed" states can be
renamed.

Rename is never allowed to an existing zone name:

	# zonecfg -z aaa
	zonecfg:aaa> 
	zonecfg:aaa> set zonename=bbb
	bbb: Zone name already in use
	zonecfg:aaa> 


One subtlety is the behavior of 'export' and 'info'.  The 'export' subcommand
produces a series of commands as follows:

	zonecfg:moo> export
	create -b
	set zonepath=/mmoooo
	...

'export' is *not* altered by this project to emit the zonename, as we expect
that customers may wish to do:

	zonecfg -z zone1 export | zonecfg -z zone2 

If 'set zonename=zone1' were part of the export, then the import to zone2 would
not work properly, since both zones would have the same name, which is illegal.

The 'info' command (shown earlier) *is* updated by this project, so that the
zone name is emitted; this is a signal to the user that this is eligible for
editing; it is possible that some consumers which parse the output of 'info'
could break if they depended on the exact output order of fields.  If this risk
is deemed unacceptable, this could be omitted from the output of 'info'.  The
project team analyzed the 'webmin' source code and determined that webmin is not
negatively affected by this change.

A second subtlety is the behavior of the 'revert' command.  In the event that
the zone is renamed, 'revert' will revert back to the previous zone name if the
configuration has not yet been committed.  In other words:

	zonecfg:moo> set zonename=newzonename
	zonecfg:newzonename> revert
	Are you sure you want to revert (y/[n])? y
	zonecfg:moo> 

As with other zonecfg interactions, no changes are made on-disk until the
'commit' command is used.


Appendix A. References:

1. <a href="../../2002/174">PSARC 2002/174 Virtualization and Namespace Isolation in Solaris</a>
2. <a href="http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022506">http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5022506</a>
3. <a href="http://forum.sun.com/thread.jspa?threadID=21944&messageID=66544">http://forum.sun.com/thread.jspa?threadID=21944&messageID=66544</a>