Simulation failed by the RAM where it should not fail about cloudsim

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I ran the simulation with the following parameters:

10 hosts; 20 vm's; 20 cloudlets.

each hosts with 24 gb, each vm with 9 gb and cloudlets from 100k MI to 300k MI 
with 50k steps.


This kind of simulation should reproduce the problem of vm migration to a host 
without enough ram for it, ie: if the host allocate ram AFTER the vm migration, 
and not before (which should be the desirable behavior).

It is exactly what happened: in DVFS.java example the simulation ran fine; but 
in the SingleThreshold.java the simulation failed by ram.


It appears that exists a major bug regarding vm migration in cloudsim kernel.


Output for this simulation:
Allocation of VM #0 to Host #4 failed by RAM
Something is wrong, the VM can's be restored

This occurred from Host.java vmCreate method. In 
PowerVmAllocationPolicySingleThreshold.java it is called from 
restoreAllocation() method.

Original comment by [email protected] on 17 Nov 2011 at 7:26

[GoogleCodeExporter]

Look. I have worked a lot at this bug because it does really exist and is a 
major one.

I'll try to reproduce an experiment using the default SingleThreshold.java 
experiment with differente configurations (inspired on hanoi tower):

3 Hosts (h0, h1, h2); 5 virtual Machines (vm0, vm1, ..., vm4); 5 Cloudlets (c0, 
c1, ..., c4).

The hosts have 24 GB of RAM and MIPS of h0 = 1000; h1 = 1500; h2 = 2000. The 
hosts power consumption are h0 = 200; h1 = 250; h2 = 300.

Each VM uses 9 GB of RAM (it means that each host can have at maximum 2 VMs) 
and MIPS  of vm0 = 500; vm1 = 750; vm2 = 1000; vm3 = 500; vm4 = 750.

The cloudlets size are in MI; c0 = 100000, c1 = 150000, c2 = 200000, c3 = 
250000, c4 = 300000.


On the simulation, the first allocation os VMs on hosts run right:

h0 receives vm0 (h1 free ram = 15 GB)
h1 receives vm1 and vm4 (h2 free ram = 6 GB)
h2 receives vm2 and vm3 (h3 free ram = 6 GB)

The only migration allowed in this scenario is clearly vm3 from h2 to h0; and 
it can or not occur - it should not because MIPS(h2)/POWER(h2) is lesser than 
MIPS(h0)/POWER(h0).


Although running the simulation the simulator tries the following at first move 
(on 5.0 seconds):

Restored VM #0 on host #0
Restored VM #1 on host #1
Restored VM #2 on host #2
Restored VM #3 on host #2
Restored VM #4 on host #1
5,00: Migration of VM #4 from Host #1 to Host #0 is started
5,00: Migration of VM #2 from Host #2 to Host #1 is started
5,00: Migration of VM #0 from Host #0 to Host #1 is started
5,00: Migration of VM #3 from Host #2 to Host #0 is started


Of course the simulator should try migrations because MIPS use of h0 and h2 is 
below 80% (if their power comsumption lowers), but it should not migrate at 
beginning.

This is an undesirable behaviorm, the maps created by optimizeAllocation() 
appears to be impossible...


Allocation of VM #0 to Host #0 failed by RAM (Avaiable RAM: 6000; Requested 
RAM: 9000)
Something is wrong, the VM can's be restored

Original comment by [email protected] on 21 Nov 2011 at 12:26

[GoogleCodeExporter]

Look. I have a doubt. After reading of the code thousands of times I haven't 
figure why in optimizeAllocation(List<? extends Vm> vmList) method the 
"migrating" vms are destroyed (vm.getHost().vmDestroy(vm); on for (Vm vm : 
vmList) { ... } ) because they don't really need to be destroyed (as seen in 
comment 4).

I think that this was generating my problems and I removed it. The simulation 
worked fine. In the comment 4 the vm 3 migrated from h2 to h0, after the 
processing the vm4 was migrated, etc. and the simulation runned fine.

I think that this is the bug. Only remove the line 
"vm.getHost().vmDestroy(vm);" on the loop in optimizeAllocation() and it is 
gone. I think that this is right because it is the only part that I am not 
seeing any sense (there is non sense destroying VMs before migration, it'll be 
migrating later on addMigratingInVm) and it worked for the simulations that I 
needed to.

I think it needs to be more tested but it is maybe the solution (or the 
beginning of it).


Waiting for comments and best regards,
Daniel Lago

Original comment by [email protected] on 21 Nov 2011 at 1:06

[GoogleCodeExporter]

Analysing various simulations I conclude that commenting the 
"vm.getHost().vmDestroy(vm)" all simulations runs until the (correct) end, with 
equal number of migrations (comparing to the case with this line enabled), but 
the power consumption grows a lot, being nearly the same as only with DVFS 
enabled.

Lost again...

Original comment by [email protected] on 21 Dec 2011 at 12:16

[GoogleCodeExporter]

The power package has been substantially updated, please try the new code from 
the repository. Please let us know if the issue still persists.

Original comment by [email protected] on 6 Jan 2012 at 8:13

• Changed state: Done