> ----- 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. > engine & vdsm should provide a framework/api to offload network services like FW, IPS, DLP, WAAS, etc. (as well as other types of services like backup/DR) to external virtual appliances by seamlessly routing/redirecting traffic to/from these appliances. this will potentially reduce conflicts & dependencies and accelerate feature velocity.
> > > > > 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
