...
In the VM-initiated snapshot, an application running in the VM would ensure it flushed the latest states on the disk,
and handshake to the Local Profile Server to initiate the snapshot. This is the most straightforward approach for us, but
has its drawbacks - once the flush operation is completed, the system is allowed to continue write operations.
This means that once we rolled back to one of the snapshots, the filesystem would likely have to use its fault-tolerance
the mechanism as if a sudden power-off happened. But at least, it will be guaranteed that it has the latest data from
the application.
Let's try to take a closer look at the list of steps for executing a command to create or rollback a snapshot in this approach.
It is also worth noting that a guest agent (for example, some future eve-guest-agent) must be running on the VM in order
for the user to initiate the creation or rollback of a snapshot from the VM. Why eve-guest-agent? Because in order to implement
this approach, there is a critical need to receive feedback from EVE. Thus, it will be either a completely new guest agent tailored
for work and needs with EVE OS, or a modified one (for example, based on qemu-ga, google-ga, or others)
...
- The user must use the functionality of the application that runs on the VM and execute a command that will flush
the cache of this application to the “physical” disk and completely end or suspend I/O in the application
(if creating a snapshot, you can only suspend I/O if rollback to a snapshot, then you can complete all current
write operations). In this case, everything depends on the functionality of the N application that runs on the VM.
As a last resort, if the application does not support such functionality for creating snapshots/backups, then
the user can always exit the application. The user will perform this step manually (or through a script) since
we cannot adapt to any specific applications. - After the successful completion of step 1, the user, through the agent application, let it be eve-guest-agent for example,
sends a command to create a snapshot, something like: eve-guest-agent snapshot --create /dev/sdb - The command is sent to EVE, and all the necessary conditions for creating/rolling back a snapshot
are calculated on EVE and if:- For example, if there is not enough free space, EVE will return an error on the eve-guest-agent VM about
not having enough space to create a snapshot on EVE. There may also be another error that appeared
in preparation for the requested operation. And the command is interrupted. - Next step
- For example, if there is not enough free space, EVE will return an error on the eve-guest-agent VM about
- EVE sends a command to the VM to do a sync and freeze the available filesystems.
- EVE checks that the filesystems on the VM have been frozen.
- EVE is running a command to create/rollback a snapshot
- If something went wrong, EVE sends an FS thaw command to the VM, and eve-guest-agent returns an error to the user
- Next step
- EVE thaws the FS on the guest VM and checks that it has been thawed.
- EVE notifies the user via eve-guest-agent that the operation was successful
- Guest VM returns to a normal state (user returns the application to its normal state)
You can read more about this in the EVE Guest Agent proposal.
Controller-Initiated snapshot
For Controller-Initiated snapshot, we, as in the case of VM-initiated snapshot, must have an agent running as a daemon on the VM.
And there is no way around it. The only difference will be that in place with the create or rollback command, we will also have to send
a list/script with commands for the guest VM from the controller. This list of commands will also be set by the user, and it is assumed
that these will be ordinary commands for running on the VM, which will be performed before and after snapshot operations to ensure
consistent snapshots.
Qemu-guest-agent fsfreeze command
Also, qemu comes with the qemu-guest-agent software, which is available for Linux and Windows. The agent runs as a daemon and
communicates with the host via the virtio or AF_VSOCK serial port. Qemu-guest-agent allows the VM side to execute sync/fsfreeze/fs-thaw
or any other command sent by the host. This can be considered as a potential solution for the Controller-Initiated snapshot approach,
or as a basis for the development of eve-guest-agent
...
The steps for this are rough as follows:
- The host Receive a command from the controller to create or rollback a snapshot;
- EVE sends a command to qemu-guest-agent to put the application into for create snapshot/backup state;
- Receive a command from the controller to create or rollback a snapshot;
- Checking qemu-guest-agent executes some command or script;
- EVE checking the state of the file system in the VM;
- Make sure EVE checking sure the file system is working normally;
- Flush EVE checking flush RAM to disk and freeze the file system in the VM;
- Make sure EVE checking sure the file system in the VM is frozen;
- Create EVE create a new snapshot or rollback to an existing snapshot;
- After completing the command with for snapshot, EVE send the command to unfreeze the file system in the VM;
- Make sure EVE checking sure that the file system is unfrozen and works normally;
- The host EVE sends a command to qemu-guest-agent to put the application into a normal state.Sending
- qemu-guest-agent executes some command or script;
- EVE sends up-to-date information to the controller.
- VM goes back to normal updating of their volume.
*Between step-5 6 and step-9 10 the guest can not do updates.
A similar process can be implemented through the EVE Guest Agent, which also will allow you to support work with snapshots and with the initiator - VM.
Implementing a plan of snapshot functionality in EVE
...
It is necessary to define a clear course of action for implementing the second part, namely adding an implementation
for EVE to interact with applications to perform certain actions within the application, before executing commands to
create or roll back snapshots in EVE. Implementations have been suggested in this document, but this is not the final
path and is still under discussion.
References
PR: Add an API to support snapshots in ZFS #2633
PR: Add implementation of functionality for working with snapshots #2607