Rose debug info
---------------

Как заглянуть внутрь запущенных виртуалок?

Однажды мне потребовалось заглянуть внутрь запущенных виртуалок и сделать это массово. Не разобравшись до конца, я просто смонтировал файловые системы внутри LVM-томов с ключиком ‐‐read-only.

В общем, мораль сегодняшней заметки будет в том, что никогда не стоит полагаться на очевидность чего-либо. Ключ ‐‐read-only команды mount действует не так как можно подумать, а с особенностями:

r, --read-only Mount the filesystem read-only. A synonym is -o ro. Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal if the filesystem is dirty. To prevent this kind of write access, you may want to mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block device itself to read-only mode, see the blockdev(8) command.

В общем, кончилась история печально — таким же массовым fsck на всех виртуалках. Естественно, с даунтаймом.

Как же сделать правильно?

В моём случае с дисками на LVM — нужно было сделать LVM-снэпшот. Это зафиксировало бы состояние диска и позволило безопасно монтировать его.

В случае qcow2-дисков можно тоже обойтись снэпшотами, но есть и другой способ — замечательная библиотека libguestfs. Входящие в её состав утилиты во время работы создают оверлей над исследуемым диском и поэтому безопасны. Однако, перед использованием какой-то команды, из тулстека libguestfs было бы неплохо проверить стрейсом, что оверлей действительно создаётся, например:

# strace -f -s 256 virt-cat -a ubuntu-20.04-amd64.qcow2 /etc/issue ... 40555 execve("/usr/bin/qemu-img", ["qemu-img", "create", "-f", "qcow2", "-o", "backing_file=/virt/ostemplates/ubuntu-20.04-amd64.qcow2", "/tmp/libguestfsFr51zn/overlay1.qcow2"], 0x564b53ad1970 /* 18 vars */) = 0 ...

Доверяй, но проверяй!

Поделиться
Отправить
 16   1 мес   libguestfs   lvm   qcow2