search

moby / hyperkit

A toolkit for embedding hypervisor capabilities in your application
BSD 2-Clause "Simplified" License
3.61k stars 327 forks source link

feature request: hyperkit-ctl #145

Open dave-tucker opened 7 years ago

dave-tucker commented 7 years ago

It would be convenient to have a hyperkit-ctl command that could:

This came up in discussion on the LinuxKit slack channel when the "interface" for interacting with running instances was described as ps aux | grep hyperkit and kill -9.

ijc commented 7 years ago

These sound like useful features for the higher level linuxkit tool to have alongside run, that would mean adding this functionality to the go bindings here, not necessarily to a new hyperkit-ctl command.

MagnusS commented 7 years ago

There's an example for the API go lib that can stop/kill and show VM config given a state dir: https://github.com/moby/hyperkit/blob/master/go/sample/main.go#L65

Perhaps something similar could be added upstream in linuxkit run hyperkit. linuxkit may also optionally launch vpnkit, which may require additional cleanup via the linuxkit cli after stopping hyperkit

rn commented 7 years ago

This is not going to be easy/workable. HyperKit only stores state about a VM in some circumstances and the state directory is not dependent on the user (DfM stores it in a different location to infrakit and LinuxKit by default uses the current directory), so you can't really have a tool which a) captures all hyperkit instances and can interact with them.

It's on the Go binding which keep some additional state. The C code handles this different.

I'm not sure we can easily inject events for poweroff/shutdown nor if we can add devices like CDROMs at run time.

Because of all of the above I'm inclined to close this as won't fix. @ijc thoughts?

ijc commented 7 years ago

I had suggested having the functionality be in the linuxkit tool partly because I misremembered that it was putting the state somewhere central by default, without that it doesn't make much sense there either.

In principal linuxkit could keep state somewhere central (e.g `$HOME) or could create a control socket somewhere central so it can be instructed to do "things". That seems best discussed in a linuxkit issue.

Adding cdroms at runtime would certainly require work on the hyperkit end, as would graceful poweroff/shutdown, but I think the most useful bit is cleanup, which can be done by linuxkit with a signal.