On Wed, 2011-08-03 at 14:25 -0400, aragonx(a)dcsnow.com wrote: OK - That makes sense. There are numerous resources available online for virtualizing Oracle 10g as stand-alone databases. If I were doing this in this way, I would still go with the free version of ESXi. This gives you the best overall control for resource assignment between the databases while using the smallest amount of RAM overhead for the hypervisor. It also does some things with RAM that will make things more efficient. And as I mentioned earlier, you have positive control over the network interfaces such that they can be pooled or dedicated as needed for performance and security issues. Check the following URL for some good technical information for virtualizing Oracle on ESXi, and includes specifics on 10g: http://www.vmware.com/solutions/partners/alliances/oracle-database-whitep... What's nice here is that several of the things covered are also transferable to other hypervisors if you understand how each of them handles resource management, disk storage, and networking. Also keep in mind that you will still need to license the box itself for Oracle. That part doesn't change. Hope that helps. Chris -- ====================== "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein

On Tue, 2011-08-02 at 21:54 -0400, Peter A wrote: The second paragraph is actually a little more revealing: "If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required." In other words, Oracle will support Oracle, but they expect VMware to support VMware. And, in practice, the number of issues directly attributed to VMware is about as close to zero as you can reasonably get. That includes RAC. ...And for which there are known best practices. I have a white paper on virtualizing RAC published that is part of the VMware Solution Enablement Toolkit you might find useful. Do you work for Oracle? Only someone from there would flag licensing issues in this way. Licensing Oracle isn't quite that cut and dry. In reality, you can absolutely contain Oracle licensing requirements to a single HA cluster - even by the most aggressive of Oracle standards. There's also a clear argument going on about host group affinity as being more than sufficient. Even then, I have many clients seriously considering moving to other competing database platforms (SQL Server, DB2, etc.) because their licensing terms are much more favorable and their databases much easier to virtualize without a lot of tuning. Oracle's licensing maneuver is going to cost them sales in the end, and that will eventually drive them to lighten up. Chris -- ====================== "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein

On Tuesday, August 02, 2011 09:40:57 PM Christopher A. Williams wrote: Hrm... Oracle ID 249212.1: Oracle has not certified any of its products on VMware virtualized environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware. There is more to the document but this is essentially it. If you have any issue that Oracle has not seen before and they have any reason to believe it may be related to virtualization, they'll ask you to install it on the native OS and show the issue still occurs. In practice, this happens very rarely and in my experience usually only in RAC where there are latency and driver feature requirements... However, the bigger thing is licensing. According to the official rules, you will have to license all processors that could potentially run Oracle. Since VMWare (or anything other than oracle VM) is not recognized, this means that you will have to license every single processor in your datacenter if you run only a single VM. After all, you could vmotion (or shutdown and move) your VM to any of the ESX servers... Peter. -- http://www.meaninglessrelict.com/

On Tue, 2 Aug 2011 15:49:45 -0400 aragonx(a)dcsnow.com wrote: I use KVM at work on two hosts, one intel, the other amd. I've had more random flaky problems with VMs hosted on the amd machine than on the intel machine (though nothing I've been able to put my finger on and report as a reproducible bug).

On Wed, 2011-08-03 at 07:34 -0400, Jorge Fábregas wrote: ...Of which you took several of those statements out of context and posted here in a misleading way. And that's _also_ a reality. Talk about speculation. I have the full document, which includes all of the statements. Shall I place the quotes on this from Larry Ellison himself here? I have those too. They actually show support for virtualizing Oracle on VMware - to the point that he's on the record as calling it "cool". And since I am in the business along these lines, I do have just a bit of expertise here. You must be working for Oracle and helping to spread their FUD. Full disclosure, or shall I research you in business circles? What Oracle is explicitly about is making money - and as much money as they can get their hand on - just like most companies. That's never changed. Yet - you speculated on _exactly_ those things that you purport not to have or now say you desire not to, and did so in ways that are totally and completely in error. So, why not present _all_ of the facts before you jump on this. I suggest that if you want to know real issues, yes go to Oracle's website. When you're done, also go to VMware's website where they have full disclosure and guidelines for virtualizing Oracle for everyone to see. They address these issues - and much more - explicitly and fully. Chris -- ==================================== "Behind every double standard lies a single hidden agenda." --G. K. Chesterton

On Tue, 2011-08-02 at 17:43 -0400, Jorge Fábregas wrote: This is misleading at best and untrue from a practical matter. The key is support as opposed to certification, and Oracle DOES support their database systems on VMware. There is an official support statement from Oracle to that effect. The reality is that Oracle only *certifies* to the Operating system layer, and VMware vSphere (ESX/ESXi) is considered hardware in that regard. Ask Oracle if they certify their database on IBM vs. HP vs. Dell hardware and you'll find that they don't certify any of them. KVM is considered a bare metal hypervisor by mainly the KVM folks. It actually bolts a hypervisor straight into the Linux kernel. It's clearly a better situation than a Type 2 hypervisor (and one I happen to like a lot), but you could question if it really is a full, pure bare metal class of the likes of ESX/ESXi and even OVM for that matter. I haven't done any explicit performance testing pitting KVM against ESX/ESXi yet and will hold off on doing any until vSphere 5.0 hits the streets as well. That's because there are significant performance increases in vSphere 5.0 (they have announced an increase from 300,000 IOPS to 1,000,000 IOPS for example). I can tell you that I have configured and tuned VMs on ESXi 4.1 which have performed as fast as their physical counterparts, sometimes even a little faster running Oracle, SQL Server, DB2, and Sybase. As an aside, it's also a little misleading to question certification with respect to VMware but not KVM, which is neither certified (for what that's worth) nor explicitly supported in the way that VMware is - particularly when it comes to RAC versions 11.2.0.2 and later. Cheers, Chris -- ====================== "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein