Qemu-guest-agent support

Requirements and motivation:

Implement the ability to create snapshots consistent with applications.
Prevent data corruption when taking snapshots.
Get rid of the need to shutdown applications to create or rollback a snapshot.
An additional option - is the ability to receive other information from the guest application.
(For example - metrics or logs)

Why Qemu-guest-agent?

Advantages:

Ready-made solution for working in the application;
Multiple ways of interaction between host and application;
Satisfies all conditions for taking snapshots on the host side without data corruption on the application side;
Supported by QEMU;
Availability in repositories;
Easy to install and run.

Flaws:

Requirements for running additional kernel modules and installing additional utilities on the application side.
If the qemu-guest-agent is not running or listening to the wrong cid, operations will not be available
The inability for qemu-ga not to specify CID:Port. This possibility exists if we make our own utility. For this reason,
it is necessary to send information for the user (CID:Port) to the controller to configure qemu-ga on the application side.
No XEN support

How will it work?

There are several options for creating a connection between a host and a guest application by
using between host and qemu-guest-agent on the guest side.

Namely, through:

-device virtio-serial

or

-device vhost-vsock-pci

-device virtio-serial

In the first case, with -device virtio-serial, the guest agent is exposed to the host via a separate QEMU chardev
device (generally, a UNIX socket) that communicates with the agent using the QMP wire protocol (minus the negotiation)
over a virtio-serial or isa-serial channel to the guest. Assuming the agent will be listening inside the guest using
the virtio-serial device at /dev/virtio-ports/org.qemu.guest_agent.0 (the default).

Virtio-serial overview

Virtio device for serial ports and console
The host can add/remove ports
Ports can be named (e.g. org.qemu.guest_agent.0)
Guest agent opens /dev/virtio- ports/<name> character device
The client app connects to QEMU chardev (UNIX domain socket, named pipe, etc)

Limitations of virtio-serial

N:1 connections are clunky over the 1:1 serial port
- Applications have to multiplex over 1 stream
- Libvirt has to arbitrate access between qemu-guest- agent client.
The relatively low number of ports available (~512)
- Limit is hard coded by the host
Stream semantics (no message boundaries)
- Ugly for datagram protocols
Applications must use character devices instead of standard sockets API...

-device vhost-vsock-pci

virtio-vsock is a host/guest communications device. It allows applications in the guest and host to communicate.
This can be used to implement hypervisor services and guest agents (like qemu-guest-agent or SPICE vdagent).

Advantages:

POSIX Sockets API so existing networking applications require minimal modification (unlike virtio-serial char devices)
Listen to sockets can accept connections from multiple clients (unlike virtio-serial char devices)
No address configuration is required inside the guest
No Ethernet or TCP/IP for a reduced attack surface for hypervisor services
Can be used with VMs that have no network interfaces

Flaws:

A hypervisor in EVE with kernel 4.8+ (not actual for EVE)
An application on that hypervisor with kernel 4.8+
QEMU 2.8+ on the hypervisor, running the virtual machine
The need to connect additional kernel modules on the application side

Sockets are created with the AF_VSOCK address family. The SOCK_STREAM socket type is currently implemented for in-order,
guaranteed stream semantics.

In EVE, we plan to implement exactly this method of communication with applications.

The proposed implementation of the functionality on the EVE side for working with snapshots.

To support consistent zfs snapshots in EVE without shutdown applications, it is proposed to add 3 functions.

Namely:

The function of checking the state of the file system in the application. (freeze, thawed)
The function of resetting memory and freezing the file system in the application
Function to thawed the file system in the application

These features will also use synchronization between EVE and the VM to guarantee command execution.
In addition, each of these functions will return the result of the command from the application

Suggested workflow for working with snapshots

Receive a command from the controller to create or roll back a snapshot;
Checking the state of the file system in the application;
Make sure the file system is working normally;
Flush RAM to disk and freeze the file system in the application;
Make sure the file system in the application is frozen;
Create a new snapshot or rollback to an existing snapshot;
After completing the command with snapshot, send the command to unfreeze the file system in the application;
Make sure that the file system is unfrozen and works normally;
Sending up-to-date information to the controller.