Skip to content

Conversation

LindirQuenya
Copy link
Member

@LindirQuenya LindirQuenya commented Jul 15, 2022

Merge #10 first.

QEMU only allows snapshot loading from writable devices. Without a separation of snapshot data from image data, this would make a read-only alpine.qcow2 impossible.
Instead, we can attach alpine.qcow2 read-only at runtime, and load the snapshot from the writable snapshot.qcow2, e.g. qemu-system-i386 -machine pc-i440fx-5.2 -m 128 -net nic,model=virtio-net-pci -net user,hostfwd=tcp:127.0.0.1:22500-:80 -qmp tcp:127.0.0.1:4444,server,nowait -qmp tcp:127.0.0.1:4445,server,nowait -drive if=none,format=qcow2,file=snapshot.qcow2 -drive file=alpine.qcow2,if=virtio,readonly=on -serial stdio -loadvm quick -display none.

The updated arguments list in services.json should be:

[
  "-machine",
  "pc-i440fx-5.2",
  "-m",
  "128",
  "-net",
  "nic,model=virtio-net-pci",
  "-net",
  "user,hostfwd=tcp:127.0.0.1:22500-:80",
  "-qmp",
  "tcp:127.0.0.1:4444,server,nowait",
  "-qmp",
  "tcp:127.0.0.1:4445,server,nowait",
  "-drive",
  "if=none,format=qcow2,file=snapshot.qcow2",
  "-drive",
  "file=alpine.qcow2,if=virtio,readonly=on",
  "-serial",
  "stdio",
  "-loadvm",
  "quick",
  "-display",
  "none"
]

@puigru
Copy link
Collaborator

puigru commented Sep 12, 2022

Considering #10 and that we still need the writeable "dummy" image file, does this actually bring anything to the table? If not, I'm not sure we should pursue it.

In any case, I vote to rename dummy.qcow2 to quick.qcow2 or snapshot.qcow2.

@LindirQuenya
Copy link
Member Author

This gives us hash stability for alpine.qcow2: /tmp will be in-memory on snapshot.qcow2, and (for reasons I have yet to fully understand) snapshot.qcow2's hash will change on each run. I have a solution for snapshot hash stability as well - as described here, use -incoming "exec:7z x -so snapshot.7z", which also lets us compress the snapshot data - but it doesn't work on Windows (yet, maybe I'll write it up and send QEMU a PR).

@LindirQuenya LindirQuenya changed the title Move the snapshot to a separate "dummy" disk. Move the snapshot to a separate disk. Sep 13, 2022
@puigru
Copy link
Collaborator

puigru commented Sep 19, 2022

In that case I'm not sure it's worth merging this yet given the additional complexity. Although I guess it's not to bad.

Something that this would allow is to have several different snapshots. We could have snapshots for different RAM sizes, and have the launcher start QEMU with more memory depending on the resources of the host. I believe this could improve the performance of large GameZIPs if fuse-archive can take advantage of it, there are some compile-time variables to tweak. We could also take a look at caching filesystems (catfs?).

@LindirQuenya
Copy link
Member Author

A bit of an update on this: ever since ec5b6c9, QEMU has support for exec: IO streams on Windows. So, the other method - a much cleaner solution, imo - is now feasible on all three platforms. I'll try to get that done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants