juju 2.0 no longer supports KVM for local provider

[Matt Bruzek]

I was moving to juju.2.0-alpha2-xenial-amd64 and I noticed that I can not bootstrap my KVM environment when I moved my configuration from 1.25 to 2.0-alpha2

I realize the "local" provider is going away in 2.0. Talking with KVM on my local system is a feature I use very much, and removing that feature may upset some customers.

Of course there are ways to talk to libvirt deamons on different systems qemu+ssh://IP-address/system. Is it possible we are going to get a libvirt provider that is "non-local"? If so please tell me how to properly configure that.

If there are no plans for KVM in 2.0 that is a big feature of a popular virtualization technology that we are removing from Juju. KVM works very well on Linux and I can imagine many users making use of the KVM type in previous versions of Juju (as I was using it EVERY day).

[Robert Ayres (robert-ayres)]

I currently use local KVM provider as a much faster way of validating SDN charms. Removing this support breaks my current workflow and makes testing cycles that much longer.

I think it's a mistake to remove this without drop-in replacement functionality.

[Charles Butler (lazypower)]

The alternative value proposition, is to setup a VMAAS on KVM, and that is not a simple task really.

I'm +1 for Robert Ayres workflow with SDN, I have a similar workflow blocker for App containers on new/bleeding edge binaries of docker.

[Adam Stokes (adam-stokes)]

I would like to offer another alternative. Make KVM(libvirt) a first class provider type like LXD? I believe the container type is still supported meaning you can `juju deploy --to 1:kvm` but I think there is a real use case for having KVM supported as an additional 'cloud' provider type.

[Matt Bruzek (mbruzek)]

Is there any decision or movement on this bug? An actual Juju user asked me about KVM support in #juju yesterday 03/28/2016. deanman was looking to use Docker with Juju, which does not work on LXC/LXD. Had to make sure he was using version 1.25 because as far as I know juju 2.0 does not work with a KVM provider.

[Richard Harding (rharding)]

KVM will be a supported container type on some substrates (MAAS, or OpenStack) but will not be in the local provider. We will investigate a KVM provider for the roadmap, but currently the goal is to focus on lxd for the local use cases and updating lxd where it does not work for the needs of our users.

[Matt Bruzek (mbruzek)]

Thanks for commenting Rick.

I understand we don't have enough time to do all the things we want, and we must prioritize the features/fixes. I also understand this is a lower priority on the grand scheme. And you have made the tough call.

Having a deploy "to" KVM _target_ is not the same as having a Juju provider that works with KVM or libvirt. Technically LXD works with other container technologies like Docker, but currently only if you run LXD manually (on the beta 16.04 release) and with special flags that enable Docker compatibility. Even when I get finally get Docker running the experience has many problems ( https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1560685 ) and Docker on LXD is not a very good user experience. Because of all the manual steps and series requirements, I have not seen anyone successfully using Juju LXD containers running Docker, and with the complexity I don't expect that anytime soon.

Having a _local provider_ that does not work with Docker is a regression from a Juju perspective. Customers are already asking for running Docker on the local provider in #juju and I am not able to give them a good answer. I would say that not being able to use Docker on the local provider is an adoption blocker for developers.

[Anastasia (anastasia-macmood)]

KVM support landed in 2.2.

It has been tested as a juju deploy target on AMD64 and ARM64. There is an issue on ARM64 on trusty, more information in the email thread on juju-dev mailing list, "KVM support in Juju on ARM64".

Related bug # 1349854.