Docker 18.06 was released last week, update our
supported docker to this new version.
Fixes: #510
Signed-off-by: Salvador Fuentes <salvador.fuentes@intel.com>
Fixes#50
This commit imports a big logic change:
* host device to be attached or appended now is sandbox level resources,
one device should bind to sandbox/hypervisor first, then container could
reference it via device's unique ID.
* attach or detach device should go through the device manager interface
instead of the device interface.
* allocate device ID in global device mapper to guarantee every device
has a uniq device ID and there won't be any ID collision.
With this change, there will some changes on data format on disk for sandbox
and container, these changes also make a breakage of backward compatibility.
New persist data format:
* every sandbox will get a new "devices.json" file under "/run/vc/sbs/<sid>/"
which saves detailed device information, this also conforms to the concept that
device should be sandbox level resource.
* every container uses a "devices.json" file but with new data format:
```
[
{
"ID": "b80d4736e70a471f",
"ContainerPath": "/dev/zero"
},
{
"ID": "6765a06e0aa0897d",
"ContainerPath": "/dev/null"
}
]
```
`ID` should reference to a device in a sandbox, `ContainerPath` indicates device
path inside a container.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Instead of using drivers.XXXDevice directly, we should use exported
struct from device structure. package drivers should be internal struct
and other package should avoid read it's struct content directly.
Signed-off-by: Wei Zhang <zhangwei555@huawei.com>
The interface "VhostUserDevice" has duplicate functions and fields with
Device, so we can merge them into one interface and manage them with one
group of interfaces.
Signed-off-by: Wei Zhang <zhangwei555@huawei.com>
Fixes#50
Previously the devices are created with device manager and laterly
attached to hypervisor with "device.Attach()", this could work, but
there's no way to remember the reference count for every device, which
means if we plug one device to hypervisor twice, it's truly inserted
twice, but actually we only need to insert once but use it in many
places.
Use device manager as a consolidated entrypoint of device management can
give us a way to handle many "references" to single device, because it
can save all devices and remember it's use count.
Signed-off-by: Wei Zhang <zhangwei555@huawei.com>
In some slow enviroments the agent is taking more than 5 seconds
to start to serve grpc request.
This was reproducible in a Centos VM with 4 cpus running 8 pods in
parallel.
Fixes: #516
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
If the grpc connection check fails we only return the grpc error.
To make more clear what failed add more information to the error.
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
Because codecov coverage regarding the patch is very inconsistent,
this commit introduces codecov.yml config file in order to disable
this check.
Fixes#511
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
If kata-agent doesn't start in VM, we need to do some rollback
operations to release related resources.
add grpc check() to check kata-agent is running or not
Fixes: #297
Signed-off-by: flyflypeng <jiangpengfei9@huawei.com>
If some errors occur after qemu process start, then we need to
rollback to kill qemu process
Fixes: #297
Signed-off-by: flyflypeng <jiangpengfei9@huawei.com>
If some errors occur after kata-proxy start, we need to
rollback to kill kata-proxy process
Fixes: #297
Signed-off-by: flyflypeng <jiangpengfei9@huawei.com>
If error occurs after sandbox network created successfully, we need to rollback
to remove the created sandbox network
Fixes: #297
Signed-off-by: flyflypeng <jiangpengfei9@huawei.com>
ContainerID is supposed to be unique within a sandbox. It is better to use
a map to describe containers of a sandbox.
Fixes: #502
Signed-off-by: Peng Tao <bergwolf@gmail.com>
We were defer removing the temporary config.json files
but not the tmpdir path we had created to store them in.
Expose that path out so we can defer removeall it.
Fixes: #480
Signed-off-by: Graham Whaley <graham.whaley@intel.com>
When enabled, do not release in memory sandbox resources in VC APIs,
and callers are expected to call sandbox.Release() to release the in
memory resources.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
For each time a sandbox structure is created, we ensure s.Release()
is called. Then we can keep the qmp connection as long as Sandbox
pointer is alive.
All VC interfaces are still stateless as s.Release() is called before
each API returns.
OTOH, for VCSandbox APIs, FetchSandbox() must be paired with s.Release,
the same as before.
Fixes: #500
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Unify qmp channel setup and teardown. This also fixes the issue that
sometimes qmp pointer is not reset after qmp is shutdown.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
For one thing, it is not used by any kata components. For another thing,
it breaks vm factory hypervisor config check.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Add enable_template option to the config file.
When it is set, enable the vm template factory.
cache factory cannot be used by kata cli directly because
it requires a running daemon to maintain the cache VMs.
`kata-runtime factory init` would initialize the vm factory and
`kata-runtime factory destroy` would destroy the vm factory.
When configured, a vm factory is loaded before creating new sandboxes.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Add SetFactory to allow virtcontainers consumers to set a vm factory.
And use it to create new VMs whenever the factory is set.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Add vm factory support per design in the VM Factory plugin section.
The vm factory controls how a new vm is created:
1. direct: vm is created directly
2. template: vm is created via vm template. A template vm is pre-created
and saved. Later vm is just a clone of the template vm so that they
readonly share a portion of initial memory (including kernel, initramfs
and the kata agent). CPU and memory are hot plugged when necessary.
3. cache: vm is created via vm caches. A set of cached vm are pre-created
and maintained alive. New vms are created by just picking a cached vm.
CPU and memory are hot plugged when necessary.
Fixes: #303
Signed-off-by: Peng Tao <bergwolf@gmail.com>
1. support qemu migration save operation
2. setup vm templating parameters per hypervisor config
3. create vm storage path when it does not exist. This can happen when
an empty guest is created without a sandbox.
Signed-off-by: Peng Tao <bergwolf@gmail.com>
There are a few changes we need on kata agent to introduce vm factory
support:
1. decouple agent creation from sandbox config
2. setup agent without creating a sandbox
3. expose vm storage path and share mount point
Signed-off-by: Peng Tao <bergwolf@gmail.com>
