Re: Hello some idea to include a contract clause to protect against virtual machines

My own experience relevant to this list pertains to entrepreneurial ventures, with the following hard-earned lesson...

"Better to start with lawyers and end with a handshake, than to start with a handshake and end with lawyers." -me, circa 2001

I can also cite additional experiences on lawyers, but that would need lots of anejo.

Thanks!

-Tim

On 11/24/14 8:55, Paresh Yadav wrote:
> +1 Tim about lawyers, speaking from experience.
>
> +1 about technical options too but in general I have fallen behind a
> lot to be able to vote on something someone at level of Tim says.
> Wageries of getting promoted?!
>
> Paresh
>
> On Monday, November 24, 2014, Tim Gorman <tim_at_evdbt.com
> <mailto:tim_at_evdbt.com>> wrote:
>
> Juan,
>
> There is an old saying that, "As soon as lawyers become involved,
> the relationship is over", and this is certainly true in a
> vendor-customer relationship. A lawyer will be glad to be paid to
> pursue such a case, but I suspect it would only irritate your
> customer and it is messy and expensive to amend contracts after
> the fact. Far easier to simply address the technical problem, for
> that is what it is. That is how "trusted advisors" are born.
>
> Virtual machines are usually allocated so as to "play nice" in a
> cluster, which means that resources such as vCPU and vRAM are
> shared back and forth, since each VM cannot always be allocated
> their configured amount at all times. It is intended for the total
> resource allocated in a virtualization cluster to exceed the
> physical capacity, at least in non-production environments.
>
> But over-subscribing virtual resources in a production environment
> is neither a good idea nor recommended, and that seems to be what
> has happened here, perhaps? So, it is not that virtualization is
> inherently "bad" for production, but badly administered.
>
> Think about it: demand for resources by the Oracle environment are
> peaking when demand for resources by the other VMs are also
> peaking, if they are supporting the same application. Unless
> otherwise configured, the hyper-visor has no choice but to
> *reduce* resource allocation across the board, due to the peak in
> demand by all. If the virtualization admins likely have graphs and
> reports showing this happening already.
>
> It might be a good idea to work with the virtualization admin(s)
> to diagnose whether this is happening or not, and decide whether
> to increase resource capacity in the cluster (i.e. buy more
> hardware) or set reservations on a minimal amount of vCPU or vRAM
> for the Oracle environment? This will permit the issue to be
> escalated as the simple technical issue of resource sharing that
> it is.
>
> At this point, IT management can be presented with the choices of
> A) increasing the capacity of the cluster and solving the problem
> or B) imposing reservations on certain VMs and micro-managing
> resource allocation.
>
> There is a further option "C" of tuning each of the critical
> virtual machines to dampen the peaks in demand of course, and this
> list can help with that.
>
> Hope this helps...
>
> -Tim
>
>
>
> On 11/24/14 6:46, Juan Carlos Reyes Pacheco wrote:
>
> Hello, please
> does anybody includes in the contract something against the
> use of virtual machines to install Oracle.
> One of our customer has a virtual machine that degrades the
> performance, and is necessary to restart the server periodically.
> They expect we solve something we can't solve, because the
> problem is in the virtual machine, other customer with the
> same software doesn't have that problem.
>
> I was asking myself if there is a "standard" clause in the
> contracts for the customer to free from problem related to
> virtual machines.
> In example I read there is no support from oracle for vmware
> machines, if you have a bug you have to demostrate this same
> bug happens in a physical installation too.
>
> Thank you :)
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
>
> --
> Thanks
> Paresh Yadav
> 416-688-1003

--
http://www.freelists.org/webpage/oracle-l