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