nlf / dhyve-os Goto Github PK

I'm wondering why each of those files is archived by tar instead of a plain text.

i don't like how it is now, it needs to be better. i hate that i have to run make build manually if i change files and then make again to get the artifacts out of it.

maybe it's best to just build everything in the image and then create a container without running it to extract the artifacts?

Because dhyve uses 8.8.8.8 for DNS the VM is unable to resolve DNS entries that the host can via VPN. Please offer a way to use the host for DNS resolution.

I tried build dhyve-os to support our enterprise but it has been running now for over 55 mins is this normal?

it's seems stuck here...

linux 4.3.3 Configuring
linux 4.3.3 Building
...

finally it continued then I got this and it failed:

cc1: some warnings being treated as errors
scripts/Makefile.modpost:113: recipe for target 'net/ipv4/netfilter/arptable_filter.mod.o' failed
make[2]: *** [net/ipv4/netfilter/arptable_filter.mod.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Makefile:1095: recipe for target 'modules' failed
make[1]: *** [modules] Error 2
package/pkg-generic.mk:196: recipe for target '/tmp/buildroot/output/build/linux-4.3.3/.stamp_built' failed
make: *** [/tmp/buildroot/output/build/linux-4.3.3/.stamp_built] Error 2
make: *** [build] Error 2

most users seem to just want the latest docker version, so let's preinstall whatever the latest is and keep the option to the init script in place so people can change it out easily

These lines in the Makefile:

    $(eval STR_CREATED=$$(shell docker inspect -f '{{.Created}}' $(BUILD_IMAGE) 2>/dev/null))
    $(eval IMG_CREATED=$$(shell date -j -u -f "%F %T" "$$(STR_CREATED)" +"%s" 2>/dev/null \
        || echo 0))

are supposed to get the created timestamp of the image. But on my system, docker inspect returns an ISO 8601 time stamp like 2015-12-24T08:18:59.927830094Z, and that doesn't match %F %T. (%FT%T works.)

Does %F %T work for others? Is the problem specific to my Docker version?

$ docker inspect -f '{{.Created}}' dhyve-os-builder
2015-12-24T08:18:59.927830094Z

$ date -j -u -f "%F %T" "2015-12-24T08:18:59.927830094Z" +"%s"
Failed conversion of ``2015-12-24T08:18:59.927830094Z'' using format ``%F %T''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
            [-f fmt date | [[[mm]dd]HH]MM[[cc]yy][.ss]] [+format]

$ date -j -u -f "%FT%T" "2015-12-24T08:18:59.927830094Z" +"%s"
Warning: Ignoring 11 extraneous characters in date string (.927830094Z)
1450945139

$ docker version
Client:
 Version:      1.8.2
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   0a8c2e3
 Built:        Thu Sep 10 19:10:10 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

It seems the rootfs/etc/init.d/S51docker script is overwriting the docker binary on startup with a 0-byte file.

Hey,

getting docker from https://get.docker.io/builds/Linux/x86_64/docker-${docker_version} no longer works. It throws a 403. If you add .tgz on the end however it works. You can run this through gunzip then tar to get the binaries.

Since the overlay size wasn't big enough to hold all the files. I put docker in /usr/bin/ and docker-* in /bin/

Cheers,
Ben

Install docker with an init script which reads an env variable (docker_version=1.10.0) and installs the appropriate version.

The default docker Debian package sets

ulimit -n 1048576
if [ "$BASH" ]; then
        ulimit -u 1048576
else
        ulimit -p 1048576
fi  

DhyveOS has much smaller limits, and although they can be changed using --ulimit when doing docker run, this causes some images that work using the Debian docker to fail with DyhveOS. It would be cool if these limits could be increased.

Currently docker will bind ports to 0.0.0.0 on the VM which means that when running docker-compose port postgres 5432 (or just using docker inspect) we get back 0.0.0.0:<bound port>. This means that I need to replace the 0.0.0.0 with the VM's IP in order to use it, putting back some of the pain that DLite might otherwise save.

It would be very useful if --ip=192.168.x.x was passed to the docker daemon when starting so that it would by default bind ports to the interface that we can reach from outside the VM. This way docker inspect and docker-compose would show an IP:PORT combination that can be connected to as-is.

That way I never have to care what the IP address of the VM is.

I've been using -o noatime,discard,ssd,autodefrag,compress=lzo,space_cache when mounting btrfs for docker storage on ec2. But we should do some tests to see what's good under xhyve.

I see that 3.0.0 has been replaced a few times now, can we bump the version each time so I know if I'm out of date?

Sorry to be a pest, lol.

Ty,
Trevor

Hi!

This is related to dlite (v1 with NFS) and most likely future versions of dlite/dhyve-os since I've read that you are planning on moving back to NFS from 9P. Really looking forward to a future v2 of dlite with NFS since the performance of 9P is really terrible for my use cases.

The only standing issue that I've had with dlite is the annoying and frequent behavior that file updates are not synced between server and host unless you wait for 5-10 seconds.

After the finding this stack overflow question and including the actimeo=1 option in the mount command in the legacy branch everything seems to be working perfectly.

Is this something you would consider including in the upcoming NFS solution for v2?

In c61d125 CONFIG_FUSE_FS was unset.

https://github.com/nlf/dhyve-os/blob/master/config/kernel#L2279

Are you open to a PR to bring FUSE support back? e.g

diff --git a/config/kernel b/config/kernel
index 818ed0b..7fb71f9 100644
--- a/config/kernel
+++ b/config/kernel
@@ -2253,7 +2253,8 @@ CONFIG_FANOTIFY=y
 # CONFIG_QUOTA is not set
 # CONFIG_QUOTACTL is not set
 # CONFIG_AUTOFS4_FS is not set
-# CONFIG_FUSE_FS is not set
+CONFIG_FUSE_FS=y
CONFIG_OVERLAY_FS=y

#
# Caches

(I haven't preemptively sent a PR because I'm still using 2.2.0 and dlite 1.1.4, so haven't built a 3.0.0 beta to test CONFIG_FUSE_FS)

dhyve-os currently uses the overlay storage driver, which has a known issue that causes yum to fail in containers. (Documented in https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/)

Would it be reasonable to support and default to a different storage driver, such as AUFS or devicemapper?

Discussion directly coming from here: nlf/dlite#61

To be future-proof, a build and test environment should be created, that is able to build multiple images for each (?!) minor docker version?

My proposal would be:

• Let Travis CI build an image matrix and test it with the current version of dlite and docker

Should I try to implement such a thing with travis?

should remove the current resolv.conf in favor of this

Hey there. I tried the 2.3.1 image from my PR, but got a kernel error :( :

❯ dlite stop
❯ dlite update -v 2.3.1
❯ dlite start
❯ ps aux | grep dlite
leipert          6470   0.0  0.0  2425204    428 s002  R+   10:35AM   0:00.00 grep --color=auto dlite
❯ sudo dlite daemon
COM1 connected to /dev/ttys003
kexec: failed to load kernel /Users/leipert/.dlite/bzImage

I also tried to dlite install with -v 2.3.1, which doesn't work either.

The 2.3.0 image starts, but they changed the API version from 1.11.0 to 1.11.1

think this is due to a kernel configuration problem