Назад | Перейти на главную страницу

Файловая система 9p плохо взаимодействует со снимком KVM savevm

У меня есть крепление 9p внутри виртуальной машины. Я делаю снимок состояния виртуальной машины с помощью savevm <snapshot>, остановите виртуальную машину, затем перезапустите ее с этим снимком (с kvm -loadvm <snapshot>). Когда я пытаюсь взаимодействовать с маунтом либо umounting илиlsing, виртуальная машина зависает в пространстве ядра.

Полная командная строка, с которой я запускаю снимок, выглядит так:

qemu-system-x86_64 -nographic -monitor telnet::6440,server,nowait \
  -m 1280M -balloon virtio -bios \
  external_sources/seabios/out/bios.bin \
  -drive file=testvm/deb.instance.integrate,if=virtio \
  -loadvm loaded \
  -virtfs local,path=/tmp/mymount,security_model=none,mount_tag=mymount

Это происходит с 64-битными гостевыми системами Debian squeeze с версиями ядра 2.6.32 и 2.6.38. ВЕРСИЯ qemu-kvm - 0.14.50, на хосте Ubuntu 10.04 amd64 с ядром 2.6.32-30.

Я не знаю, как диагностировать эту проблему дальше; На данный момент мой единственный вариант - заменить 9p какой-нибудь сетевой файловой системой.

Согласно списку рассылки qemu-devel, virtio-9p в настоящее время вообще не поддерживает динамическую миграцию, поэтому savevm / loadvm не может работать.

  1. это не имеет ничего общего с kvm как таковым - qemu управляет снимками.
  2. savevm / loadvm - это в основном миграция в файл. Никогда не пробовал это с 9p, так как я не слишком знаком с ним, но если в модели FS есть тайминги, это может быть проблемой.
  3. ubuntu в качестве kvm-хоста зарекомендовал себя (по крайней мере, для меня) как неоптимальный. Не знаю, это упаковка или сама ОС, но одни и те же версии kvm и qemu всегда были для меня надежными в Fedora.
  4. Я бы начал с а) тестирования на Fedora или rhel box б) публикации в списке рассылки linux-kvm в) проверки у тех, кто поддерживает 9p, может ли он пережить живую миграцию, гибернацию и приостановку.