sanjay nadkarni wrote: > Lori Alt wrote: >> sanjay nadkarni wrote: >>> Sorry for the delay in replying. >>> >>> >>> Sarah Jelinek wrote: >>>> Hi Sanjay, >>>> >>>> A few questions... >>>> >>>> Under Assumptions: >>>>> Since OpenSolaris supports only ZFS root file system, this is the >>>>> only root file system that is >>>>> supported. In addition for zones only ZFS zone roots are supported. >>>> >>>> For clarification, does this mean we only copy data from the root >>>> pool, or root pools if there are multiple(and allowed for multiple >>>> root pools)? The reason I ask is that the ZFS root filesystem, /, >>>> today does not have separate /var or /usr. I know that there is >>>> talk of allowing for a separate /var dataset, which means that this >>>> dataset could live in another zpool(not the root pool). So, is the >>>> plan to 'follow' any datasets that are part of the BE's? Even if it >>>> means spanning pools? >>> I am not envisioning dataset spanning pools. S10 with ZFS root >>> support is also strongly recommending that zone roots be in the root >>> pool. I this plan to stick with that. >> We did recommend that at one time, but that was mainly because we >> could handle only so much complexity when we were introducing zfs root. >> >> Ed Pilatowicz and the zones team is now pushing us hard to relax this >> restriction and support zone roots on pools on files. Yes, files. >> Either local, or exported from a file server (such as the 7000 >> series) via NFS or CIFS. > Interesting. Do you have any info on the use case for this ?
yes, see: http://bt2ws.central.sun.com/CrPrint?id=6915127 Look at the CR and the zoss project docs referenced in the CR. lori > > -Sanjay > >> So I don't think that the "zone roots must be in the root pool" rule >> is going to stand. >> >> lori >>>> >>>> >>>>> No user data payload. Flash provided the ability to include user >>>>> file systems. This was >>>>> reasonable when disks were much smaller and data was closely tied >>>>> to the system. Today, most >>>>> user data is either on a NAS or SAN device and they can be huge. >>>>> User data is often separately >>>>> backed up. Hence it does not it does not make sense to include >>>>> user payload. >>>> >>>> I have been thinking about this, and I am assuming you mean that we >>>> won't copy anything outside of what is defined in the BE's, which >>>> right now is anything under rpool/ROOT/. So, /export/home is in the >>>> shared dataset space and would not be copied? >>> That is correct. >>>> I am asking because what does this mean for zones that have >>>> datasets as resources that are not in the root pool? Or a device as >>>> a resource. It sounds as if there is a possibility that some zones >>>> configurations will not be fully functional or bootable on the new >>>> system if we are only copying the content of the BE's. >>>> >>> Yup..but I don't quite see a way around this. Perhaps the zones >>> team has some thoughts here. >>> >>> >>> >>> -Sanjay >>> >>>> Requirements: >>>> >>>>> Master images must support global and non-zones. >>>> >>>> We should probably outline in more detail what the specific >>>> requirements for non-global zones is. >>>> >>>> that's it for now. >>>> >>>> thanks, >>>> sarah >>>> **** >>>> sanjay nadkarni (Laptop) wrote: >>>>> Caimanics, >>>>> Please review the requirements documents for replication in >>>>> OpenSolaris. This provides the the Flash type functionality but >>>>> includes support for zones. >>>>> >>>>> Thanks >>>>> >>>>> -Sanjay >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> caiman-discuss mailing list >>>>> caiman-discuss at opensolaris.org >>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> >
