<http://www.theregister.co.uk/2009/11/23/repetitive_os_bloat/>
Except—isn’t this going full circle? Aren’t you just reinventing a single OS
with memory protection for individual processes?
LOL....
If you didnt have virtualisation, you would have a full OS
anyway....but its a q of advancing generations, ie improving
technology
Generation 1
We used to buy 30~50 servers per year at $8~10k each, now we buy 2~3
$20k servers per year and a SAN disk tray...that's over $500,000 v <
$100,000....Per server we now spend < $1500...
Generation 2 is now common ....we already thin provision the disk...so
give the OS and data say 100g, it uses 20gig to start with, grows with
time add disks in time....
Generation 2a or 3....Common parts of the OS are not
replicated....just delta files....40 machines can share a 10g common
disk and then have delta files of various sizes.
Generation 4 This will move into the OS and applications....so load
one Windows/Linux OS and one firefox into memory and say 40 machines
share the common code.
We can even look at thin provisioning via a thin client...where
firefox isnt even in the OS image,its external...
Whats stopping such great tech at the moment is the cost, Vmware's
view cost is obscene...the saving we'd make on say a wyse terminal is
lost in VMware's licence fees. Ditto HP's thin OS idea...I bet...its
simply priced so the vendor takes the lion's share of the savings....
Interesting things to look at is Red Hat's virtual desktop tech,
considerably cheaper, not as "powerful" as VMare but a fraction of the
cost, ie good enough and cheap aka Windows 1.0 ~ win98 territory....so
this could be a game changer...in time this will filter through to
totally free....OSS.
regards
Cheers,
Cliff
--
The Internet is interesting in that although the nicknames may change,
the same old personalities show through.
> thingy wrote:
>> On Nov 24, 12:23 pm, Lawrence D'Oliveiro <l...@geek-
>> central.gen.new_zealand> wrote:
>>> Every virtual machine has to run a full copy of an OS, duplicating
>>> services and needlessly consuming resources. So how about
>>> “bare-metal virtualization”, where each guest is running the
>>> thinnest of OS layers, just enough to intermediate service requests
>>> and responses with the host OS?
>>>
>>> <http://www.theregister.co.uk/2009/11/23/repetitive_os_bloat/>
>>>
>>> Except—isn’t this going full circle? Aren’t you just reinventing a
>>> single OS with memory protection for individual processes?
>>
>> LOL....
>>
>> If you didnt have virtualisation, you would have a full OS
>> anyway....but its a q of advancing generations, ie improving
>> technology
>>
>> Generation 1 We used to buy 30~50 servers per year at $8~10k each,
>> now we buy 2~3 $20k servers per year and a SAN disk tray...that's
>> over $500,000 v < $100,000....Per server we now spend < $1500...
>>
>> Generation 2 is now common ....we already thin provision the
>> disk...so give the OS and data say 100g, it uses 20gig to start with,
>> grows with time add disks in time....
>>
>> Generation 2a or 3....Common parts of the OS are not
>> replicated....just delta files....40 machines can share a 10g common
>> disk and then have delta files of various sizes.
>>
> I don't think that that is going to be that easy, otherwise it would
> have been done already in the thin client scenarios.
Sounds a bit like union fs, but at the file level instead of the file system
level.
>> Generation 4 This will move into the OS and applications....so load
>> one Windows/Linux OS and one firefox into memory and say 40 machines
>> share the common code.
>>
> There need be only one copy for the whole organisation, pulled down over
> the network. However we will still be paying per instance with an
> instance defined by Microsoft as a machine that *might* at some time
> load the OS or use the OS through a thin client!
Sounds like a compelling reason to use a freer alternative.
>> We can even look at thin provisioning via a thin client...where
>> firefox isn't even in the OS image,its external...
>>
> That's fine but when an app such as Firefox is loaded a certain amount
> of customisation goes on. As time passes the user tweaks Firefox to suit
> themselves. This has to be stored somewhere and currently locally make
> sense though it may not always be that way. It might be quicker to put
> firefox in a chip in the monitor and just download the customisations,
> but if you add up all the customisations for all the apps a user might
> use in a day, the customisations (presumably loaded over the network)
> might get to be quite big. People already have user profiles measured in
> GB in some cases! Besides the chip in the monitor would have to be
> pretty large and customisable. I'm not sure if this scenario is feasible
> though it is plausible.
There would always be a need for a place to store user data. Putting it at
the user end of thin client is interesting, but would probably kill
performance as thin clients are often used when bandwidth and/or latency
are poor.
>> Whats stopping such great tech at the moment is the cost, Vmware's
>> view cost is obscene...the saving we'd make on say a wyse terminal is
>> lost in VMware's licence fees. Ditto HP's thin OS idea...I bet...its
>> simply priced so the vendor takes the lion's share of the
>> savings....
>>
>> Interesting things to look at is Red Hat's virtual desktop tech,
>> considerably cheaper, not as "powerful" as VMare but a fraction of
>> the cost, ie good enough and cheap aka Windows 1.0 ~ win98
>> territory....so this could be a game changer...in time this will
>> filter through to totally free....OSS.
>>
> Except that they can't make up their minds. First it was Xen now it's
> KVM. What will it be next week? And what will we have to do to convert?
> Sigh!
I've been meaning to take a closer look at Xen, but from what I know you
can't just turn it on on a computer to have a look. I may look for a Xen
liveCD to see how it goes.
--
A.
>""GB in some cases! Besides the chip in the monitor would have to be
>pretty large and customisable. I'm not sure if this scenario is
>feasible though it is plausible.""
Hmmm, may not be that far off Cliff. I read earlier this week about a
new TV from Sony, I think, that had not only a very smart chip in it but
a large GB harddrive. Can't remember where I read it but was 52" and
used the additions to enable user to record up to 8 simultaneous HiDef
channels at once and record up to 90 0dd hours. Cost was about 15000 us
I think but economies of scale may well slash it if it takes off.
Obviously a monitor would be much cheaper and it wouldn't be too hard to
incorp a small chip/hdd (solid state?)and peripherals into monitor
making them in essence your thin client.
As an aside NZPC world have free copy VMware on dvd this month so am
going to install and give the ubuntu image that came with it a whirl
over the weekend. Have also downloaded the google chrome OS image to
have a play with.
Imagine that on monitor chip with free OSS stuff would eally lower costs
do you think for small/medium business ?
bAZZ
Assuming the operating system or systems are split into 'static' code
plus 'variables' areas, it would seem feasible that one copy of the OS
or OS's can be stored in an area read-only accessible by all virtual
machines. There is no fundamental reason why applications such as
Apache cannot be similarly stored.
Rearrangement of GNU/Linux to facilitate this would seem quite
possible, but any re-arrangement of Windows may require Microsoft's
cooperation, but then AFAIK Microsoft does not like virtual instances
of Windows running on a physival machine running something other than
Windows.
Nope...better to centralise...
It might be quicker to put
> firefox in a chip in the monitor and just download the customisations,
Take a look on you tube with a wyse terminal and 4 desktops and
VMware's view.
> but if you add up all the customisations for all the apps a user might
> use in a day, the customisations (presumably loaded over the network)
> might get to be quite big. People already have user profiles measured in
> GB in some cases! Besides the chip in the monitor would have to be
> pretty large and customisable. I'm not sure if this scenario is feasible
> though it is plausible.
> >> Whats stopping such great tech at the moment is the cost, Vmware's
> > view cost is obscene...the saving we'd make on say a wyse terminal is
> > lost in VMware's licence fees. Ditto HP's thin OS idea...I bet...its
> > simply priced so the vendor takes the lion's share of the
> > savings....
>
> > Interesting things to look at is Red Hat's virtual desktop tech,
> > considerably cheaper, not as "powerful" as VMare but a fraction of
> > the cost, ie good enough and cheap aka Windows 1.0 ~ win98
> > territory....so this could be a game changer...in time this will
> > filter through to totally free....OSS.
>
> Except that they can't make up their minds. First it was Xen now it's
> KVM. What will it be next week? And what will we have to do to convert?
> Sigh!
>
> Cheers,
>
> Cliff
I think they are using both....
Going on a course in 2 weeks to look at it.
regards
> We used to buy 30~50 servers per year at $8~10k each, now we buy 2~3
> $20k servers per year and a SAN disk tray...that's over $500,000 v <
> $100,000....Per server we now spend < $1500...
But then why do you need so many servers anyway? This seems to be a
characteristic of the Windows mentality, where if you run multiple
(proprietary) apps on one server, then if something goes wrong, the vendors
will all point the finger at each other. That’s why you end up separating
the apps onto different boxes.
Whereas Linux servers regularly run multiple Free Software apps providing
completely different services at the same time, and everybody knows how to
coexist.
> On Nov 24, 12:23 pm, Lawrence D'Oliveiro <l...@geek-
>>
>> <http://www.theregister.co.uk/2009/11/23/repetitive_os_bloat/>
>>
>> Except—isn’t this going full circle? Aren’t you just reinventing a single
>> OS with memory protection for individual processes?
>
> Assuming the operating system or systems are split into 'static' code
> plus 'variables' areas, it would seem feasible that one copy of the OS
> or OS's can be stored in an area read-only accessible by all virtual
> machines.
You mean, the way operating systems already divide their ministrations among
currently-running processes?
What I'm saying is that it won't make sense for some people, while it
will for others. EG it would not work for the sales force (who take
their laptops to clients) but it would for, say, accounts.
> I think they are using both....
>
> Going on a course in 2 weeks to look at it.
>
Is that a virtualisation course?
Yes, any 'top level' operating system would need to do this with
respect to operating systems on virtual machines. With respect to
this is would not really matter if each virtual operating system had
exclusive control over its own memory or if they each mapped a common
area of read only memory. In this case the read only memory would
needed to be 'loaded' then locked read only before any virtual
machines were started.
> On Nov 28, 11:00 am, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
>
>> In message
>> <63bc4a23-5fe2-4109-986c-07a3c16fd...@k13g2000prh.googlegroups.com>,
>> peterwn wrote:
>>
>> > On Nov 24, 12:23 pm, Lawrence D'Oliveiro <l...@geek-
>>
>> >> <http://www.theregister.co.uk/2009/11/23/repetitive_os_bloat/>
>>
>> >> Except—isn’t this going full circle? Aren’t you just reinventing a
>> >> single OS with memory protection for individual processes?
>>
>> > Assuming the operating system or systems are split into 'static' code
>> > plus 'variables' areas, it would seem feasible that one copy of the OS
>> > or OS's can be stored in an area read-only accessible by all virtual
>> > machines.
>>
>> You mean, the way operating systems already divide their ministrations
>> among currently-running processes?
>
> Yes, any 'top level' operating system would need to do this with
> respect to operating systems on virtual machines.
Why bother with the virtualization, then?
Just the player Cliff. Worked OK with the ubuntu image that was included
but wouldn't play well with the chrome image. Had to download the Sun
virtual box to do so.
Yep, the player is certainly limited but for the price one can't
complain :)
bAZZ
You’d think virtualization would offer something similar, but it doesn’t.
Yes, you can migrate virtual machines from one physical host to another, but
that doesn’t do anything to improve reliability: you can’t maintain a “hot
spare” of a live VM, ready to take over the moment the original fails. Why
don’t hypervisors offer such a facility? Yet DRBD can do it without
virtualization.
Why not?
> Why don’t hypervisors offer such a facility? Yet DRBD can do it without
> virtualization.
DRBD by itself doesn't give you that at all. It only handles the
storage level of the HA stack. You still need other pieces for the
network and application failover etc.
And you can build hot spare VMs that operate on DRBD backed storage
too. And they can even migrate the contents of the VMs RAM across
before any TCP sessions timeout. The VMs OS doesn't even know it
switched physical hardware.
It must be very satisfying being so much wiser than the rest of the
world eh? Silly people - don't they know that virtualisation doesn't
offer anything?
--
Cheers
Anton
> On Dec 15, 7:33 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> Here’s an example of a solution to a real problem:
>> <http://www.theinquirer.net/inquirer/news/1565809/drbd-accepted-linux-kernel>.
>>
>> Why don’t hypervisors offer such a facility? Yet DRBD can do it without
>> virtualization.
>
> DRBD by itself doesn't give you that at all. It only handles the
> storage level of the HA stack. You still need other pieces for the
> network and application failover etc.
OS-level and application-level pieces, Virtualization is no help with this
at all.
> And you can build hot spare VMs that operate on DRBD backed storage
> too.
But virtualization doesn’t add anything to the table.
> And they can even migrate the contents of the VMs RAM across
> before any TCP sessions timeout.
But you have to do that before the VM crashes—once it crashes, all its
context is lost. DRBD helps you recover *after* you’ve crashed.
> It must be very satisfying being so much wiser than the rest of the
> world eh? Silly people - don't they know that virtualisation doesn't
> offer anything?
Love that passive-aggressive mentality...
I'm sure there are other examples.
> DRBD helps you recover *after* you’ve crashed.
But weren't you originally claiming that DRBD was for "improving
reliability" in ways that virtualisation couldn't? Now it is for
helping you recover from a crash?
--
Cheers
Anton