another +1 for me (Vitaliy, thanks for redirecting me to this thread). I evaluate Veeam v6 four our new vSphere 5 cloud environment with dozens (will be hundreds to thousands) of VMs that are relatively small and have minimal CBT changes. Having redundant 10GE iSCSI SAN, enterprise storage arrays managed by Storage DRS and a decent backup server, it's impossible for me to efficiently utilize the backup process with the number of jobs that corresponds to logical groups of VMs. About 10-30% of VM backup time is spent by waiting for quiescing, snapshots and appliance reconfigurations, and during the actual backup there are still plenty of CPU/bandwidth/storage resources available. I was really surprised that despite all the v6 scalability features, the level of concurrency is primarily limited by the number of jobs.
Although we clearly cannot backup hundreds of VMs by only one job and so there will be always some concurrency, I still see this limitation important when considering if Veeam is suitable for our environment. It must be taken into account when planning the structure of vSphere folders, when planning the capacity and partitioning of backup servers, it's necessary to ensure uniform distribution of VMs between multiple jobs to maintain the backup window length, etc.
So, if it's not an architectural issue of the backup engine, I vote for an option to enable and tune concurrency inside jobs. Let users decide which jobs - serial or parallel - are better in their environment