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 ?

-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
>


Reply via email to