----- Original Message ----- > From: "Roni Luxenberg" <rluxe...@redhat.com> > To: "Alon Bar-Lev" <alo...@redhat.com> > Cc: "Simon Grinberg" <si...@redhat.com>, "VDSM Project Development" > <vdsm-devel@lists.fedorahosted.org> > Sent: Thursday, November 29, 2012 5:13:04 PM > Subject: Re: [vdsm] MTU setting according to ifcfg files. > > > ----- 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.
There is another thread on that, don't recall it's title but it discusses API, and there too we are divided into the stateless vs statefull parties. > > > > > > > > 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 > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
