#qemu #checkpoint
#qemu #контрольная точка
Вопрос:
Я использую эмулятор qemu для aarch64 и хочу создать внешнюю контрольную точку (или быструю переадресацию), чтобы сохранить все, что мне нужно для перезапуска системы, только с момента создания контрольной точки. (На самом деле, я хочу пропустить этап загрузки) Я нашел кое-что только в qemu VM snapshot и быстрой переадресации, но это не работает для эмулятора. Существует ли какая-либо функция контрольной точки для эмулятора qemu?
Ответ №1:
Снимок savevm должен делать то, что вы хотите. Короткий ответ заключается в том, что вам нужно настроить диск QCOW2 для сохранения снимков, а затем на мониторе вы можете использовать команду ‘savevm’ для создания снимка. Затем опция командной строки ‘-loadvm’ позволит вам возобновить работу оттуда. Все это отлично работает при эмуляции AArch64.
https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots / имеет более подробное руководство.
Комментарии:
1. Возможно ли, чтобы гость сообщал QEMU, когда делать снимок?
Ответ №2:
Минимальный пример
Ответ Питера просто сработал для меня, но позвольте мне привести полностью воспроизводимый пример.
Я полностью автоматизировал все по адресу: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/1e0f0b492855219351b0bfa2eec4d3a6811fcaaa#snapshot
Ключевым шагом является преобразование изображения в qcow2, как описано в: https://docs.openstack.org/image-guide/convert-images.html
cd buildroot/output.x86_64~/images
qemu-img convert -f raw -O qcow2 rootfs.ext2 rootfs.ext2.qcow2
И последняя использованная команда QEMU была:
./buildroot/output.x86_64~/host/usr/bin/qemu-system-x86_64 -m 128M -monitor telnet::45454,server,nowait -netdev user,hostfwd=tcp::45455-:45455,id=net0 -smp 1 -M pc -append 'root=/dev/vda nopat nokaslr norandmaps printk.devkmsg=on printk.time=y console=ttyS0' -device edu -device virtio-net-pci,netdev=net0 -drive file=./buildroot/output.x86_64~/images/rootfs.ext2.qcow2,if=virtio,format=qcow2 -kernel ./buildroot/output.x86_64~/images/bzImage -nographic
Чтобы протестировать ее, войдите в виртуальную машину и запустите:
i=0; while true; do echo $i; i=$(($i 1)); sleep 1; done
Затем в другой оболочке откройте монитор:
telnet localhost 45454
savevm my_snap_id
Подсчет продолжается. Затем, если мы загрузим виртуальную машину:
loadvm my_snap_id
подсчет возвращается к тому месту, где мы сохраняли. Это показывает, что состояния процессора и памяти были восстановлены.
Мы также можем убедиться, что состояние диска также изменено на обратное. Гость:
echo 0 >f
Монитор:
savevm my_snap_id
Гость:
echo 1 >f
Монитор:
loadvm my_snap_id
Гость:
cat f
И результат такой 0
.
Комментарии:
1. Я преобразовал ubuntu-16.04-server-cloudimg-arm64-uefi1.img с помощью приведенной выше команды, однако при попытке загрузить новый образ qcow2 он оказывается в: UEFI Interactive Shell v2.1 EDK II UEFI v2.50 (EDK II, 0x00010000) Таблица сопоставления BLK3: Псевдонимы: VenHw (F9B94AE2-8BA6-409B-9D56- B9B417F53CB3) BLK0: Псевдоним (ы): VenHw (8047DB4B-7E9C-4C0C-8EBC-DFBBAACACE8F) BLK1: Псевдоним (ы): VenHw (837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003C000A00000000) BLK2: Псевдоним (ы): VenHw (837DCA9E-E874- 4D82-B29A-23FE0E23D1E2,003E000A00000000)
2. @hayesti ага, значит, изменение ext на qcow2 само по себе создает проблемы? Я рекомендую следующее: 1) в качестве отчаянной попытки попробуйте установить EFI, как показано на superuser.com/questions/942657 /… и фактически предоставить ее QEMU (там не сделано) 2) создайте новый вопрос и обратитесь к Питеру 🙂