ovirt-shell – some examples

oVirt is commonly managed via Engine WebAdmin interface. The reason is simple: it is very easy and intuitive. The official oVirt Administration manual shows the web interface as example too.

However, I can’t always rely on a web browser. There are sometimes that I have just the terminal. Because of my needs, I started to experiment the ovirt-shell alternative. For the basic tasks, I didn’t find problems: start vm, migrate vm, set a host in maintenance state, update some vm attribute… Below I will show some examples of the commands I’ve tried.

First, how can I connect?

[root@engine ~]# ovirt-shell -l https://engine.example.com/api -u admin@internal

You will see something like this:

 >>> connected to oVirt manager <<<
Welcome to oVirt shell
[oVirt shell (connected)]#

Once connected, it’s possible use double <TAB> to see possible commands:

[oVirt shell (connected)]# <TAB> <TAB>
EOF     add          clear   console    echo file history list remove show   summary 
action  capabilities connect disconnect exit help info    ping shell  status update

In case of doubt, the commands could be prefixed with ‘help’. For instance ‘help show host’. I won’t paste here the output of the commands because they are too big and I think you can see it by your own. Check some examples I used with descriptions:

Show details of VM web01.example.com:

show vm web01.example.com

Start VM web01.example.com:

action vm web01.example.com start

Run once VM web01.example.com in stateless mode:

action vm web01.example.com start --vm-stateless

Shutdown gracefully VM web01.example.com:

action vm web01.example.com shutdown

Migrate VM web01.example.com to any host:

action vm web01.example.com migrate

Migrate VM web01.example.com.br to host node01.example.com:

action vm web01.example.com migrate --host-name node01.example.com

Put host node02.example.com in maintenance mode:

action host node02.example.com deactivate

Activate host node03.example.com:

action host node03.example.com activate

List all VMs running on host node01.example.com:

list vms --query 'host=node01.example.com'

Edit VM web01.example.com to  boot firstly via PXE and then HD:

update vm web01.example.com --os-boot 'boot.dev=network,boot.dev=hd'

You can run just one command without get the ovirt-shell prompt:

ovirt-shell -l https://engine.example.com/api -u admin@internal -E show vm web01.example.com

If you want to run a series of commands, write them in a file and use the ‘-f’ option:

ovirt-shell -l https://engine.example.com/api -u admin@internal  -f cmds.txt

For more information, check the official page of CLI, in other words, ovirt-shell.

Hugepages and KSM on Linux

Searching for Linux optimization some time ago I got two cool features: huge pages and ksm.

Huge pages

The Linux Virtual Memory subsystem (VM) provides memory to the system in blocks, called pages. By default, each page has 4 kilobytes of size. In theory, a system with 2GiB of RAM can allocate 524,288 pages with 4KiB of size. Along with the payload, pages carries some control bits. These bits are scanned by kscand so that VM subsystem can manage the page life cycle. Each page has an entry in the page table. Thus, as much pages you have, more resources will be demanded to manage all of them.

That way, Linux can allocate untill 4 MiB page size for x86 systems and 2 MiBpage size for x86_64. You can enable it defining into your .config file of kernel source:


Once you have a kernel compiled with this two options enabled, you can allocate a number of hugepages using sysctl tool:

sysctl -w vm.nr_hugepages = 10

This will tell Linux to reserve space to 10 hugepages. You can check it out:

[root@localhost ~] grep ^Huge /proc/meminfo
HugePages_Total: 10
HugePages_Free: 10
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB

In case of x86_64 system, it means 2 MiB * 10 = 20 MiB. That pages are allocated contiguously. So, it is recommended you allocate huge pages in the boot time. Huge pages can’t be moved to swap space too.

It is commonly use in virtualization hosts and database servers.


The Kernel Samepage Merging is a mechanism which is used mainly by hypervisiors to save memory. When it is enabled, a kernel thread scans memory searching for pages with the same content but with different owner. When it occurs, Linux merges them and maps both to the same location. The new common page is marked as copy-on-write too. As soon as a process need to motify that page, Linux breaks it again into two pages. To use KSM, the kernel have to be compiled with CONFIG_KSM=y. Once the kernel is compiled with KSM, you can enable KSM to scan with:

echo 1 > /sys/kernel/mm/ksm/run

Now, your kernel will scan 100 pages each 20 millisecs by default. You can modify this writing into the files pages_to_scan and sleep_millisecs that you can find in /sys/kernel/mm/ksm folder. Monitor the KSM:

eduardo@symphony:~$ ( cd /sys/kernel/mm/ksm/ ; while true ; do clear ; for i in * ; do echo -n "${i}: " ; cat ${i} ; done ; sleep 1 ; done )

For more details, find hugetlbpage.tx and ksm.txt in Documentation folder of your Linux source.