Re: [osv-dev] Can't download "large" files using python3 on top of Firecracker: ...virtio/net.rs:257] Receiving buffer is too small to hold frame of current size
On Thu, Sep 19, 2019 at 7:06 AM Henrique Fingler wrote:
> First of all, thank you for being active and helping out users!
>
> Here's my setup: I'm building a python3 image, with a script that does
>
> * response = urllib.request.urlopen("http://")*
>
> The execution just hangs for a few seconds, then a storm of warnings from
> Firecracker show up:
>
>
> 2019-09-18T17:50:36.841517975 [anonymous-instance:WARN:devices/src/virtio/
> net.rs:257] Receiving buffer is too small to hold frame of current size
> 2019-09-18T17:50:36.841529410 [anonymous-instance:WARN:devices/src/virtio/
> net.rs:257] Receiving buffer is too small to hold frame of current size
> 2019-09-18T17:50:36.841569665 [anonymous-instance:WARN:devices/src/virtio/
> net.rs:257] Receiving buffer is too small to hold frame of current size
> 2019-09-18T17:50:36.841584097 [anonymous-instance:WARN:devices/src/virtio/
> net.rs:257] Receiving buffer is too small to hold frame of current size
> 2019-09-18T17:50:36.841656060 [anonymous-instance:WARN:devices/src/virtio/
> net.rs:257] Receiving buffer is too small to hold frame of current size
>
> This is coming from here:
> https://github.com/firecracker-microvm/firecracker/blob/master/devices/src/virtio/net.rs
>
> If the file is smaller, let's say 256B, it works fine
>
> Could this be a bug in the virtio implementation of OSv or is it a
> Firecraker thing?
> I'll start to investigate the issue. I'm asking because you might have
> seen this problem.
>
Try disable gso/tso in osv viriot-net driver.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osv-dev/965f0cad-d074-4b18-b998-ffe5777851a2%40googlegroups.com
>
> .
>
--
Asias
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/CAO1GqFbU0ZGDRt5_q1xGK7SF5qnZ-QiPhzC%3Drs%2BmuJAtTxxEwg%40mail.gmail.com.
Re: [osv-dev] vsock support in osv
No, I do not think it is supposed yet. -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CAO1GqFa3a7t-4zxQHpLrFsE2S68e-xtBm2KBJh6gif93aDejOg%40mail.gmail.com.
Re: [osv-dev] vsock support in osv
On Wed, Nov 6, 2019 at 3:29 AM Waldek Kozaczuk wrote: > Asias, > > I saw somewhere that you are one of the original authors of vsock so you > may have first-hand suggestions. Isn't vsock (called socket device in > virtio spec - > https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-3910) > quite similar to virtio-net device (same rx and tx vqueues plus event one). > Would it make sense to use/re-use virtio-net code in OSv as a basic for > vsock device? > Yes, I worked on vsock in the past. It is similar to virtio-net in the sense it uses the virt-queues, but it is not an ethernet device. It is a socket (both stream and datagram) level transport. We can reuse the virtio infrastructure in osv but other than that it makes little sense to reuse the virtio-net code. > > Also as I understand vsock allows for guest-host communication. But what > are the practical examples when this is useful? Configuration management? > Would it be somewhat similar to what cloud init provides, no? > It allows guest-host and guest-host communication. It is zero config so that the guest does not need to do the ip address configuration. It can be used to replace the virtio-serial device for management. It can also be used as a guest-host file sharing using nfs on top of vsock. The nice thing about vsock is that it is easy to use from the application point of view. Any tcp/udp socket programs can be easily modified to run on top of vsock. Change the protocol number and recompile. That's it. > > Waldek > > On Monday, November 4, 2019 at 6:37:20 PM UTC-5, Asias He wrote: >> >> No, I do not think it is supposed yet. >> > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/osv-dev/142a1cc4-78fa-4b2e-ae65-eb779c54340a%40googlegroups.com > <https://groups.google.com/d/msgid/osv-dev/142a1cc4-78fa-4b2e-ae65-eb779c54340a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Asias -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CAO1GqFa2%2BG7yiLKwt%3DVBhMTYN9K1AAn3bEV9qEcmdZow_TKd5A%40mail.gmail.com.
Re: [osv-dev] OSv boots in 3ms on QEMU microvm machine
On Fri, Nov 22, 2019 at 9:34 PM Waldek Kozaczuk wrote: > > As you may have heard QEMU developers added new machine type: microvm - > https://github.com/qemu/qemu/blob/master/docs/microvm.rst. It has been merged > into master but not part of any official QEMU release. So if you want to try > you need to build QEMU from the source. > > Recently I have played with it and eventually managed to boot OSv > successfully on it after some adjustments (see some of my recent virtio code > tweaks). And the same OSv ROFS image that would boot in ~5 ms on firecracker, > can boot in only ~3ms on QEMU microvm. Wow! This is pretty impressive! > > OSv v0.54.0-34-gccb9cd12 > Booted up in 2.91 ms > Cmdline: /hello > Hello from C code > > real 0m0.057s > user 0m0.037s > sys 0m0.020s > > and with these options: > qemu-system-x86_64 \ > -m 64M \ > -smp 1 \ > --nographic \ > -kernel ./scripts/../build/last/loader-stripped.elf \ > -append "--nopci /hello" \ > -M microvm,x-option-roms=off,pit=off,pic=off,rtc=off \ > -nodefaults \ > -no-user-config \ > -no-reboot \ > -global virtio-mmio.force-legacy=off \ > -device virtio-blk-device,id=blk0,drive=hd0,scsi=off \ > -drive file=./build/last/usr.img,if=none,id=hd0,cache=writeback,aio=threads \ > -enable-kvm \ > -cpu host,+x2apic \ > -serial stdio > > Adding 1 NIC makes it boot slower by ~1 ms: > OSv v0.54.0-34-gccb9cd12 > eth0: 192.168.122.15 > Booted up in 4.30 ms > Cmdline: /hello > Hello from C code > > Regards, > Waldek > > > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/osv-dev/8d146284-3b04-4afb-b31d-158412e8f6fa%40googlegroups.com. -- Asias -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CAO1GqFZ9WFwmWFDpY9BdUSAa8tk8Hm19g4mSqmMKZz-WQmHg1A%40mail.gmail.com.
Re: Running OSv on kvmtool
On Wed, Apr 11, 2018 at 9:00 PM, Waldek Kozaczuk wrote: > Has anybody tried it? Is it lighter and faster than QEMU? > > Waldek > > PS. I have been trying to find an official github repo and many things > popup but hard to tell which one is what. > The current maintainer's repo is here: https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git I update this github repo from time to time: https://github.com/kvmtool/kvmtool The above two repo should be identical at the moment. > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Asias -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: OSv runs on Docker's Hyperkit under 100ms
On Wed, Apr 11, 2018 at 3:29 AM, Waldek Kozaczuk wrote: > Last week I have been trying to hack OSv to run on hyperkit and finally I > managed to execute native hello world example with ROFS. > > Here is a timing on hyperkit/OSX (the bootchart does not work on hyperkit > due to not granular enough timer): > > OSv v0.24-516-gc872202 > Hello from C code > > *real 0m0.075s * > *user 0m0.012s * > *sys 0m0.058s* > > command to boot it (please note that I hacked the lzloader ELF to support > multiboot): > > hyperkit -A -m 512M \ > -s 0:0,hostbridge \ > -s 31,lpc \ > -l com1,stdio \ > -s 4,virtio-blk,test.img \ > -f multiboot,lzloader.elf > Impressive! How hard is it to setup hyperkit on osx, just brew install? > > Here is a timing on QEMU/KVM on Linux (same hardware - my laptop is setup > to triple-boot Ubuntu 16/Mac OSX and Windows): > > OSv v0.24-510-g451dc6d > 4 CPUs detected > Firmware vendor: SeaBIOS > bsd: initializing - done > VFS: mounting ramfs at / > VFS: mounting devfs at /dev > net: initializing - done > vga: Add VGA device instance > virtio-blk: Add blk device instances 0 as vblk0, devsize=8520192 > random: intel drng, rdrand registered as a source. > random: initialized > VFS: unmounting /dev > VFS: mounting rofs at /rofs > VFS: mounting devfs at /dev > VFS: mounting procfs at /proc > VFS: mounting ramfs at /tmp > disk read (real mode): 28.31ms, (+28.31ms) > uncompress lzloader.elf: 49.63ms, (+21.32ms) > TLS initialization: 50.23ms, (+0.59ms) > .init functions: 52.22ms, (+1.99ms) > SMP launched: 53.01ms, (+0.79ms) > VFS initialized: 55.25ms, (+2.24ms) > Network initialized: 55.54ms, (+0.29ms) > pvpanic done: 55.66ms, (+0.12ms) > pci enumerated: 60.40ms, (+4.74ms) > drivers probe: 60.40ms, (+0.00ms) > drivers loaded: 126.37ms, (+65.97ms) > ROFS mounted: 128.65ms, (+2.28ms) > Total time: 128.65ms, (+0.00ms) > Hello from C code > VFS: unmounting /dev > VFS: unmounting /proc > VFS: unmounting / > ROFS: spent 1.00 ms reading from disk > ROFS: read 21 512-byte blocks from disk > ROFS: allocated 18 512-byte blocks of cache memory > ROFS: hit ratio is 89.47% > Powering off. > > *real 0m1.049s* > *user 0m0.173s* > *sys 0m0.253s* > > booted like so: > > qemu-system-x86_64 -m 2G -smp 4 \ > > -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ > > -drive > file=/home/wkozaczuk/projects/osv/build/last/usr.img,if=none,id=hd0,cache=none,aio=native > \ > > -enable-kvm -cpu host,+x2apic \ > > -chardev stdio,mux=on,id=stdio,signal=off \ > > -mon chardev=stdio,mode=readline > > -device isa-serial,chardev=stdio > > > In both cases I am not using networking - only block device. BTW I have > not tested how networking nor SMP on hyperkit with OSv. > > So as you can see* OSv is 10 (ten) times faster* on the same hardware. I > am not sure if my results are representative. But if they are it would mean > that QEMU is probably the culprit. Please see my questions/consideration > toward the end of the email. > > Anyway let me give you some background. What is hyperkit? Hyperkit ( > https://github.com/moby/hyperkit) is a fork by Docker of xhyve ( > https://github.com/mist64/xhyve) which itself is a port of bhyve ( > https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html) - > hypervisor on FreeBSD. Bhyve architecture is similar to that of KVM/QEMU > but QEMU-equivalent of bhyve is much lighter and simpler: > > "The bhyve BSD-licensed hypervisor became part of the base system with > FreeBSD 10.0-RELEASE. This hypervisor supports a number of guests, > including FreeBSD, OpenBSD, and many Linux® distributions. By default, > bhyve provides access to serial console and does not emulate a graphical > console. Virtualization offload features of newer CPUs are used to avoid > the legacy methods of translating instructions and manually managing memory > mappings. > > The bhyve design requires a processor that supports Intel® Extended Page > Tables (EPT) or AMD® Rapid Virtualization Indexing (RVI) or Nested Page > Tables (NPT). Hosting Linux® guests or FreeBSD guests with more than one > vCPU requires VMX unrestricted mode support (UG). Most newer processors, > specifically the Intel® Core™ i3/i5/i7 and Intel® Xeon™ E3/E5/E7, support > these features. UG support was introduced with Intel's Westmere > micro-architecture. For a complete list of Intel® processors that support > EPT, refer to http://ark.intel.com/search/advanced?s=t&; > ExtendedPageTables=true. RVI is found on the third generation and later > of the AMD Opteron™ (Barcelona) processors" > > Hyperkit/Xhyve is a port of bhyve but targets Apple OSX as a host system > and instead of FreeBSD vmm kernel module uses Apple hypervisor framework ( > https://developer.apple.com/documentation/hypervisor). Docker, I think, > forked xhyve to create hyperkit in order to provide lighter alternative of > running Docker containers on Linux on Mac. So in essence hyperkit is a > component of Docker for Mac vs Docker Machine/Toolbox (based on > Vir
Re: [PATCH] Improved python27
Cheers! I was running jpython on osv for python applications in the past.
Good to see this!
On Tue, Aug 14, 2018 at 11:42 AM, Waldemar Kozaczuk
wrote:
> This patch renames python27 to python2x and improves it
> by discovering Python home directory by reading sys.* variables.
>
> Signed-off-by: Waldemar Kozaczuk
> ---
> python27/README | 8
> {python27 => python2x}/GET | 17 ++---
> {python27 => python2x}/Makefile | 0
> python2x/README | 13 +
> {python27 => python2x}/python.c | 0
> {python27 => python2x}/usr.manifest | 0
> 6 files changed, 23 insertions(+), 15 deletions(-)
> delete mode 100644 python27/README
> rename {python27 => python2x}/GET (67%)
> rename {python27 => python2x}/Makefile (100%)
> create mode 100644 python2x/README
> rename {python27 => python2x}/python.c (100%)
> rename {python27 => python2x}/usr.manifest (100%)
>
> diff --git a/python27/README b/python27/README
> deleted file mode 100644
> index 3569e47..000
> --- a/python27/README
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -This app builds an image containing the already-compiled Python shared
> -object (libpython2.7.so) installed on the build macine, and some of
> -the required libraries from the build machine.
> -
> -Example usage:
> -
> -./scripts/run.py -e "/python"
> -./scripts/run.py -e "/python -c \"aa={1:22,3:44}; print aa; print
> 'asdf'\""
> diff --git a/python27/GET b/python2x/GET
> similarity index 67%
> rename from python27/GET
> rename to python2x/GET
> index 05774df..8942577 100755
> --- a/python27/GET
> +++ b/python2x/GET
> @@ -1,10 +1,14 @@
> #!/usr/bin/env bash
> set -e
>
> -VERSION=2.7
> BASEDIR=$PWD
> ROOTFS=$BASEDIR/ROOTFS
>
> +PYTHON_PREFIX_DIR=`python -c 'import sys; print(sys.prefix)'`
> +PYTHON_MAJOR_VERSION=`python -c 'import sys;
> print(sys.version_info.major)'`
> +PYTHON_MINOR_VERSION=`python -c 'import sys;
> print(sys.version_info.minor)'`
> +PYTHON_VERSION="${PYTHON_MAJOR_VERSION}.${PYTHON_MINOR_VERSION}"
> +
> install_shlibs() {
> SHLIBS=""
> SHLIBS+=" $ROOTFS/python.so "
> @@ -17,23 +21,22 @@ SHLIBS_COUNT="`echo \"$SHLIBS\" | wc -l`"
> ldd $SHLIBS | grep -Po '(?<=> )/[^ ]+' | sort | uniq | grep -Pv
> 'lib(c|gcc|dl|m|util|rt|pthread|stdc\+\+|selinux|krb5|gssapi_krb5)\.so' |
> xargs -I {} install {} $ROOTFS/usr/lib
> # ROOTFS/lib/python2.7/config/libpython2.7.so is a symlink to ../../
> libpython2.7.so,
> # so create a valid destination to avoid ldd error due to dangling
> symlink.
> -(cd $ROOTFS/lib && ln -sf ../usr/lib/libpython$VERSION.so.1.0
> libpython$VERSION.so)
> +(cd $ROOTFS/lib && ln -sf ../usr/lib/libpython${PYTHON_VERSION}.so.1.0
> libpython${PYTHON_VERSION}.so)
> echo "$SHLIBS_COUNT"
> }
>
> main() {
> mkdir -p build/
> -gcc -o build/python.so python.c -fPIC -shared -lpython${VERSION}
> +gcc -o build/python.so python.c -fPIC -shared -lpython${PYTHON_VERSION}
>
> rm -rf "$ROOTFS"
> mkdir -p "$ROOTFS/usr/lib"
> -mkdir -p "$ROOTFS/lib/python$VERSION"
> +mkdir -p "$ROOTFS/lib/python${PYTHON_VERSION}"
>
> cp build/python.so "$ROOTFS"
> install_shlibs
> -# TODO /lib64/python2.7/ should not be hardcoded?
> -PY_LIB1=/lib64/python$VERSION/
> -rsync -a $PY_LIB1 $ROOTFS/lib/python$VERSION/ --exclude test --exclude
> unittest \
> +PY_LIB1="${PYTHON_PREFIX_DIR}/lib/python${PYTHON_VERSION}/"
> +rsync -a $PY_LIB1 $ROOTFS/lib/python${PYTHON_VERSION}/ --safe-links
> --exclude test --exclude unittest \
> --exclude '*.pyc' --exclude '*.pyo' --exclude '*.egg-info'
>
> SHLIBS_COUNT4=`install_shlibs`
> diff --git a/python27/Makefile b/python2x/Makefile
> similarity index 100%
> rename from python27/Makefile
> rename to python2x/Makefile
> diff --git a/python2x/README b/python2x/README
> new file mode 100644
> index 000..217a00b
> --- /dev/null
> +++ b/python2x/README
> @@ -0,0 +1,13 @@
> +This app builds an image containing the already-compiled Python shared
> +object for Python 2.x (libpython2.7.so for example) installed on the
> build macine,
> +and some of the required libraries from the build machine.
> +
> +The python home directory is assumed to be installed under
> +/lib/python./
> +where sys is Python package this script reads the sys.* values from.
> +
> +Example usage:
> +
> +./scripts/run.py -e "/python"
> +./scripts/run.py -e "/python -c \"aa={1:22,3:44}; print aa; print
> 'asdf'\""
> +./scripts/run.py --api -e "/python -m SimpleHTTPServer 8000"
> diff --git a/python27/python.c b/python2x/python.c
> similarity index 100%
> rename from python27/python.c
> rename to python2x/python.c
> diff --git a/python27/usr.manifest b/python2x/usr.manifest
> similarity index 100%
> rename from python27/usr.manifest
> rename to python2x/usr.manifest
> --
> 2.17.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "OSv Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osv-dev+unsubscr...@googlegr
Re: [RFC] Support firecracker
On Sun, Jan 6, 2019 at 11:32 AM Waldek Kozaczuk
wrote:
>
>
> On Saturday, January 5, 2019 at 4:09:23 AM UTC-5, דור לאור wrote:
>>
>> Great stuff Waldek! Is unix socket the normal way to pass parameters for
>> Firecracker?
>>
> I think so. There is also experimental vsock interface but I am not
> familiar with it and not sure what purpose of it would be (
> https://github.com/firecracker-microvm/firecracker/issues/650).
>
Vsock was added for easier guest host communication with zero configuration
(I happen to the author of the vsock kernel module). In theory, they can
use vsock for anything that a socket is useful between host and guest.
Btw, there are some work to implement nfs over vsock.
>
>> How's the boot speed vs Qemu?
>>
> I have posted some numbers in my other email to the group but here are
> some more details.
>
> First of all my numbers come from running tests on my 5-years old MacBook
> pro that I have been using for all my OSv development in last three years.
> It is 4-core 2.3 GHz i7 machine. Not sure how it compares to newer models
> but given Moore's law does not work any more it might be still pretty fast.
>
> Architecture:x86_64
> CPU op-mode(s): 32-bit, 64-bit
> Byte Order: Little Endian
> CPU(s): 8
> On-line CPU(s) list: 0-7
> Thread(s) per core: 2
> Core(s) per socket: 4
> Socket(s): 1
> NUMA node(s):1
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 70
> Model name: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
> Stepping:1
> CPU MHz: 898.037
> CPU max MHz: 3500.
> CPU min MHz: 800.
> BogoMIPS:4589.68
> Virtualization: VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:256K
> L3 cache:6144K
> L4 cache:131072K
>
> Additionally firecracker startup/configuration is more fine-grained than
> QEMU which does everything in one shot (start VMM process, configure
> resources, start guest, etc). With firecracker it is broken down like
> follows:
>
>1. Start VMM process which listen on socket for API calls (I have not
>measured it but seems very fast).
>2. Make API call to:
> - create instance that specified number of vCPUs, memory and kernel
> loader file path
> - configure block device
> - configure networking device
> - all these calls seem to take less than 1ms and can be executed in
> any order it seems
>3. Make API call to start instance that eventually starts guest
>
> So here are some log snippets (2,3) and OSv bootchart from running
> native-example rofs image (no networking):
>
> Add block device:
> 2019-01-05T20:21:44.*096*617431 [anonymous-instance:INFO:api_server/src/
> http_service.rs:599] The API server received a synchronous Put request on
> "/drives/rootfs" with body "{n "drive_id": "rootfs",n "path_on_host":
> "/home/wkozaczuk/projects/osv/build/release/usr.rofs",n "is_root_device":
> false,n "is_read_only": falsen }".
> 2019-01-05T20:21:44.*096*659174 [anonymous-instance:INFO:api_server/src/
> http_service.rs:565] The synchronous Put request on "/drives/rootfs" with
> body "{n "drive_id": "rootfs",n "path_on_host":
> "/home/wkozaczuk/projects/osv/build/release/usr.rofs",n "is_root_device":
> false,n "is_read_only": falsen }" was executed successfully. Status code:
> 204 No Content.
>
> Create instance:
> 2019-01-05T20:21:44.*1085*43339 [anonymous-instance:INFO:api_server/src/
> http_service.rs:599] The API server received a synchronous Put request on
> "/boot-source" with body "{n "kernel_image_path":
> "/home/wkozaczuk/projects/waldek-osv/build/release/loader-stripped.elf",n
> "boot_args": "--bootchart /hello"n }".
> 2019-01-05T20:21:44.*108*584295 [anonymous-instance:INFO:api_server/src/
> http_service.rs:565] The synchronous Put request on "/boot-source" with
> body "{n "kernel_image_path":
> "/home/wkozaczuk/projects/waldek-osv/build/release/loader-stripped.elf",n
> "boot_args": "--bootchart /hello"n }" was executed successfully. Status
> code: 204 No Content.
>
> Start instance that starts guest and terminates the process eventually:
> 2019-01-05T20:21:44.119820357 [anonymous-instance:INFO:api_server/src/
> http_service.rs:599] The API server received a synchronous Put request on
> "/actions" with body "{n "action_type": "InstanceStart"n }".
> 2019-01-05T20:21:44.119837722 [anonymous-instance:INFO:vmm/src/lib.rs:1104]
> VMM received instance start command
> 2019-01-05T20:21:44.119903817 [anonymous-instance:INFO:vmm/src/
> vstate.rs:97] Guest memory starts at 7faddec0
>
> 2019-01-05T20:21:44.1*24*761979 [anonymous-instance:INFO:api_server/src/
> http_service.rs:565] The synchronous Put request on "/actions" with body
> "{n "action_type": "InstanceStart"n }" was executed successfully. Status
> code: 204 No Content.
> 2019-01-05T20:21:44.*141*417423 [anonymous-instance:INFO:vmm/src/
> lib.rs:1163] Vmm is
