Simulation failed by the RAM where it should not fail

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open the SingleThreshold.java example.
2. Change the hosts number to a big number, like 1000. Change the VMs number to 
2000 and the cloudlets number to 2000.
3. Run the simulation several times (10 should be ok).

What is the expected output? What do you see instead?

Expected: Simulation completed successfully.

Instead: "Allocation of VM #??? to Host #??? failed by RAM". It should not fail 
because we have more than enough hosts and RAM for this simulation.

What version of the product are you using? On what operating system?

2.1.1. This problems occurs on both Windows and Linux; using JDK 6.

Please provide any additional information below.

I think that there's a problem with the lines between 148 and 171 from 
PowerDatacenter.java file ( if (!isDisableMigrations()) { ... } ).

More specifically, *maybe* the problem resides on the fact (that I suppose) 
that "send(getId(), vm.getRam() / ((double) vm.getBw() / 8000) + 0, 
CloudSimTags.VM_MIGRATE, migrate)" method does not instantly reserves RAM and 
BW on destination host, but at the end of migration instead.

Original issue reported on code.google.com by daniella...@gmail.com on 10 Nov 2011 at 2:38

[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 daniella...@gmail.com 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 daniella...@gmail.com 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 daniella...@gmail.com 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 daniella...@gmail.com 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 anton.be...@gmail.com on 6 Jan 2012 at 8:13

• Changed state: Done