Re: Hello some idea to include a contract clause to protect against virtual machines
Date: Wed, 26 Nov 2014 17:26:12 -0400
Message-ID: <CAGYrQysg_vc5dgCtHfHs0-sn1jrLuHeqmp-JJmuzCT3i1X=YmA_at_mail.gmail.com>
Hello Freek, I think the problem resides usually their system technician says the problem is Oracle, and is our word against their word. The customers understands what is a slow and a faster server, but the virtual server is a more complex concept, so they must trust in what say their people.
2014-11-25 4:44 GMT-04:00 Freek D'Hooge <freek.dhooge_at_gmail.com>:
> Juan,
>
> How do you deal with customers who have put the database on an
> underpowered server or storage system?
> In what way would such a situation be different from having a customer who
> has put it on a wrongly configured virtual machine?
>
> Kind regards,
>
> --
> Freek D'Hooge
> Exitas NV
> Senior Oracle DBA
> email: freek.dhooge_at_exitas.be
> tel +32(03) 443 12 38
> http://www.exitas.be
>
> On ma, 2014-11-24 at 18:15 -0400, Juan Carlos Reyes Pacheco wrote:
>
> Thank you Tim, the problem is if you don't do that then the customer, will
> expect you solve the problem that comes from the virtual misconfiguration,
> doing some kind of magic in the database.
>
> I was thinking something like
>
> "In the case of the use of virtualization, the customer is aware it can
> affect the support from Oracle, and in the case of a failure of performance
> or bug, he accept he may need to move the production environment to an
> standalone server to verify the bug or the performance problem is not a
> problem in the virtual machine."
>
>
> This keeps an open point, because in this moment that customer is
> expecting we solve something comes from the virtual server. Because we
> restarted the database, cleared the memory, etc. and only restarting the
> server the problem is solved. And is the only customer who has that
> problem, and other clients has identical software, and the database
> configuration is standard.
>
>
> 2014-11-24 10:28 GMT-04:00 Tim Gorman <tim_at_evdbt.com>:
>
> 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/ <http://www.freelists.org/webpage/oracle-l>
> webpage/oracle-l <http://www.freelists.org/webpage/oracle-l>
>
>
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Nov 26 2014 - 22:26:12 CET