Pull to refresh

Comments 18

Для того чтобы мне было удобно управлять виртуальными машинами, мне надо будет написать свою утилиту, которая просто будет принимать параметры на вход, выполнять команды и завершаться.

А чем родной CLI QEMU (qm) для этой задачи не угодил?

Тем, что когда ты пишешь программу, которая должна эти машины создавать пачками и опрашивать их состояния без остановки, virsh решительно никуда не годится. Virsh написан для человеков. Мне нужно для роботов. В самой статье два абзаца о том, почему мне для конкретной задачи не подходит virsh

Я, собственно, про virsh и не писал... я про родной qm.

Ах, это, да, извиняюсь, неправильно понял. На самом деле, момент заключался в том, что мне из своей программы надо управлять виртуалками. Для этого всегда есть два пути - первое, пытаться переточить утилиты CLI, второе - управлять напрямую через общедоступные API.

Почему бы не попробовать API?

Ну так Вы же с помощью API в итоге написали собственную CLI утилиту. Которая, на первый взгляд, ничего такого, что не умеет qm, не делает (разве что шаблон хочет на входе в виде XML-файла, а в qm все параметры можно прямо в аргументах задать, что для скриптинга даже удобнее, или использовать сохранённые штатными средствами той же qm шаблоны). Вот я и поинтересовался.

Казалось бы, у нас в руках есть virsh,
но, как показала практика, он не такой удобный и полезный, как мне бы
того хотелось. Virsh умеет управлять QEMU из консоли, но по факту — это
просто текстовый интерфейс, который не очень хорошо работает в скриптах и
внешних программах.

А вот здесь можно подробнее, что с virsh не так?

1) xml
2) кто блин придумал использовать для такой банальной вещи как остановка вм слово DESTROY

но это придирки, работать не мешают

а автору топика стоит погуглить что такое lxd (и да он не только lxc контейнерами может рулить но и виртуалками) он решает весь спектр задач по сопровождению vm как синглноды так и кластера, он ужобен, и у него есть api. в если ставить его НЕ из snap то он ещё и не подводит.

1) xml

и?

вроде всё читаемо и элементарно извлекается:

<domain type='qemu'>
  <name>QEmu-fedora-i686</name>
  <uuid>c7a5fdbd-cdaf-9455-926a-d65c16db1809</uuid>
  <memory>219200</memory>
  <currentMemory>219200</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='cdrom'/>
  </os>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='cdrom'>
      <source file='/home/user/boot.iso'/>
      <target dev='hdc'/>
      <readonly/>
    </disk>
  </devices>
<domain>

xml конфиг неудобен для ручного редактирования и неприятен для визуального восприятия, даже старый добрый ini мне нравится больше, ну а стильномодномолодёжный yaml визуально читаемей в сто раз. конечно это не имеет значения если xml генерируется под капотом каким-то чёрным ящиком и другим чёрным ящиком используется. но когда приходится лезть в него руками становится больно, неприятно и долго.

У меня есть база данных. В ней - настройки тысяч виртуальных машин. Мне эти настройки надо опрашивать, разбираться с ними и следить за ними. Xml генерируем на лету.

так на вскидку прикинул как подобный конфиг мог бы выглядеть в yaml формате (за ошибки и опечатки не ругайте, писал с телефона сидя в машине в ожидании)

domain:
    name: fedora-test
    uuid: xxx-xxx-xxx
    memory: 4096
    vcpu:
        sockets: 1
        cores: 2
    os:
        type:
            arch: aarch64
            machine: pc
        boot:
            dev: cdrom
    devices:
        emulator: /usr/bin/qemu-system-x86_64
        disk:
            type: file
            device: cdrom
            file: /mnt/data/iso/darch.iso
            target:
                dev: sda
            radonly: yes

строк получилось больше, но читаемость намного лучше ИМХО.
может быть я избалован этими вашими ансиблами, но по опыту могу сказать что недоконца проснувшись поздней ночью от экстренного алерта yaml читать всё же поприятнее чем xml.. может быть это всё придирки, так как и virsh с его xml ужасом я юзаю эвридей уже много лет без проблем, но хотелось бы что-то поудобнее.

Ну, скажу честно, читаемость удобнее, изменяемость идёт в канализацию. Лучше, в таком случае TOML. Там хотя-бы наличие лишнего пробела не является причиной начала апокалипсиса с последующим истреблением всех процессов в системе.

Вот про destroy - это вы просто за живое задели!

Да, за destroy хочется посмотреть в фасеточные глаза того инопланетянина, который это придумал.

Я в первый раз про destroy несколько раз в разных источниках перечитывал, когда изучал virsh, мозг отказывался ломать машину,

А что за библиотека такая в коде - uncloudzone/libtars/tylibvirt? Её не найти, нигде ничего нет подобного. Это опечатка? Напишите, пожалуйста, ссылку на эту библиотеку.

Sign up to leave a comment.