[Automated-testing] board/vm management layer verbs for syzbot

[Dmitry Vyukov]

On Tue, Oct 8, 2019 at 1:11 AM <Tim.Bird at sony.com> wrote:
>
> Dmitry,
>
> In our hallway conversation at Plumbers we talked about the
> functions used for syzbot to control and/or communicate
> with the system under test.  I wrote them down somewhere, but I
> can't find them now.
>
> I believe you said something like "we only use a small number of functions"
> (like 4 or so).
>
> Can you tell me what these are, or point to where I can find them in
> the syzbot source code?
>
> Just for comparison, Fuego uses the following, which we call our
> "transport" APIs:
>  * cmd - execute a command on the device under test
>  * put - copy files and/or directories to the device under test
>  * get - copy files and/or directories from the device under test
>
> And ones that we consider our board management API:
>  * setup - can be used for provisioning a board or instantiating a vm
>  * teardown - used for instance destruction (for vms)
>  * reboot - reboot the device under test

Hi Tim,

Here is the interface:
https://github.com/google/syzkaller/blob/28ac6e6496673327d3319bab81c57a0f7366fb45/vm/vmimpl/vmimpl.go#L32-L57

Some comments:
 - when Instance is created, it's supposed to be a "good" state (e.g. rebooted)
 - Close ("destructor") should take care of doing tear down, returning
back to pool, etc
 - for Copy operation we don't specify destination path, it's supposed
to be chosen by the impl (different machines can have writable storage
at different paths); this is fine for our use case of copying a few
files into a single dir; a more flexible interface would allow
choosing a suffix of the path on the target machine (impl will choose
a path prefix, but you can still re-create a particular dir layout on
the target)
 - port forwarding may look a bit specialized for our use case, but we
want to connect back to the host over tcp (for a richer rpc protocol);
maybe we could limit this to just 1 port which is specified during
construction (not dynamically, e.g. qemu port forwarding can be setup
only when you start the instance, not later)
 - Run method is designed for long-running processes, so it streams
output and can be aborted; also the console output is included in the
command output, which may not be the best decision (it's always
possible to merge it later, but not possible to unmerge)
 - Diagnose is newer addition and can be used to provoke
machine/OS-dependent diagnostics output on the console (because we do
care a lot about kernel crashes/hangs and ability to understand what
happened later based on console output)