It is not very clear what you are asking.

But say I have 8 VM named VM1, VM2, ... , VM8.

VM1 receives work requests and distributes tasks to queues.

Then sometimes a VM needs physical resources that must be shared, say a database.

The resource must be managed so there isn't 8 different VM trying to use it at the same time, but that does NOT have to be through VM1 or any particular VM.

If the resource is physically attached to just one VM, than it makes sense for that VM to manage requests; but that doesn't have to be VM1.

If the resource can float and be attached to or respond to any VM, then all you really need is the equivalent of a mutex and queue on the resource, managed by the equivalent of a broadcast message (e.g. a queue in common memory protected by a mutex would be fine), so that it isn't confused by 8 VM commanding it at once.

So for example lets manage a Database using messaging. I require every VM to know:

(a)Which VM currently owns the DB,

(b) Which VM is currently last in line for the DB.

(c) Which VM is after it in line.

Say VM3 needs the DB, it knows VM7 owns it, and VM2 is last in line. It sends a request to VM2 to get in line. VM2 acks by broadcasting a message saying VM3 is now last in Line, and records that VM3 in (c), next in line after itself.

VM7 owns the DB; when it is done with its search or whatever, it needs to release the DB to its next in line; say for simplicity that is VM2. It broadcasts to all that VM2 now owns the DB, and clears its own states (but not (b), it always needs to know which VM is last in line, in case it needs the DB again). VM2 sees that message and knows it is free to use the DB, When it is done, it also broadcasts to its next in line (VM3), which then gets the DB and uses it.

If nobody is next in line when VM3 is done, VM3 retains the ownership (and can use it again), and also remains last in line for all VM; if they need the DB they will send a request to VM3 to get in line: VM3 will broadcast a message saying the new VM is both last in line and the new owner of the DB, and change its own state accordingly.

This protocol can be refined to handle priorities, missed messages, crossed messages, machine outages (with timeouts), etc. But the basic outline above is to demonstrate that no particular machine has to be the "master" of any resource, the resource can be managed collectively. At any given moment there is one owner that is the acting Master, but there is no centrally located queue, every VM remembers the few IDs it needs to know: Current Owner, Last in Line, Next in line (similar to a linked list).

Dear Prof. Anthony Castaldo 

Thank You for your detailed answer and sorry that the question was not so clear.

I am taking resources (memory or storage) point of view. Is there any load balancing solution available in the hypervisor to balance the resources of virtual machine's depends upon the load. 

Thanks in advance

I am sure there are hundreds of load balancing solutions, it is an active area of academic research still, and changes as technology develops new resources with new constraints.

I will leave the answer to somebody more familiar with the state of the art than I am, but I think the load balancing algorithm will depend on the resources, whether there are some tasks with higher priority than others, how long a resource is necessary, whether performance is needed (so resources should be allocated as close to the machine as possible), whether we know in advance the duration of tasks, and so on.

I suggest you google for "load balancing algorithms" or something similar.

Thank you Prof. Anthony Castaldo

Dear Mr. Sanoop,

Eventhough I am not expert in load balancing aspects of VMs in cloud computing, I assume  the load balancing algorithms used in distributed systems will help you. There are load balancing algorithms such as sender initiated, receiver initiated, symmetrically initiated  and adaptive algorithms.  Please refer M. Singhal & N.G. Shivaratri, “Advanced concepts in operating systems”. If these algorithms are not relevant to your work, please ignore this post.

Dear Sir 

I will surely have a look into the above mentioned. 

Thank you