Есть ли в эмуляторе qemu функция контрольной точки?

#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) создайте новый вопрос и обратитесь к Питеру 🙂