Lately, in my experience, I have seen less performance degradation when deploying QlikView on a vm environment, instead of on physical hardware. Depending on configurations (optimizations), using contemporary virtualization software (i.e. not 3 versions prior), and performance tuning the QlikView environment will all contribute to great performance to end users on a vm platform.
Yes. Another option, you can consider virtualizing specific components, example: QlikView Publisher, Web Service, and place the QlikView Server on dedicated hardware. Virtual deployment of Qlik has seen great performance improvements in the past few years. I strongly and respectfully suggest dedicating a vm instance to QlikView alone...if you need to virtualize...as I have learned, QlikView will cannibalize the RAM and CPU on a machine...in a vm instance where QlikView is installed with another application...this can have undesired performance results.
It might also be worth pointing out that Qvs is not the only service that is worth considering moving to a separate machine. Publisher, or the Distribution Service, is not seldom another reason for resource congestion. When a reload task is run, QDS will spawn a QVB process, which in all intents and purposes is a QlikView core (Qv, Qvs), which will do the reload. This process, like the Qvs, has the potential to use a lot of resources. It is good to keep this in mind, since Qvs and QDS will fight over resources if they are executing heavily at the same time.
So, a real distributed deployment might have Qvs services on separate machines and QDS on separate as well. You usually refer to this as front-end and back-end, for obvious reasons.