----- 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. > 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. > > Regards, > 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
