----- Original Message -----
> From: "Simon Grinberg" <si...@redhat.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
> Sent: Thursday, November 29, 2012 2:35:46 PM
> Subject: Re: [vdsm] MTU setting according to ifcfg files.
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alo...@redhat.com>
> > To: "Simon Grinberg" <si...@redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>
> > Sent: Thursday, November 29, 2012 2:25:03 PM
> > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Simon Grinberg" <si...@redhat.com>
> > > To: "Itamar Heim" <ih...@redhat.com>
> > > Cc: "Alon Bar-Lev" <alo...@redhat.com>, "VDSM Project
> > > Development"
> > > <vdsm-devel@lists.fedorahosted.org>, "Andrew
> > > Cathrow" <acath...@redhat.com>, "Saggi Mizrahi"
> > > <smizr...@redhat.com>
> > > Sent: Thursday, November 29, 2012 2:12:09 PM
> > > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Itamar Heim" <ih...@redhat.com>
> > > > To: "Saggi Mizrahi" <smizr...@redhat.com>
> > > > Cc: "Alon Bar-Lev" <alo...@redhat.com>, "Simon Grinberg"
> > > > <si...@redhat.com>, "VDSM Project Development"
> > > > <vdsm-devel@lists.fedorahosted.org>, "Andrew Cathrow"
> > > > <acath...@redhat.com>
> > > > Sent: Thursday, November 29, 2012 1:06:29 PM
> > > > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > > > 
> > 
> > <snip>
> > 
> > > > >>
> > > > >> Assuming manual changes and distro specific persistence make
> > > > >> the
> > > > >> problem complex in factor of np complete, as we do not know
> > > > >> what
> > > > >> was
> > > > >> changed when and how to revert.
> > > > >>
> > > > >> Itamar though a bomb that we should co-exist on generic
> > > > >> host,
> > > > >> this
> > > > >> is
> > > > >> something I do not know to compute. I still waiting for a
> > > > >> response
> > > > >> of where this requirement came from and if that mandatory.
> > > 
> > > Just few reasons:
> > > - One of the key attraction with KVM is that with it, you are
> > > capable
> > > to run process/application along side virtual machines. Look at
> > > every KVM presentation out there.
> > > - Licencing and support, some application (do I hear Oracle?) are
> > > not
> > > licensed/supported on KVM, but you would still want to use free
> > > cycles for virtual machines (especially on modern servers)
> > > - 3rd party monitoring and audit tools
> > > - custom drivers
> > > - custom SLA policies
> > > - etc,
> > > - etc,
> > > - etc,
> > > 
> > > You don't want to say, ha if you use VDSM to manage the node you
> > > can't do all of the above.
> > 
> > Actually, I am.
> > I claim that we will never be able to stabilize a product if we go
> > this way.
> > There is a very good reason why other virtualization solutions out
> > there put similar restriction.
> > 
> > When and if we finish with rock solid solution using a pure
> > completely managed slave and have good market share then we can
> > start thinking about these non deterministic approaches.
> 
> Actually it's the other way around. Since you are far from there,
> then many (if not most) users today actually use a full blown host
> to complement features or required functionality like: Monitoring,
> Private firewall, central logging, customization for third party
> devices etc.

And again, I disagree.
This may be enough for an entry level solution.
Enterprise solution will probably prefer rhev-h or similar self managed 
solution, this of course, if we provide decent management support.

Customization for third party devices has no management/state impact.
Central logging - we have the log collector for that.
Monitoring - if we going to provide SLA we are going to perform monitoring as 
well.
Private Firewall - this will totally conflict with whatever engine enforces.

> 
> > Or... maybe this is the marketing advantage we would like, and then
> > we should FOCUS on this approach, but then we are aiming to low
> > scale, manual managed solution, and the "other" open source project
> > will probably consume the higher scale.
> > 
> > As I wrote there are two solution using CURRENT technology for
> > that:
> > 1. Move the original host into virtual machine and manage the host
> > as
> > a whole.
> > 2. Execute virtual machine with nested virtualization and manage
> > this
> > VM as if it was our host, in this mode we have no conflict.
> > 
> > > Stateless by the way, in a sense that after reboot the node goes
> > > back
> > > to the original configuration, works very well with the
> > > requirement
> > > above. This means that the admin sets everything required for the
> > > non virtualized hardware, VDSM configures on top, but after
> > > reboot
> > > all is reverted to the original thus everything else continues to
> > > work after reboot.
> > 
> > This is not the way to go in this case, Oracle will not live within
> > stateless world, nor 1000 other solutions.
> 
> You missed what I've said: Admin configures state-fully everything
> required for the 'native' application, VDSM may configure starless
> on top. After reboot, host goes back to the original configuration
> that is enough to run the 'native' non managed by VDSM applications.

No I did not.
Let's say we introduce watchdog support into vdsm, what will be the impact on 
Oracle?
Let's say we modify block scheduler, will it conflict?
Let's say Oracle tune the scheduler (io or cpu), what will be the impact?
Now, let's assume we attach iscsi, then communication is lost, what impact will 
this have on other processes when mount point hangs process?
I can think of many other complex scenarios without a valid solution.
We will not be able to stabilize a solution this way... but we can sure die 
trying :)

Alon
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to