On 02/15/09 13:51, jpdrawneek wrote: > Steffen Weiberle wrote: >> On 02/15/09 10:48, John-Paul Drawneek wrote: >>> Just wondering what the gain you would get from using ldoms instead >>> of zones in the examples and blueprints docs that sun provides. >>> >>>> From the look they would be better suited to using zones, as same >>>> OS, software etc... >>> >>> But they use ldoms and don't say why? >>> >>> One I am mainly looking at is the tomcat setup. >> >> There are a number of blueprints and other documents regarding the use >> of zones. Not knowing which one you are specifically looking at, it is >> hard to guess at why the author(s) chose the specific virtualization >> tool they did. >> > http://wikis.sun.com/download/attachments/24543563/820-4995.pdf > > I don't see how ldoms can provide higher utilization than zones - ie the > over head > >> Keep in mind that Solaris Containters or zones can be run in any >> instance of Solaris 10, whether already in a virtualized environment >> or not. This includes on bare metal, in a Dynamic System Domain, in an >> LDom, in a Xen domain, in an xVM server domain, in a VirtualBox >> instance, in a Parallels, in a VMware guest, and so on. > I know this - I am just reading your documentation and wondering why the > choose to do it that way.
I suspect this was done to demonstrate the scalability of LDoms for a situation where operational requirements made LDoms a more desirable deployment methodology. However, only the authors know for sure. The primary reason my customers choose LDoms is that there are business reasons that require separate application instances to be able to be run at different OS update or patch levels. While this paper does not focus on that, it is a benefit of LDoms over Solaris Containers. >> Below is *my* list of features I give to customers to help decide >> whether to use Containers or LDoms (excluding the case of running a >> Container within an LDom or other virtualized environment). >> >> Steffen >> >> Solaris Containers >> ------------------ >> No special hardware required >> Single OS image >> Sub-CPU resource granularity >> Shared kernel, memory, file systems (configuration, resources and >> management) >> Solaris only (excluding Linux branded zone on x86) >> CPUs can be shared >> Works on all systems >> Virtually unlimited partitioning (max is 8191 non-global zones) >> Single system patch level >> Most admin operations can be applied to all containers in a single >> operation >> Very little performance overhead for zone infrastructure >> >> >> LDoms >> ----- >> Sun4v systems only >> Multiple OS images >> Multiples of CPU granularity >> Dedicated kernel, memory, file systems >> Can support other OSes >> CPUs can not be shared (CPUs here refers to a strand/thread) >> Currently available on Tx000, T5xy0 only >> Partitioning limited to number of CPUs >> Multiple and different patch and release levels possible >> Each LDom must be fully managed separately > So from your list there is seems to be no reason for that pdf to be > produced - so why use ldom for these task. One common reason is: *Multiple and different patch and release levels possible* Another one that just came to mind is: With Solaris Containers, if I need to do kernel level DTracing, it has to be done in the global zone. Thus an application owner or developer, who probably does not have access to the global zone, would need to contact others to have the data gathering done. If I were to give each application or developer their own LDom, they could do the full DTrace diagnostics, while not impacting the rest of the system consumers. Also, I had a customer not deploy Solaris Containers since an administrator (with sufficient privileges) in the global zone could see all traffic in and out of the system. This is much more difficult with LDoms in the service domain(s), and with hybrid I/O unicast traffic will not even pass through a service domain. (I am not 100% sure whether putting the interface into promiscuous mode would allow visibility into that traffic.) > Theres also the sugar crm pdf - again it chooses ldom when zones seems a > much better fit. I won't speculate which is better without knowing the full deployment requirements. I would agree that in general the use of Solaris Containers for hosting multiple instances of an application would be very efficient. I run Solaris Containers heavily because they run on all *my* hardware and there is virtually no overhead. I don't have dedicated T-series hardware, so LDoms would not be an alternative. Steffen PS. I am a strong proponent of Solaris Containers as blogs.sun.com/stw/ shows.
