On Thu, Jan 21, 2010 at 12:13 AM, sanjay nadkarni <Sanjay.Nadkarni at sun.com> wrote: > Hi Mike, > ? ? ? ? Thanks for providing valuable feedback. ?Apologies for the delay in > replying. ?My responses are in line. > > Mike Gerdts wrote: >> >> On Tue, Jan 12, 2010 at 3:16 AM, sanjay nadkarni (Laptop) >> <Sanjay.Nadkarni at sun.com> 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 >>> >> >> >>> >>> Archive: A compressed zfs send stream of the active >>> boot environment is defined as an archive. >>> >> >> s/A compressed/An optionally compressed/ >> > > I was thinking of always having default compression else the sizes might be > too big. Moving 5-10GB images is painful.
What I am looking forward to is that won't have such large images. With S10, I start with SUNWCXall and remove large hunks that aren't useful and do other things to disable components that are hard to remove. This is because I need broad hardware support and it seems as though most ISV's only test their software with SUNCall or similar. With OpenSolaris, I'm expecting that ISV's will be starting with something close to what is on the live CD and building up from there. My guess is that this will make it so that my typical image is way less than 1 GB - particularly if I remove the desktop components that aren't needed in a server environment. Being able to specify the compression algorithm is important to meet other needs as I describe elsewhere. One of the compression algorithms could be "none" implemented by "cat". >> [snip] >> I like the idea of being able to more fully specify system >> configuration (e.g. network, partitioning) as part of the archive. >> However, it should be possible to override those. ?For instance, in a >> disaster recovery situation the hardware and/or target network may be >> different than the master. >> > > ?The ability to override, name server and IP (i.e. system configuration > parameters) is a requirement. ? The thought here is provide information that > would be helpful when choosing a target system. I hate to use the term QoS, > but for lack of a better work, ?I thought it would be useful to include the > QoS associated with the image. s/QoS/constraints/ ? >> I would find it useful to be able to deploy a flash-ish global zone in >> one phase, followed by deploying various non-global zones over time. >> Much like the architecture requirements, presumably these may need to >> do an "image update" during attach. >> > > you mean replicating a zone ? ?So something like, cloning a zone, detaching > the cloned zone and attaching it to another system ? Yes. I am trying to get past the point where the installation mechanism varies unnecessarily between virtualization technologies. When I find another soapbox I will be making suggestions along this line for the interactive installer as well. [snip] >> General: >> >> The global zone and non-global zones may be in different pools. ?So >> long as the boot pool is limited to single disks or mirrors, it is >> quite likely that systems intended to host a lot of zones will have >> the zones in a pool other than the boot pool. >> >> If network metadata is contained in the archive, there needs to be a >> way to deal with different NICs in different machines. ?For example, >> one would think that a T1000 and T2000 are relatively the same. >> Unfortunately one has bge interfaces and the other has e1000g >> interfaces. >> > > I definitely need to elaborate. ?My thought really was to capture if network > failover, or aggregation was enabled. ?With the introduction of crossbow, > one can ?create a complex network topology and the idea here be able to > capture that. ?If 3 VNICs were built by aggregating 2 physical NICs and then > partitioning them. ?It would be nice if the target system had 2 phyiscal > NICs. Any chance this will use CDP (Cisco Discovery Protocol) or the standards-based equivalent? This would make it so that it would be able to determine which VLAN(s) are on each physical link to be smart about automatically picking the right one(s). >> Any support for incremental archives? ?Presumably this would leverage >> zfs send -I. ?It would be helpful for those cases where there is a >> very common base configuration with several variants built from that >> base. >> > > Are you suggesting differential flash type functionality ? After speaking to > a number customers, very few used differential flash. ?When used, it was ?to > delivery patches. ?Since IPS addresses the patching, I don't see need. The times that I have considered using it were when I needed to layer extra software on top of a base image. The process was just so slow that found it easier to generate fresh archives. This isn't a really big deal to me, so we can probably reconsider in the future if needed. Thanks for your reply, Mike -- Mike Gerdts http://mgerdts.blogspot.com/
