Я провел исследования, сделал выводы и хочу с вами поделиться.
У виртуалки в opennebula есть два параметра: CPU и VCPU.
И они значат не то, что вы думаете.

VCPU - это сколько ядер в виртуалке.
А ещё это - сколько ядер хоста может выжрать виртуалка.
Одно ядро виртуалки, если его нагрузить, выжирает одно ядро хоста.
Виртуалка с 4 VCPU, если их загрузить, нагрузит 4 ядра хоста.

CPU - бесполезный параметр.
opennebula позволяет выставлять приоритеты виртуалкам по части cpu.
Приоритеты выставляются через подсистему cgroups.
В cgroups есть параметр cpu.shares, который можно выставить процессу или группе процессов.
Два процесса с cpu.shares=100 поделят процессорное время ядра поровну.
Процессы с 100 и 200 поделят время, как 1/3 и 2/3 (каждый получит свой кусок от 100+200).
Так вот, CPU=1 у виртуалки просто выставляет ей cpu.shares=1024. И все.
CPU=0.5 - это cpu.shares=512.
CPU=0.01 - это cpu.shares=11.

Как это будет выглядеть на практике.
Допустим, есть хост с 1 ядром.
И мы запускаем 2 виртуалки с такими параметрами:

* v1: CPU=1 VCPU=1
* v2: CPU=1 VCPU=1

Если на v1 и v2 запустить нагрузку, они поделят одно реальное ядро пополам.
Если у v1 указать CPU=0.5, то он будет получать 33% одного реального ядра, а v2 - 66%.
Почему? Потому что их cpu.shares будут равны в сумме 1536. Доля v1 (512) в этом будет 33%, а доля v2 (1024) - 66%.
Так вот, если теперь у v2 указать CPU=0.5, то они снова будут делить ядро пополам.
Почему? 512+512 = 1024, и доля каждого (512) будет снова равна 50%.

CPU не отражает что-то сам по себе.
Он просто задает приоритет.
И он имеет смысл только в сравнении с CPU других виртуалок.
CPU=1 у всех виртуалок на хосте имеет такой же смысл, как CPU=0.01 или CPU=100.
Он имеет смысл только в одном случае: если у нас честный хостинг.
Т.е. если мы продаем виртуалки вообще без overselling'а.
Например, сервер на 24 ядра - это 24 виртуалки с одним виртуальным ядром.
Честно и не выгодно.
В этом случае параметр можно использовать.
opennebula честно считает отданные CPU и указывает их в "Allocated CPU".

this

да, это отличный материал - надо в faq

У Системного ДС , как говорилось ранее, CLONE_MODE="copy" в итоге, на старте ВМ на ноде с системным хранилищем создается дисклесс ресурс, и cat копирует с него данные в рерурс для будещей ВМ. Но когда мы говорим сразу запустить 10, 15 ну в общем множество ВМ.... то послушно выполняется скрипт clone из tm и доходит до этого момента когда на каждый экземпляр ВМ он пытается создать дисклесс но ноде с системным хранилищем, на что получает ошибку "already exists." и успешно останавливается. Если поступить очень грязно и функцию linstor_exec_and_log_no_error свести до состояния

function linstor_exec_and_log_no_error {
    EXEC_LOG=`exec $LINSTOR -m --output-version v0 $1 2>&1`
    EXEC_LOG_RC=0
        return $EXEC_LOG_RC
 
}

так сказать убрать проверку выполнения, то все гостевые ВМ стартуют на ура.

У Системного ДС , как говорилось ранее, CLONE_MODE="copy" в итоге, на старте ВМ на ноде с системным хранилищем создается дисклесс ресурс, и cat копирует с него данные в рерурс для будещей ВМ. Но когда мы говорим сразу запустить 10, 15 ну в общем множество ВМ.... то послушно выполняется скрипт clone из tm и доходит до этого момента когда на каждый экземпляр ВМ он пытается создать дисклесс но ноде с системным хранилищем, на что получает ошибку "already exists." и успешно останавливается. Если поступить очень грязно и функцию linstor_exec_and_log_no_error свести до состояния

function linstor_exec_and_log_no_error {
    EXEC_LOG=`exec $LINSTOR -m --output-version v0 $1 2>&1`
    EXEC_LOG_RC=0
        return $EXEC_LOG_RC
 
}

так сказать убрать проверку выполнения, то все гостевые ВМ стартуют на ура.

А ты не проверял, проблема возникает именно при создании diskless-устройства или при его удалении?

В общем заимплементил блокировки в v1.4.0
https://github.com/OpenNebula/addon-linstor_un

подскажите, пожалуйста, как можно запускать определенный скрипт script.sh, когда разворачивается виртуалка c одного определенного шаблона?