github.com/niedbalski/juju@v0.0.0-20190215020005-8ff100488e47/container/kvm/doc.go (about) 1 // Copyright 2016 Canonical Ltd. 2 // Licensed under the AGPLv3, see LICENCE file for details. 3 4 /* 5 Package kvm provides the facilities to deploy to kvm instances. 6 7 kvm implements the container interface for worker/provisioner to manage 8 applications deployed to kvm based 'containers' (see 9 juju/worker/provisioner/provisioner.go:containerProvisioner and 10 juju/container/container.go:container.Manager). The worker provisioner 11 specifics are in juju/worker/provisioner/kvm-broker.go and 12 juju/worker/container_initilisation.go. 13 14 The provisioner worker manages kvm containers through the interface provided in 15 this package, see: containerfactory.go, container.go, instance, and 16 initialization.go. That is to say those files provide the container.Manager 17 interface while the rest of this package are the implementation of 18 container.Manager for kvm instances. 19 20 This package originally depended on the ubuntu uvtool apt package. This meant 21 that kvm would only work on ubuntu on amd64. The goal of removing Juju's 22 dependency on uvtool is to allow kvm to also work on arm64 and ppc64el. 23 However, it is still only expected to work on ubuntu. 24 25 When removing uvtool we (redir) performed a survey of the libvirt and qemu go 26 package landscape. There are a number of cgo based libraries and two possibly 27 promising ones once they are further developed: 28 github.com/digitalocean/go-libvirt and github.com/digitalocean/go-qemu. Those 29 packages are nascent and alpha at the time of this writing. They implement pure 30 go interfaces to libvirt and qemu by way of libvirt/qemu's custom RPC protocol. 31 While this would reduce the number of commands that require shelling out, it 32 wouldn't provide a way to create and manage disk images. So unless someone 33 implements qemu-utils and genisoimage in go, we'll always need to shell out for 34 those calls. The wrapped commands exist, shockingly, in wrappedcmds.go with 35 the exception of libvirt pool initialisation bits which are in 36 initialization.go. 37 38 After the provisioner initializes the kvm environment, we synchronise (fetch if 39 we don't have one) an ubuntu qcow image for the appropriate series and 40 architecture. This happens in sync.go and uses Juju's simplestreams 41 implementation in juju/environs/simplestreams and juju/environs/imagedownloads. 42 Once we fetch a compressed ubuntu image we then uncompress and convert it for 43 use into the libvirt storage pool. The storage pool is named 'juju-pool' and it 44 is located in $JUJU_DATADIR/kvm/guests, where JUJU_DATADIR is the value 45 returned by paths.DataDir. This ubuntu image is then used as a backing store 46 for our kvm instances for given series. 47 48 NB: Sharing a backing store across multiple instances allow us to save 49 significant disk space, but comes at a price too. The backing store is read 50 only to the volumes which use it and it cannot be updated. So we cannot easily 51 update common elements the way that lxd and snappy do with squashfs based 52 backing stores.This is to the best of my understanding, so corrections or 53 updates are welcome. 54 55 Once the backing store is ready, we create a system disk and a datasource disk. 56 The system disk is a sparse file with a maximum file size which uses the 57 aforementioned backing store as its base image. The data source disk is an iso 58 image with user-data and meta-data for cloud-init's NoCloud method to configure 59 our system. The cloud init data is written in kvm.go, via a call to machinery 60 in juju/cloudconfig/containerinit/container_userdata.go. Destruction of a 61 container removes the system and data source disk files, but leaves the backing 62 store alone as it may be in use by other domains. 63 64 TBD: Put together something to send progress through a reader to the callback 65 function. We need to follow along with the method as implemented by LXD. 66 67 */ 68 package kvm