Re: [zones-discuss] zones on shared storage proposal
On Thu, May 21, 2009 at 3:55 AM, Edward Pilatowicz edward.pilatow...@sun.com wrote: hey all, i've created a proposal for my vision of how zones hosted on shared storage should work. if anyone is interested in this functionality then please give my proposal a read and let me know what you think. (fyi, i'm leaving on vacation next week so if i don't reply to comments right away please don't take offence, i'll get to it when i get back. ;) ed I'm very happy to see this. Comments appear below. please ensure that the vim modeline option is not disabled vim:textwidth=72 --- Zones on shared storage (v1.0) [snip] -- C.1.i Zonecfg(1m) The zonecfg(1m) command will be enhanced with the following two new resources and associated properties: rootzpool resource src resource property install-sizeresource property zpool-preserve resource property dataset resource property zpool resource src resource property install-sizeresource property zpool-preserve resource property nameresource property The new resource and properties will be defined as follows: rootzpool - Description: Identifies a shared storage object (and it's associated parameters) which will be used to contain the root zfs filesystem for a zone. zpool - Description: Identifies a shared storage object (and it's associated parameters) which will be made available to the zone as a delegated zfs dataset. That is to say put your OS stuff in rootzpool, put everything else in zpool - right? src - Status: Required. - Format: Storage object uri (so-uri). (See definition below.) - Description: Identifies the storage object associated with this resource. install-size - Status: Optional. - Format: Integer. Defaults to bytes, but can be flagged as gigabytes, kilobytes, or megabytes, with a g, k, or m suffix, respectively. - Description: If the specified storage object doesn't exist at zone install time it will be created with this specific size. This property has no effect for storage objects which already exist and have a pre-defined size. zpool-preserve - Status: Optional. - Format: Boolean. Defaults to false. - Description: When doing an install, if this property if this property is set to true and a zpool already exists on the specified storage object it will be used. When doing a destroy, if this property is set to true, the root zpool will not be destroyed. dataset - Status: Optional - Format: zfs filesystem name component (can't contain a '/') - Description: Name of a dataset within the root zpool to delegate to the zone. name - Status: Required - Format: zfs filesystem name component (can't contain a '/') - Description: Used as part of the name for a zpool which will be delegated to the zone. Zonecfg(1m) verify will verify the syntax of any rootzpool resource group (and its properties), but it will NOT verify the accessibility of any storage specified by by a so-uri. (This is because accessing the storage specified by an so-uri could require configuration changes to other subsystems.) -- C.1.ii Storage object uri (so-uri) format The storage object uri (so-uri) syntax[03] will conform to the standard uri format defined in RFC 3986 [04]. The nfs URI scheme is defined in RFC 2224 [05]. The so-uri syntax can be summarised as follows: File storage objects: path:///file-absolute nfs://host[:port]/file-absolute Vdisk storage objects: vpath:///file-absolute vnfs://host[:port]/file-absolute Device storage objects: fc:///wwn[@lun] iscsi:///alias=alias[@lun] iscsi:///target=target[@lun] iscsi://host[:port]/[tpgt=tpgt/]target=target[@lun] File storage objects point to plain files on a local, nfs, or cifs filesystems. These files are used to contain zpools which store zone datasets. These are the simplest types of storage objects. Once created, they have a fixed size, can't be grown, and don't support advanced features like snapshotting, etc. Some example file so-uri's are: path:///export/xvm/vm1.disk - a local file path:///net/heaped.sfbay/export/xvm/1.disk - a nfs file accessible via autofs nfs://heaped.sfbay/export/xvm/1.disk - same file specified directly via a nfs so-uri Vdisk storage objects are similar to file storage objects in that they can live on local,
Re: [zones-discuss] [crossbow-discuss] A query regarding vnic, NGZ and sysidcfg
On May 21, 2009, at 11:34 AM, Narendra Kumar.S.S wrote: Hi, I am discussing a problem with a customer who is trying to configure vnic in a NGZ thru sysidcfg. He is giving a sysidcfg file in which network_interface is configured as vnic0. So, the NGZ should create this vnic and configure this. Here is the information that they have given regarding the NGZ and the interfaces: From global zone: $ zoneadm -z mathesar-z1 list -v ID NAME STATUS PATH BRANDIP 10 mathesar-z1 running/export/home/zones/ mathesar-z1 native excl $ ifconfig -a lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 e1000g0: flags=1004843UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4 mtu 1500 index 2 inet 10.8.57.93 netmask ff00 broadcast 10.8.57.255 ether 0:14:4f:20:82:24 lo0: flags=2002000849UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL mtu 8252 index 1 inet6 ::1/128 e1000g0: flags=2000841UP,RUNNING,MULTICAST,IPv6 mtu 1500 index 2 inet6 fe80::214:4fff:fe20:8224/10 ether 0:14:4f:20:82:24 e1000g0:1: flags=2080841UP,RUNNING,MULTICAST,ADDRCONF,IPv6 mtu 1500 index 2 inet6 2002:a08:39f0:1:214:4fff:fe20:8224/64 $ dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID vnic0e1000g1 1000 2:8:20:4f:b3:a6 random 0 $ zonecfg -z mathesar-z1 info zonename: mathesar-z1 zonepath: /export/home/zones/mathesar-z1 brand: native autoboot: true bootargs: pool: limitpriv: scheduling-class: ip-type: exclusive hostid: inherit-pkg-dir: dir: /lib inherit-pkg-dir: dir: /platform inherit-pkg-dir: dir: /sbin inherit-pkg-dir: dir: /usr net: address not specified physical: vnic0 defrouter not specified $ zlogin mathesar-z1 ifconfig -a lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 vnic0: flags=1000843UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 2 inet 10.0.1.100 netmask ff00 broadcast 10.0.1.255 ether 2:8:20:4f:b3:a6 lo0: flags=2002000849UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL mtu 8252 index 1 inet6 ::1/128 vnic0: flags=2004841UP,RUNNING,MULTICAST,DHCP,IPv6 mtu 1500 index 2 inet6 fe80::8:20ff:fe4f:b3a6/10 ether 2:8:20:4f:b3:a6 $ zlogin mathesar-z1 cat /etc/hostname.vnic0 mathesar-z1 Now the problem that is observed is, during zlogin an error message is getting printed. The error message is: vnic0 is not a valid network interface line 7 position 19. According to the output above vnic0 seems to be configured in the non- global zone, is the configuration of vnic0 correct? Did you already check the contents of the sysidcfg config file? Did they try to specify the PRIMARY interface instead of vnic0 in the sysidcfg config file? Did they try to assign the physical NIC (for example e1000g1) to the zone instead to see if they still get this error message? Nicolas. If you have any suggestion on possible workarounds or solutions, please let me know. Regards, Narendra ___ crossbow-discuss mailing list crossbow-disc...@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss -- Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc. nicolas.dr...@sun.com - http://blogs.sun.com/droux ___ zones-discuss mailing list zones-discuss@opensolaris.org
