Jose R R wrote: > On Mon, May 18, 2009 at 7:15 AM, mark <m.roth2006@xxxxxxx> wrote: >> ESGLinux wrote: <snip> >>> Now that I could restart my mail server with a Xen kernel (uname -a: Linux >>> mailserver 2.6.18-128.el5xen #1 SMP Wed Dec 17 12:01:40 EST 2008 x86_64 >>> x86_64 x86_64 GNU/Linux) >>> >>> I suposse it`s not a goog idea to run a non-xen kernel on a Xen host, >> <snip> >> Really?! >> >> Ok, that's nothing I would have expected, from my limited experience with VMs. >> VMware, you install the "guest" o/s in the VM, and it doesn't have to know >> anything about the VM host. > > Xen guest paravirtualization, i.e., when the guest or DomU "knows" > that it is being virtualized, provides the closest to native hardware > performance. Accordingly, open --hence modifiable or capable of being > "Xenizied"-- kernels like that of GNU/Linux are the ideal for the > so-called cloud computing platform or delivery mechanism. > > The performance of Software as a Service (SaaS) applications, being > served/delivered through the cloud platform, is dependent on the > qualities of underlying infrastructure, of which virtualization plays > a prominent role. Neither proprietary, closed source, technologies as > those by VmWare or MS HyperV, can provide the level of flexibility > and/or performance as that enabled by open source Xen technology. > > Additionally, interoperability and deployment of virtual machines > hosting business applications among the different cloud computing > providers, including those of private clouds, decreases significantly > if closed source, self-serving proprietary virtualization enabler > infrastructure technology prevail. > On the other hand, given ESGLinux's problems, *requiring* knowledge of the host o/s can result in more problems. It also seems to me that that same knowledge would provide hooks for intrusion into the host o/s. For that matter, the whole concept of an o/s, as I was taught it, lo, these many years ago, was that the programs running on it did *not* have to have knowledge of the hardware, but made standardized calls to the API's of the o/s, which provided the services required. Then there's another issue, that being that I am *very* unconvinced of the wonderfulness of cloud computing. If it were being offered via an intranet, to use spare resources inside an organization, that's one thing (I'm thinking of something along an expanded version of Seti-at-home); but as soon as it's out of my control, the guaranty of both data security and availiblity becomes questionable. mark -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
