As part of discussion: #492

1. kata-runtime
   A. issue "versioned" command to kata-agent, can always communicate correctly with old kata-agent. (MUST)
   B. disk persist data should be "versioned", kata-runtime can always handle old "version" of persist data to restore sandbox/container struct from disk to memory. (MUST)

The disk persist data should be "versioned" or baselined, and has a good rule for future modification. Currently we modify the data quite casually which is bad.

The persist data can include data under "/run/vc/sbs", "/var/lib/vc/sbs/" and "/run/kata-containers/", among them the "/run/vc/sbs" should be most important and difficult part.

These files including:

/run/vc/sbs/d827f23e7157863f23924f9d54d3822cd96f932f9ce53935b6fc7a1e61634b01
├── agent.json
├── d827f23e7157863f23924f9d54d3822cd96f932f9ce53935b6fc7a1e61634b01
│   ├── devices.json
│   ├── mounts.json
│   ├── process.json
│   └── state.json
├── devices.json
├── hypervisor.json
├── lock
├── network.json
├── proxy.sock
└── state.json

Based on this description, I have this proposal:

1. combine these files to one file

Currently we have many files here, and I think agent.json, devices.json, hypervisor.json, network.json and state.json can be combined to one. I don't think seperating them into several files can bring many benefits, this may bring some discussions or argues about performance penalty caused by disk writting, let's discuss whether this is real necessary.

2. baseline the persist data format.

Let me take #32 as an example, persist data format should be regarded as one kind of exported APIs.

We can create a dir virtcontainers/persist/types.go containing persist data format:

e.g.

// DeviceInfo is an embedded type that contains device data common to all types of devices.
type DeviceInfo struct {
    // Hostpath is device path on host
    HostPath string

    // ContainerPath is device path inside container
    ContainerPath string

    // Type of device: c, b, u or p
    // c , u - character(unbuffered)
    // p - FIFO
    // b - block(buffered) special file
    // More info in mknod(1).
    DevType string

    // Major, minor numbers for device.
    Major int64
    Minor int64

    // FileMode permission bits for the device.
    FileMode os.FileMode

    // id of the device owner.
    UID uint32

    // id of the device group.
    GID uint32

    // Hotplugged is used to store device state indicating if the
    // device was hotplugged.
    Hotplugged bool

    // ID for the device that is passed to the hypervisor.
    ID string

    // DriverOptions is specific options for each device driver
    // for example, for BlockDevice, we can set DriverOptions["blockDriver"]="virtio-blk"
    DriverOptions map[string]string
}

We should define all the data we want to export in a consolidated dir, and keeps an eye on any change to this dir.

And we can have a Dump() and Restore() function to convert internal structure to exported data structure and vise versa,

RunV gives a good example: https://github.com/hyperhq/runv/blob/master/hypervisor/persistence.go