----- Original Message -----
From: "Simon Grinberg" simon@redhat.com To: "Alon Bar-Lev" alonbl@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" alonbl@redhat.com To: "Simon Grinberg" simon@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" simon@redhat.com To: "Itamar Heim" iheim@redhat.com Cc: "Alon Bar-Lev" alonbl@redhat.com, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Andrew Cathrow" acathrow@redhat.com, "Saggi Mizrahi" smizrahi@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" iheim@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "Alon Bar-Lev" alonbl@redhat.com, "Simon Grinberg" simon@redhat.com, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Andrew Cathrow" acathrow@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:
- 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