Xen virtual machines and ntp

[mark]

Jose R R wrote:
> [...]
>>>> 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.
> 
> This issue has been addressed at length --please, search relevant
> keywords.  The fact that proprietary technologies like VmWare do not
> disclose in the open their security issues does not leave them out of
> similar security issues.

Sorry, I thought we were just having such a discussion.
> 
>> 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.
>>
> That was when x86 technology was still a "creature."  Now, in spite of
> its obvious limitations, it wants to "grow" and emulate an feature of
> the mainframe.

I beg your pardon. This was in the late seventies and early eighties, and we
were discussing *mainframes* in school. Everything I've learned on mainframes,
mid-frames, and micros has only reinforced such an attitude. For example, from
Macaholic friends, I heard how when Mac went from the Motorola chips to the IBM
PowerPC chips when, in the nineties? it *broke* M$'s Word for the Mac; when
folks investigated, they found that M$ Word was such a *dog* that to get
acceptable performance, M$ had made direct hardware calls, bypassing the o/s.

BAD. Not acceptable. And that's true for *any* platform, other than someone's
lab breadboard.
> 
>> 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.
>>
> Current economic conditions are dragging conservative attitudes into
> outsourcing their IT plumbing and cloud computing does exactly that.
> The proliferation of cloud computing platform delivery mechanism
> providers, of which Amazon EC2 is the poster child, should start
> smashing those artificial attitudes.

Sorry, I don't understand what you're saying here. If I read it one way, you're
attacking my attitude. If I read it another, you're attacking the use of cloud
computing. Kindly rephrase.

	mark