Not to be too controversial, but I think you're making some very large assumptions with your question. Let's start with farm configuration.
In my experience, I don't think I've seen any one configuration that's more common than another with one notable exception: "development" servers. Devs tend to lump everything into one VM (or one box), simply because it's easiest to prototype. This is done without any real eye towards expected load or farm purpose -- it's a convenience thing.
When it comes to production farm configuration, though, the purpose and expected load on the farm should drive its configuration. This is the whole basis behind tools like Microsoft's System Center Capacity Planner (SCCP) (http://www.microsoft.com/systemcenter/en/us/capacity-planner.aspx - free download). You plug in your expected user load and what the farm will be doing, and you get a baseline recommendation out. It's not a one-size fits all, but it provides a solid starting point for further planning, customization, and tuning.
Though user load tends to be one of the bigger drivers in "number of boxes" to throw in a farm, the intended purpose of the farm is going to drive a number of configuration and tuning aspects. You asked about "better performance" in your question, but you need to answer this question: what is the farm going to be used for?
To use two disparate examples, performance tuning suggestions will vary significantly based on whether a farm will be used for collaboration (the classic "team sites" scenario) or publishing (that is, an Internet-exposed "banner site"). At a high level, optimizations for the former are going to drive towards maximizing R/W performance, while tuning for the latter will focus on maximizing caching performance and minimizing response time.
Though there are some general planning and performance tips that are relevant in most farm scenarios (for example, leveraging 64-bit hardware and software: http://technet.microsoft.com/en-us/library/dd630764.aspx), I would encourage you to start by nailing down two parameters:
- Expected user load (both average and peak)
- Intended farm purpose (collaboration, publishing, hybrid, etc.)
Once you know those two things, you're in a position to begin estimating your farm size/configuration; you'll also have an idea of where to focus some tuning efforts.
Good luck!
You need to either recreate or do the smart thing and extend the Web App. By Extending it you will allow it to be available on another url, where you can put it back on port 80. If you recreate it, just save the site collection via stsadm and restore it on the new Web Abb.
Option 1:
Central Admin -> App Management -> Create or Extend Web Application
Choose Extend and the existing web app, then give it a new URL & authorization method if needed
Option 2:stsadm -o backup -url "your url" -filename "somefile"
stsadm -o restore -url "new url" -filename "somefile"
as far as DNS goes, if the url is the machine name then no. If it is not the machine name then you need a host header and a dns entry to point to the static IP of the machine.
Best Answer
Yes it would work but a few thoughts, firstly ESX snapshots are not a long-term thing, they slow a VM down a lot and shouldn't be around for more that 24 hours in general, secondly you'd be wise to quiesce your open files first to ensure transactions are complete etc.
If you want a nice ESX-only solution the best idea is to get your server how you want, stop all services likely to have open files (MSSQL, Exchange, Sharepoint etc) - then CLONE the VM, then restart your services. This way all files are integral and you have a known working state. That said if you have commvault then you just need to buy their various app-server bolt-ons and it'll backup your VMs accurately by quiescing them first - job done.