Hi Edward, See comments and questions below inline:
1. Section C.0 > ... That said, nothing in this proposal should not prevent us from adding > support for... That "not" before "prevent" is superfluous. 2. Section C.1.i How many instances of "rootzpool" and "zpool" resources is permitted? IMO "zero or one" for "rootzpool" and "zero or more" for "zpool" is enough. 3. Section C.1.iii > The newly created or imported root zpool will be named after the zone to > which it is associated, with the assigned name being "<zonename>_rpool". What if zone name is changed later? Will the name of the zpool change as well? It is not clear how the association with the zpool will be maintained if its name will not change. > This zpool will then be mounted on the zones zonepath and then the > install process will continue normally[07]. > > XXX: use altroot at zpool creation or just manually mount zpool? What will happen on zoneadm move? IMO the zones framework have to remount the zpool in the new location. > If the user has specified a "zpool" resource, then the zones framework > will configure, initialize, and/or import it in a similar manner to a > zpool specified by the "rootzpool" resource. The key differences are > that the name of the newly created or imported zpool will be > "<zonename>_<name>". What if zone name or zpool resource name is changed later? Will the name of the zpool change as well? It is not clear how the association with the zpool will be maintained if its name will not change. 4. Section C.1.viii > Since zoneadm(1m) clone will be enhanced to support cloning between > encapsulated root zones and un-encapsulated root zones, zoneadm(1m) > clone will be documented as the recommended migration mechanism for > users who which to migrate existing zones from one format to another. "users who which" -> "users who wish" 5. Section C.5 > For RAS purposes,... What is RAS? > Here's some examples of how this lofi functionality could be used > (outside of the zone framework). If there are no lofi devices on > the system, and an admin runs the following command: > lofiadm -a -l /export/xvm/vm1.disk > > they would end up with the following device: > /dev/lofi/dsk0/p# - for # == 0 - 4 > /dev/lofi/dsk0/s# - for # == 0 - 15 > /dev/rlofi/dsk0/p# - for # == 0 - 4 > /dev/rlofi/dsk0/s# - for # == 0 - 15 > > If there are no lofi devices on the system, and an admin runs the > following command: > lofiadm -a -v /export/xvm/vm1.vmdk > > they would end up with the following device: > /dev/lofi/dsk0/p# - for # == 0 - 4 > /dev/lofi/dsk0/s# - for # == 0 - 15 > /dev/rlofi/dsk0/p# - for # == 0 - 4 > /dev/rlofi/dsk0/s# - for # == 0 - 15 The list of devices is the same in both examples. What's the difference? 6. Section D > D. INTERFACES > > Zonecfg(1m): > rootzpool committed, resource > src committed, resource property > install-size committed, resource property What is the meaning of "committed" here? >Zones misc: > /var/zones/nfsmount/<zonename>/<host>/<nfs-share-name> > project private, nfs mount point The mount point is different from what is described in section C.1.iii (see additional comment above): > If an so-uri points to an explicit nfs server, the zones framework will > need to mount the nfs filesystem containing storage object. The nfs > server share containing the specified object will be mounted at: > /var/zones/nfsmount/<host>/<nfs-share-name> 7. What will happen to storage objects on "zonecfg delete"? -- Illya Kysil -- "EASY" is the word you use to describe other people's job. _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
