You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a scenario where we have 1 host with 2 PEs and 4 VMs each one requesting these 2 PEs. The paper CloudSim: A Novel Framework for Modeling and Simulation of Cloud Computing Infrastructures and Services states in section 3.2 that when using a VmSchedulerSpaceShared, one VM will execute first and after it finishes, the other one will start executing. However, the DatacenterBroker fails in allocating a host for 2 of these VMs due to lack of available PEs. Since each one of the 2 host PEs has a capacity of 1000 MIPS, even defining that each one of the 4 VMs requires just 500 MIPS, the allocation of 2 VMs fails.
As stated in the paper, the allocation should work in the same way that the CloudletSchedulerSpaceShared does. For the given scenario, If:
the MIPS capacity requested by each VM is not higher than the capacity of available Host PEs;
no VM is requiring more PEs or MIPS than the total Host capacity;
then, even if there is less PEs than the amount required by all VMs, 2 VMs should be queued to start executing after the first 2 ones finish.
The other scenarios presented in section 3.2 of the mentioned paper have to be tested two, to ensure they are working as expected. Integration tests for these scenarios would be included too.
If it is a more wide problem or you don't know where it happens, provide a minimal simulation example that reproduces the problem
It is a broader problem related to both DatacenterBroker and VmScheduler implementations.
An example showing the problem is available here. You will see in the logs that 2 of the 4 VMs fail and just the other 2 are placed.
Specifications like the version of the project, operating system or workload file used
The problem occurs in the current development version of CloudSim Plus but it comes from prior versions of CloudSim.
The text was updated successfully, but these errors were encountered:
manoelcampos
changed the title
Allocation of a Host PE to a VM fails when the host uses a VmSchedulerSpaceShared and there is more VMs than PEs.
Allocation of a Host PE to a VM fails when the host uses a VmSchedulerSpaceShared and there are more VMs than PEs.
Dec 22, 2017
ISSUE:
Actual behaviour and expected behavior
Consider a scenario where we have 1 host with 2 PEs and 4 VMs each one requesting these 2 PEs. The paper CloudSim: A Novel Framework for Modeling and Simulation of Cloud Computing Infrastructures and Services states in section 3.2 that when using a
VmSchedulerSpaceShared
, one VM will execute first and after it finishes, the other one will start executing. However, the DatacenterBroker fails in allocating a host for 2 of these VMs due to lack of available PEs. Since each one of the 2 host PEs has a capacity of 1000 MIPS, even defining that each one of the 4 VMs requires just 500 MIPS, the allocation of 2 VMs fails.As stated in the paper, the allocation should work in the same way that the
CloudletSchedulerSpaceShared
does. For the given scenario, If:then, even if there is less PEs than the amount required by all VMs, 2 VMs should be queued to start executing after the first 2 ones finish.
The other scenarios presented in section 3.2 of the mentioned paper have to be tested two, to ensure they are working as expected. Integration tests for these scenarios would be included too.
If it is a more wide problem or you don't know where it happens, provide a minimal simulation example that reproduces the problem
It is a broader problem related to both DatacenterBroker and VmScheduler implementations.
An example showing the problem is available here. You will see in the logs that 2 of the 4 VMs fail and just the other 2 are placed.
Specifications like the version of the project, operating system or workload file used
The problem occurs in the current development version of CloudSim Plus but it comes from prior versions of CloudSim.
The text was updated successfully, but these errors were encountered: