----- Original Message -----
> From: "Simon Grinberg" <si...@redhat.com>
> To: "Itamar Heim" <ih...@redhat.com>
> Cc: "Alon Bar-Lev" <alo...@redhat.com>, "VDSM Project Development"
> <email@example.com>, "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"
> > <firstname.lastname@example.org>, "Andrew Cathrow"
> > <acath...@redhat.com>
> > Sent: Thursday, November 29, 2012 1:06:29 PM
> > Subject: Re: [vdsm] MTU setting according to ifcfg files.
> > >>
> > >> 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
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
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
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.
vdsm-devel mailing list