Xen virtual machines and ntp

mark m.roth2006 at rcn.com
Mon May 18 16:18:51 UTC 2009


Jose R R wrote:
> On Mon, May 18, 2009 at 7:15 AM, mark <m.roth2006 at rcn.com> 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




More information about the redhat-list mailing list