Allow flexibility in running bare vm-base containers

[feliksik]

Hi Sheng,

I think RancherVM is great, the startvm script helped me a lot in getting containers to run. I am forking RancherVm and I'd like to have your opinion on the following approach, to see if it makes sense to keep contributing to upstream.

I'm arguing that putting the vm base images in the containers is user friendly for the Proof-of-Concept, until you want to run other images (which you often want). Then the user is burdened with managing a docker repo to push to, or build the images himself. So the data management problem is then moved to managing docker repo's.

My approach is based on 2 ideas:

1. For many use cases you want to manage your images with another way than inside the containers (e.g. separate docker volumes, or just on the host)
2. you want to be able to volume-mount a directory with multiple vm-image files, and specify which one to use.

Do you think this makes sense?

If so, properties of the proposed changes:

• backwards compatible with the rancheros/ubuntu/centos sub-images
• allow running vm-base with an -e IMAGE variable that specifies the file name or directory relative to /base-image .
• if /base_image/$IMAGE is a directory, use the first file as listed by ls -1 .
• if /base_image/$IMAGE is a symlink, resolve it so that the qcow2 chain works fine (reason for the above to is allow for more flexible qcow2 image chains)

[feliksik]

Testing:

• cd vm/image/base
• ./fetch-images.sh # puts your image files in ~/ranchervm-images
• ./create-vm-container.sh myvmname ubuntu # to start an ubuntu image

[liyimeng]

This sound a great idea +1!

[JonathonReinhart]

@feliksik I'm intrigued by this proposal, but I must ask: What purpose does Docker serve in your system?

[feliksik]

@JonathonReinhart I use docker for various purposes. Do you mean, what's the point of using Docker if I aim to manage the qcow2 images without it? I don't know. It's all an experiment, as far as I am concerned.

I don't use RancherVM at the moment. It's a great proof of concept, but I never used it in production.

I honestly don't know whether the whole proposal is a good idea, you can just as well consider it feature bloat that will be confusing. I don't know.

[JonathonReinhart]

Do you mean, what's the point of using Docker if I aim to manage the qcow2 images without it?

@feliksik Yes, exactly.

It's all an experiment, as far as I am concerned.

I completely understand and agree!

I am intrigued, and ask because I've been having the same conversation with some of my colleagues. We want to apply Docker-like semantics to VMs for testing purposes, and we're wondering whether using Docker to encapsulate the VMs (like RancherVM) makes sense. Or, forget about Docker altogether, and using the native qcow2 image chaining. We're also wondering whether Libvirt has any support for this kind of thing.

[feliksik]

Note that the RancherVM implementation also uses qcow2 image chaining. Having said that, I think it's all a matter of abstraction. KVM and even libvirt have a gazillion options, but sometimes you just want to set cpu's and memory and go, and RancherVM gives you a lightweight interface.

If it's just a matter of testing for you, it may work well. But as soon as you want more fanciness (mounting extra disks, networks, whatever), you may end up re-implementing Openstack... But then again, this may be easier than installing Openstack :-P

[JonathonReinhart]

Note that the RancherVM implementation also uses qcow2 image chaining.

Where does it do this? My understanding was that it just had a single qcow2 image in /base_image. If you made changes in the VM, they were contained in the Docker container, which you could then commit or destroy, just like any other Docker container. I didn't see anything that dealt with more than just that one qcow2 image.

[feliksik]

@JonathonReinhart https://github.com/rancher/vm/blob/master/image/base/startvm#L158

This is a performance optimization over the docker FS layers, but it may depend on your use-case and docker FS implementation whether you care or notice.

[pwFoo]

Would be great to replace the vm-image to be more flexible!

Also with VM interfaces. It's possible to add additional (docker) networks to containers. So it would be great to map interfaces to the VM too.

[ahoeg]

Found BBVA/Kvm (https://github.com/rancher/vm/issues/84) which looks very interesting...

[LLParse]

This is an interesting proposal.

We like using Docker Registry as a distribution mechanism for the base images and probably won't deviate from that. However, we are seriously considering integration with external block storage systems for volumes and snapshots. It will then be trivial to store base images outside of a Docker Registry.

[cjellick]

Closing this due to staleness. Feel free to reopen or open a new PR if there's still a relevant change to be made. Thanks!