У меня есть виртуальная машина Windows, работающая на kvm. В настоящее время у него есть необработанный образ диска 90 ГБ. Я хотел бы клонировать эту виртуальную машину без необходимости хранить две копии необработанного образа диска размером 90 ГБ.
Похоже, что хороший подход для этого - создать два новых изображения qcow или qcow2 на основе оригинала. Сначала я преобразовал необработанное изображение в изображение qcow2:
qemu-img convert -O qcow2 basewindowsxp.img basewindowsxp.qcow2
Затем я попытался создать новое изображение, подкрепленное этим:
qemu-img create -F qcow2 -f qcow2 -b `pwd`/basewindowsxp.qcow2 windowsxp-1.qcow2
Затем я использовал virt-manager, чтобы указать исходной виртуальной машине windowsxp-1.qcow2. Однако, когда я пытаюсь запустить виртуальную машину в этой новой конфигурации, virt-manager сообщает об ошибке:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 588, in run_domain
vm.startup()
File "/usr/share/virt-manager/virtManager/domain.py", line 150, in startup
self._backend.create()
File "/usr/lib/python2.6/dist-packages/libvirt.py", line 300, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open disk image /var/lib/libvirt/images/windowsxp-1.qcow2
Ошибка предполагает, что имя файла было неправильно указано или что разрешения файловой системы слишком строгие, но ни то ни другое:
$ ls -l /var/lib/libvirt/images/windowsxp-1.qcow2
-rwxrwxrwx 1 root root 262144 2010-05-27 08:32 /var/lib/libvirt/images/windowsxp-1.qcow2
Почему virt-manager не запускает эту виртуальную машину?
Эта проблема была вызвана тем, как libvirt использует apparmor.
Поведение по умолчанию - обеспечить некоторую защиту хоста от гостя, ограничивая, к каким файлам процессу виртуализации на хосте разрешен доступ. libvirt знает, что процессу виртуализации (в данном случае kvm) для правильной работы требуется образ диска, поэтому он создает профиль приложения, который позволяет получить доступ к windowsxp-1.qcow2. Однако он не знает, что windowsxp-1.qcow2 поддерживается basewindowsxp.qcow2, поэтому профиль apparmor не разрешает доступ к этому файлу.
Очень жаль, что kvm сообщает об ошибках настолько минимально. Основная ошибка почти наверняка была EPERM при открытии basewindowsxp.qcow, но, видимо, эта ошибка сглаживается и полезная информация теряется.
Однако чтение системных журналов покажет, что apparmor что-то делает. Например,
28 мая 13:12:28 имя хоста ядро: [5338.835932] type = 1503 audit (1275066748.269: 42): operation = "open" pid = 10601 parent = 1 profile = "libvirt-b1a29fd0-698c-11df-9c21-f78cb972735d" required_mask = ":: w" denied_mask = ":: w" fsuid = 0 ouid = 1001 name = "/ var / lib / libvirt / images / basewindowsxp.img"
Это показывает, что происходит, когда профиль apparmor запрещает запись в файл для процесса. Каждый раз, когда запуск виртуальной машины завершался неудачно из-за неправильной конфигурации, это сообщение журнала появлялось в / var / log / messages.
Есть несколько возможных решений проблемы.
1) Отключить аппаратную защиту. Этим можно управлять через графический интерфейс virt-manager. В разделе обзора, подраздел безопасности, можно отключить apparmor.
2) Вручную разрешите доступ к дополнительному файлу. Это контролируется изменением файлов apparmor в каталоге /etc/apparmor.d/libvirt/. Добавляем строку вроде:
"/var/lib/libvirt/images/basewindowsxp.img" r,
к файлу, совпадающему с uuid рассматриваемой виртуальной машины, предоставит доступ для чтения к имени файла в кавычках.
3) Обновите базовую платформу apparmor / libvirt / до более новой версии и заново создайте виртуальные машины. По-видимому, эта неправильная конфигурация была замечена и автоматически устраняется в достаточно новых версиях рассматриваемого программного обеспечения.