Editing Demo scripts

The following demo scripts (scenarios) can be used to show advantages of OpenVZ.

== Full VE lifecycle ==

Create a VE, set an IP, start, add a user, enter, exec, show <code>ps -axf</code> output inside the VE, stop, and destroy. It should take two minutes ("compare that to a time you need to deploy a new (non-virtual) server!"). During the demonstration, describe what's happening and why.

Here are the example commands needed:

 # VE=123
 # IP=10.1.1.123
 # sed -i "/$IP /d" ~/.ssh/
 # time vzctl create $VE --ostemplate fedora-core-5-i386-default
 # vzctl set $VE --ipadd $IP --hostname newVE --save
 # vzctl start $VE
 # vzctl exec $VE ps axf
 # vzctl set $VE --userpasswd guest:secret --save
 # ssh guest@$IP
 [newVE]# ps axf
 [newVE]# logout
 # vzctl stop $VE
 # vzctl destroy $VE

== Massive VE creation ==

Create/start 50 or 100 VEs in a shell loop. Shows fast deployment and high density.

Here are the example commands needed:

<pre>
# time for ((VE=200; VE<250; VE++)); do \
>  time vzctl create $VE --ostemplate fedora-core-5-i386-default; \
>  vzctl start $VE; \
> done
</pre>

== Massive VE load ==

Use VEs from previous item — load those by <code>ab</code> or <code>http_load</code>. This demo shows that multiple VEs are working just fine, with low response time etc.

<pre>
# for ((VE=200; VE<250; VE++)); do \
>  vzctl set $VE --ipadd 10.1.1.$VE --save; \
> done
</pre>
On another machine:
<pre>
# rpm -ihv http_load
# 
</pre>
FIXME: http_load commands

== Live migration ==

If you have two boxes, do "<code>vzmigrate --online</code>" from one box to another. You can use, say, <code>xvnc</code> in a VE and <code>vncclient</code> to connect to it, then run <code>xscreensaver-demo</code> and while the picture is moving do a live migration. You'll show <code>xscreensaver</code> stalls for a few seconds but then keeps running — on another machine! That looks amazing, to say at least.

FIXME: commands, setup, vnc template.

== Resource management ==
Below scenarios aims to show how OpenVZ resource management works.

=== [[UBC]] protection ===

==== fork() bomb ====
<pre>
# while [ true ]; do \
>     while [ true ]; do \
>         echo " " > /dev/null;
>     done &
> done
</pre>
We can see that number of processes inside VE will not be grow up. We will see only increase of <code>numproc</code> or <code>kmemsize</code> fail counters in <code>/proc/user_beancounters</code>.

==== dentry cache eat up ====
FIXME

=== CPU scheduler ===
Create 3 VEs:
<pre>
# vzctl create 101
# vzctl create 102
# vzctl create 103
</pre>

Set VEs weights:
<pre>
# vzctl set 101 --cpuunits 1000 --save
# vzctl set 102 --cpuunits 2000 --save
# vzctl set 103 --cpuunits 3000 --save
</pre>

We set next cpu sharing <code>VE101 : VE102 : VE103 = 1 : 2 : 3</code>

Run VEs:
<pre>
# vzctl start 101
# vzctl start 102
# vzctl start 103
</pre>

Run busy loops in VEs:
<pre>
# vzctl enter 101
[ve101]# while [ true ]; do true; done
# vzctl enter 102
[ve102]# while [ true ]; do true; done
# vzctl enter 103
[ve103]# while [ true ]; do true; done
</pre>

Check in top that sharing works:
<pre>
# top
COMMAND    %CPU
bash       48.0
bash       34.0
bash       17.5
</pre>

So, we see that CPU time is given to VEs in proportion  ~ 1 : 2 : 3.

=== Disk quota ===
<pre>
# vzctl set VEID --diskspace 1048576:1153434 --save
# vzctl start VEID
# vzctl enter VEID
[ve]# dd if=/dev/zero of=/tmp/tmp.file bs=1048576 count=1000
dd: writing `/tmp/tmp.file': Disk quota exceeded
</pre>

[[Category:Events‏‎]]