Dave Miner wrote: > On 01/14/10 12:43 PM, Sarah Jelinek wrote: >> Hi Ethan, >> > ... >>> FileSystem Class / Dataset Class >>> This is perhaps another nit, but the relationship of the Dataset Class >>> being >>> a subclass of the FileSystem class doesn't align with the the ZFS >>> definitions >>> for those objects. Not all datasets are filesystems, e.g. ZFS Volume >>> and a ZFS >>> snapshots aren't filesystems. >> >> A ZFS Volume is covered by the LogicalVolume class. The snapshot is a >> good point though. I will think on this a bit. but, you have a good >> point which I think I need to address. >> > > Is there any reason we need to be discovering snapshots? I can't come > up with one. > >> >>> VMEnv Class / Zone Class >>> WRT the R&R statement in the last paragraph of 3.2.1.1 (first >>> paragraph on >>> page 14), an assumption here seems to be that the zone content itself >>> always >>> lives in the same pool as where the zone configuration is found. That's >>> not >>> always the case. Zones (and the VMs represented by the VMEnv Class) are >>> logical targets, but their translation into physical devices (for target >>> discovery) >>> would seem to be dependent on another logical target -- an installed >>> Solaris >>> instance (or a BootEnv seems to be the closest object defined). >> >> It wasn't my intent to imply the that the zone content itself always >> lives in the same pool. The configuration lives in the pool, and we can >> get the configuration data simply by getting the data from the pool. >> That's all this statement is intended to say. However, I get your point >> about the fact that the zone content may live outside the root pool and >> we might want to understand the zone configuration to try to 'do >> something' about getting that content during replication. As well as any >> devices that are resourced to the zone. >> >> As for mapping the logical device to physical devices, there are cases I >> can see where we would need to 'follow' the information for a VM and >> then do more with regard to replicating the content for example. The 'in >> use' details are provided by libdiskmgt, so we don't actually have to >> 'follow' anything to get this data. >> >> A couple of use cases come to mind that I thought I would outline here >> just to try to understand what we might need in terms of zones for >> Caiman. >> >> 1. Creation of a zone during initial installation of a system: >> In this case, since we only create a root pool, and I believe that's all >> we plan to support during install, the zone and its contents must >> initially live in that root pool. This might include filesystems not in >> the current BE, such as /export/home or others created by the user. >> > > Um, I think we've consistently said we'd be able to support creation of > multiple pools in at least AI, even if the interactive installers didn't > do so. I don't think that has any particular impact on the > architecture, though.
Well.. that's not what I understood. But, if we do allow creation of multiple pools with AI, I don't think it affects the architecture either. However, how we choose to manage the BE's and replication and multiple pools may require a few changes, at least in terms of managing associations. thanks, sarah **** > > Dave > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
