Re: [OSR-devel] OpenVZ for OSR

[Marc G. <gr...@at...>]

----- "Gordan Bobic" <go...@bo...> wrote:

> For the sake of education and diversity I have just finished the first
> 
> attempt at this, purely to see if there is an inherent problem in
> OpenVZ 
> that might shoot this down.
> 
> Well - I haven't found any such problems! :D
I don't see them either. As far as I understand them.
> 
> The basic setup was this:
> 
> Two identical host machines (virtual, because it was easier, but fully
> 
> virtualized with KVM, CentOS 5.4). The host OS was stripped down to a
> 
> bare minimum (a "mere" 850MB...) since I didn't feel applying the more
> 
> sensibly sized OSR init root was vital for now and modding it would 
> require extra work.
> 
> Shared virtual disk (shared image, presented as an IDE device), with
> GFS 
> on top. So far, so standard.
> 
> The shared GFS device was mounted under /vz/private (where OpenVZ
> keeps 
> the VM fs trees).
> 
> CentOS 5.4 guest template was initialized in there. The guest config 
> file was the same on both hosts, except for the IP address (the IP is
> 
> configured on the host rather than the guest, but each guest can have
> 
> independent iptables rules if required).
> 
> Thus - the two guests were running on a GFS shared root. The one thing
> 
> remaining would be to set up the entries in fstab to make sure that 
> /cdsl.local gets bind mounted correctly at boot-up time, but other
> than 
> that, I'd say the preliminary prototype test has passed. :)
> 
> The basic thing I wanted to achieve is to have a cleaner separation 
> between the host provided shared rootfs and the guest so that there
> are 
> no issues during shutdown with unmounting file systems, etc. This 
> prototype appears to have completely met those requirements.
> 
> There is also an added bonus benefit that I hadn't thought of before -
> 
> the guest can be cleanly rebooted without rebooting the host (which
> also 
> means without triggering fencing and suchlike).
> 
> Gordan
Ok. Correct me if I'm wrong.
My current understanding of your concept is as follows:

You want to create a OpenVZ Cluster that just does OpenVZ without anything else.

So no "Sharedroot" within OpenVZ. But it's small.

Then you'll boot the SharedRoot as a "Guest" for you apps.

Advantages:
* Better debugging (Console, ..)
* Easier to maintain
* Virtualizationperspective: Very low resource overhead. Thanks to OpenVZ Containers.

Disadvantages:
* Tainted kernel (no support from RedHat, SAP etc.)
* Local installations for the "Host" Nodes needed.

Questions:
* This sounds like the approach the ovirt people are doing. They are using stateless linux with RO-Root as image and then mount /var rw?!
* Complexity: How to handle bonding/multipathing and other enterprise configurations?

Did I understand your concept right?

The biggest problem I see is the support one. This is a very nice concept for people who don't care about support.

What do you think?

-- 

Marc Grimme