QEMU & QEMU-KVM VMs in docker
3,681 views
Skip to first unread message
unclejack
Aug 22, 2013, 1:45:06 PM8/22/13
to docke...@googlegroups.com
Hello,
I've been working on a project to run VMs in Docker containers. These VMs are supposed to boot quickly by restoring from snapshots, thus providing a ready to use VM in 5-15 seconds. This is done via 2 snapshots, one snapshot was taken when using KVM and one snapshot was taken when running in full emulation mode.
The container runs this system on startup and the VM can then be used in a fashion similar to that of vagrant VMs. In fact, the VM is based on a VM built by packer and the vagrant SSH keys are also used.
Startup process of the VM in the Docker container run with -privileged:
1. check if the KVM module is loaded
2. attempt to set up the KVM device node
3. attempt to start the VM by restoring the snapshot taken with KVM enabled
4. if 3 failed, try to start the VM by restoring the snapshot taken with KVM disabled
5. run things on the VM: ssh -p 2222 vag...@127.0.0.1
The purpose of these VMs is to allow some more advanced testing and to perform testing which may break something on the host system.
The Docker tests finish running just like on the host system when using KVM acceleration. However, they're very slow and they fail to run at all when running on the fully emulated QEMU VM.
Would there be interest in fixing the Docker testing to make it work under fully emulated QEMU VMs?
Would there be any value in using these VMs for some kind of tasks (testing, testing packages, testing kernel bugs)?
Do you think it'd be OK to use this kind of VMs for building the vbox/vmware/qemu/xen/ec2 VM images to be downloaded by users?
The image is available as backjlack/qemu on the official registry and it can be used like this:
$ docker run -i -t -privileged backjlack/qemu
# you should get to a shell prompt in 5-15 seconds
# exit will close the SSH session and close the container & the VM
Observation: mknod will fail to create the /dev/kvm device node if KVM isn't available. Some errors will be printed to the screen, but the fully emulated VM should work.
I will provide the Dockerfile and the files used to create that Docker image soon.
I've been working on a project to run VMs in Docker containers. These VMs are supposed to boot quickly by restoring from snapshots, thus providing a ready to use VM in 5-15 seconds. This is done via 2 snapshots, one snapshot was taken when using KVM and one snapshot was taken when running in full emulation mode.
The container runs this system on startup and the VM can then be used in a fashion similar to that of vagrant VMs. In fact, the VM is based on a VM built by packer and the vagrant SSH keys are also used.
Startup process of the VM in the Docker container run with -privileged:
1. check if the KVM module is loaded
2. attempt to set up the KVM device node
3. attempt to start the VM by restoring the snapshot taken with KVM enabled
4. if 3 failed, try to start the VM by restoring the snapshot taken with KVM disabled
5. run things on the VM: ssh -p 2222 vag...@127.0.0.1
The purpose of these VMs is to allow some more advanced testing and to perform testing which may break something on the host system.
The Docker tests finish running just like on the host system when using KVM acceleration. However, they're very slow and they fail to run at all when running on the fully emulated QEMU VM.
Would there be interest in fixing the Docker testing to make it work under fully emulated QEMU VMs?
Would there be any value in using these VMs for some kind of tasks (testing, testing packages, testing kernel bugs)?
Do you think it'd be OK to use this kind of VMs for building the vbox/vmware/qemu/xen/ec2 VM images to be downloaded by users?
The image is available as backjlack/qemu on the official registry and it can be used like this:
$ docker run -i -t -privileged backjlack/qemu
# you should get to a shell prompt in 5-15 seconds
# exit will close the SSH session and close the container & the VM
Observation: mknod will fail to create the /dev/kvm device node if KVM isn't available. Some errors will be printed to the screen, but the fully emulated VM should work.
I will provide the Dockerfile and the files used to create that Docker image soon.
Jérôme Petazzoni
Aug 22, 2013, 2:10:13 PM8/22/13
to unclejack, docker-dev
This is awesome.
On Thu, Aug 22, 2013 at 10:45 AM, unclejack <unclej...@gmail.com> wrote:
Would there be interest in fixing the Docker testing to make it work under fully emulated QEMU VMs?
Definitely. I noticed similar issues when running Docker tests within UML (User Mode Linux).
I would love to compare our respective test logs (mine are on e.g. https://travis-ci.org/jpetazzo/docker/builds/10435015).
Typically, an odd test will time out (borking the whole run), and sometimes, a TestStart or TestRunHostname will fail inexplicably.
Would there be any value in using these VMs for some kind of tasks (testing, testing packages, testing kernel bugs)?
If we can get this working in QEMU, I would be happy to update my travis scripts to use QEMU instead of UML.
So count me in :-)
Do you think it'd be OK to use this kind of VMs for building the vbox/vmware/qemu/xen/ec2 VM images to be downloaded by users?
Maybe.
The image is available as backjlack/qemu on the official registry and it can be used like this:
$ docker run -i -t -privileged backjlack/qemu
2013/08/22 11:09:49 Error: No such image: backjlack/qemu (tag: latest)
?
I will provide the Dockerfile and the files used to create that Docker image soon.
Thanks!
unclejack
Aug 22, 2013, 3:19:33 PM8/22/13
to docke...@googlegroups.com, unclejack
On Thursday, August 22, 2013 9:10:13 PM UTC+3, Jérôme Petazzoni wrote:
This is awesome.On Thu, Aug 22, 2013 at 10:45 AM, unclejack <unclej...@gmail.com> wrote:
Would there be interest in fixing the Docker testing to make it work under fully emulated QEMU VMs?
Definitely. I noticed similar issues when running Docker tests within UML (User Mode Linux).I would love to compare our respective test logs (mine are on e.g. https://travis-ci.org/jpetazzo/docker/builds/10435015).Typically, an odd test will time out (borking the whole run), and sometimes, a TestStart or TestRunHostname will fail inexplicably.
This is the output I was getting:
http://paste.ubuntu.com/6007223/
The whole thing takes about 400-500 seconds to run when running in full emulation mode.
Would there be any value in using these VMs for some kind of tasks (testing, testing packages, testing kernel bugs)?If we can get this working in QEMU, I would be happy to update my travis scripts to use QEMU instead of UML.So count me in :-)
That sounds great!
Do you think it'd be OK to use this kind of VMs for building the vbox/vmware/qemu/xen/ec2 VM images to be downloaded by users?Maybe.
The image is available as backjlack/qemu on the official registry and it can be used like this:
$ docker run -i -t -privileged backjlack/qemu2013/08/22 11:09:49 Error: No such image: backjlack/qemu (tag: latest)?
I've removed the old image. This should be fixed now.
Reply all
Reply to author
Forward
0 new messages