diff options
| -rw-r--r-- | docs/providers/libvirt/r/volume.html.markdown | 42 | ||||
| -rw-r--r-- | website/docs/index.html.markdown (renamed from docs/providers/libvirt/index.html.markdown) | 22 | ||||
| -rw-r--r-- | website/docs/r/cloudinit.html.markdown (renamed from docs/providers/libvirt/r/cloudinit.html.markdown) | 6 | ||||
| -rw-r--r-- | website/docs/r/coreos_ignition.html.markdown (renamed from docs/providers/libvirt/r/coreos_ignition.html.markdown) | 42 | ||||
| -rw-r--r-- | website/docs/r/domain.html.markdown (renamed from docs/providers/libvirt/r/domain.html.markdown) | 244 | ||||
| -rw-r--r-- | website/docs/r/network.markdown (renamed from docs/providers/libvirt/r/network.markdown) | 21 | ||||
| -rw-r--r-- | website/docs/r/volume.html.markdown | 67 | ||||
| -rw-r--r-- | website/libvirt.erb | 38 |
8 files changed, 301 insertions, 181 deletions
diff --git a/docs/providers/libvirt/r/volume.html.markdown b/docs/providers/libvirt/r/volume.html.markdown deleted file mode 100644 index 2c639a14..00000000 --- a/docs/providers/libvirt/r/volume.html.markdown +++ /dev/null @@ -1,42 +0,0 @@ ---- -layout: "libvirt" -page_title: "Libvirt: libvirt_volume" -sidebar_current: "docs-libvirt-volume" -description: |- - Manages a storage volume in libvirt ---- - -# libvirt\_volume - -Manages a storage volume in libvirt. For more information see -[the official documentation](https://libvirt.org/formatstorage.html). - -## Example Usage - -``` -resource "libvirt_volume" "opensuse_leap" { - name = "opensuse_leap" - source = "http://download.opensuse.org/repositories/Cloud:/Images:/Leap_42.1/images/openSUSE-Leap-42.1-OpenStack.x86_64.qcow2" -} - -``` - -## Argument Reference - -The following arguments are supported: - -* `name` - (Required) A unique name for the resource, required by libvirt. - Changing this forces a new resource to be created. -* `pool` - (Optional) The pool where the resource will be created. - If not given, the `default` pool will be used. -* `source` - (Optional) If specified, the image will be retrieved from this URL and uploaded into - libvirt. Only remote HTTP urls are supported for now. -* `size` - (Optional) The size of the volume in bytes (if you don't like this, help fix [this issue](https://github.com/hashicorp/terraform/issues/3287). - If `source` is specified, `size` will be set to the source image file size. -* `base_volume_id` - (Optional) The backing volume (CoW) to use for this volume. -* `base_volume_name` - (Optional) The name of the backing volume (CoW) to use for this volume. Note well: when `base_volume_pool` is not specified the volume is going to be searched inside of `pool`. -* `base_volume_pool` - (Optional) The name of the pool containing the volume defined by `base_volume_name`. - -## Attributes Reference - -* `id` - a unique identifier for the resource diff --git a/docs/providers/libvirt/index.html.markdown b/website/docs/index.html.markdown index e3118d4c..6dc0cfe1 100644 --- a/docs/providers/libvirt/index.html.markdown +++ b/website/docs/index.html.markdown @@ -8,15 +8,19 @@ description: |- # Libvirt Provider -The Libvirt provider is used to interact with Linux [libvirt](https://libvirt.org) hypervisors. +The Libvirt provider is used to interact with Linux +[libvirt](https://libvirt.org) hypervisors. -The provider needs to be configured with the proper connection information before it can be used. +The provider needs to be configured with the proper connection information +before it can be used. -While libvirt can be used with several types of hypervisors, this provider focuses on [KVM](http://libvirt.org/drvqemu.html). Other drivers may not be working and haven't been tested. +~> **Note:** while libvirt can be used with several types of hypervisors, this +provider focuses on [KVM](http://libvirt.org/drvqemu.html). Other drivers may not be +working and haven't been tested. ## Example Usage -``` +```hcl # Configure the Libvirt provider provider "libvirt" { uri = "qemu:///system" @@ -35,6 +39,12 @@ The following keys can be used to configure the provider. * `uri` - (Required) The [connection URI](https://libvirt.org/uri.html) used to connect to the libvirt host. - This URI can also be specified with the `LIBVIRT_DEFAULT_URI` shell environment - variable. +## Environment variables + +The libvirt connection URI can also be specified with the `LIBVIRT_DEFAULT_URI` +shell environment variable. +```hcl +$ export LIBVIRT_DEFAULT_URI="qemu+ssh://root@192.168.1.100/system" +$ terraform plan +``` diff --git a/docs/providers/libvirt/r/cloudinit.html.markdown b/website/docs/r/cloudinit.html.markdown index e30cf55a..5cd67fd1 100644 --- a/docs/providers/libvirt/r/cloudinit.html.markdown +++ b/website/docs/r/cloudinit.html.markdown @@ -8,12 +8,12 @@ description: |- # libvirt\_cloudinit -Manages a [cloud-init](http://cloudinit.readthedocs.io/) ISO disk that can be used to customize a Domain during 1st -boot. +Manages a [cloud-init](http://cloudinit.readthedocs.io/) ISO disk that can be +used to customize a domain during first boot. ## Example Usage -``` +```hcl resource "libvirt_cloudinit" "commoninit" { name = "commoninit.iso" local_hostname = "node" diff --git a/docs/providers/libvirt/r/coreos_ignition.html.markdown b/website/docs/r/coreos_ignition.html.markdown index ae95e77b..cac00305 100644 --- a/docs/providers/libvirt/r/coreos_ignition.html.markdown +++ b/website/docs/r/coreos_ignition.html.markdown @@ -9,12 +9,14 @@ description: |- # libvirt\_ignition Manages a [CoreOS Ignition](https://coreos.com/ignition/docs/latest/supported-platforms.html) -file written as a volume to a libvirt storage pool that can be used to customize a CoreOS Domain during 1st -boot. +file written as a volume to a libvirt storage pool that can be used to customize +a CoreOS Domain during first boot. + +~> **Note:** to make use of Ignition files with CoreOS the host must be running QEMU v2.6 or greater. ## Example Usage -``` +```hcl resource "libvirt_ignition" "ignition" { name = "example.ign" content = <file-name or ignition object> @@ -33,6 +35,38 @@ The following arguments are supported: information that will be used to create the Ignition file in the libvirt storage pool. The `content` can be * The name of file that contains Ignition configuration data, or its contents - * A rendered Terraform Ignition object + * A rendered terraform Ignition object Any change of the above fields will cause a new resource to be created. + +## Integration with Ignition provider + +The `libvirt_ignition` resource can be integrated with terraform +[Ignition Provider](/docs/providers/ignition/index.html). + +An example where a terraform ignition provider object is used: + +```hcl +# Systemd unit resource containing the unit definition +resource "ignition_systemd_unit" "example" { + name = "example.service" + content = "[Service]\nType=oneshot\nExecStart=/usr/bin/echo Hello World\n\n[Install]\nWantedBy=multi-user.target" +} + +# Ignition config include the previous defined systemd unit resource +resource "ignition_config" "example" { + systemd = [ + "${ignition_systemd_unit.example.id}", + ] +} + +resource "libvirt_ignition" "ignition" { + name = "ignition" + content = "${ignition_config.example.rendered}" +} + +resource "libvirt_domain" "my_machine" { + coreos_ignition = "${libvirt_ignition.ignition.id}" + ... +} +``` diff --git a/docs/providers/libvirt/r/domain.html.markdown b/website/docs/r/domain.html.markdown index 35feb4c8..6c40cb10 100644 --- a/docs/providers/libvirt/r/domain.html.markdown +++ b/website/docs/r/domain.html.markdown @@ -13,9 +13,9 @@ Manages a VM domain resource within libvirt. For more information see ## Example Usage -``` +```hcl resource "libvirt_domain" "default" { - name = "test" + name = "test" } ``` @@ -24,58 +24,34 @@ resource "libvirt_domain" "default" { The following arguments are supported: * `name` - (Required) A unique name for the resource, required by libvirt. - Changing this forces a new resource to be created. -* `memory` - (Optional) The amount of memory in MiB. If not specified the domain will be - created with 512 MiB of memory - be used. -* `vcpu` - (Optional) The amount of virtual CPUs. If not specified, a single CPU will be created. -* `running` - (Optional) Use `false` to turn off the instance. If not specified, true is assumed and the instance, if stopped, will be started at next apply. -* `disk` - (Optional) An array of one or more disks to attach to the domain. The `disk` object structure is documented below. -* `network_interface` - (Optional) An array of one or more network interfaces to attach to the domain. The `network_interface` object structure is documented below. -* `metadata` - (Optional) A string containing arbitrary data. This is going to be - added to the final domain inside of the [metadata tag](https://libvirt.org/formatdomain.html#elementsMetadata). - This can be used to integrate terraform into other tools by inspecting the - the contents of the `terraform.tf` file. + Changing this forces a new resource to be created. +* `cpu` - (Optional) Configures CPU mode. See [below](#cpu-mode) for more + details. +* `vcpu` - (Optional) The amount of virtual CPUs. If not specified, a single CPU + will be created. +* `memory` - (Optional) The amount of memory in MiB. If not specified the domain + will be created with 512 MiB of memory be used. +* `running` - (Optional) Use `false` to turn off the instance. If not specified, + true is assumed and the instance, if stopped, will be started at next apply. +* `disk` - (Optional) An array of one or more disks to attach to the domain. The + `disk` object structure is documented [below](#handling-disks). +* `network_interface` - (Optional) An array of one or more network interfaces to + attach to the domain. The `network_interface` object structure is documented + [below](#handling-network-interfaces). * `cloudinit` - (Optional) The `libvirt_cloudinit` disk that has to be used by the domain. This is going to be attached as a CDROM ISO. Changing the cloud-init won't cause the domain to be recreated, however the change will have effect on the next reboot. -* `cpu` - (Optional) Configures CPU mode. -* `autostart` - (Optional) Set to `true` to start the domain on host boot up. If not specified `false` is assumed. -* `filesystem` - (Optional) An array of one or more host filesystems to attach to the domain. The `filesystem` object structure is documented below. - -There is an optional `coreos_ignition` parameter: -* `coreos_ignition` (Optional) The `libvirt_ignition` resource that is to be used by - the CoreOS domain. - -An example where a Terraform ignition provider object is used: -``` -# Systemd unit resource containing the unit definition -resource "ignition_systemd_unit" "example" { - name = "example.service" - content = "[Service]\nType=oneshot\nExecStart=/usr/bin/echo Hello World\n\n[Install]\nWantedBy=multi-user.target" -} - -# Ignition config include the previous defined systemd unit resource -resource "ignition_config" "example" { - systemd = [ - "${ignition_systemd_unit.example.id}", - ] -} +* `autostart` - (Optional) Set to `true` to start the domain on host boot up. + If not specified `false` is assumed. +* `filesystem` - (Optional) An array of one or more host filesystems to attach to + the domain. The `filesystem` object structure is documented + [below](#sharing-filesystem-between-libvirt-host-and-guest). +* `coreos_ignition` - (Optional) The + [libvirt_ignition](/docs/providers/libvirt/r/coreos_ignition.html) resource + that is to be used by the CoreOS domain. -resource "libvirt_ignition" "ignition" { - name = "ignition" - content = "${ignition_config.example.rendered}" -} - -resource "libvirt_domain" "my_machine" { - coreos_ignition = "${libvirt_ignition.ignition.id}" - ... -} -``` - -Note that to make use of Ignition files with CoreOS the host must be running -QEMU v2.6 or greater. +### UEFI images Some extra arguments are also provided for using UEFI images: @@ -91,8 +67,7 @@ In that case, `libvirt` will copy that variables file into a file specific for t So you should typically use the firmware as this, -``` - +```hcl resource "libvirt_domain" "my_machine" { name = "my_machine" firmware = "/usr/share/qemu/ovmf-x86_64-code.bin" @@ -107,12 +82,14 @@ resource "libvirt_domain" "my_machine" { and `/etc/libvirt/qemu.conf` should contain: -``` +```hcl nvram = [ "/usr/share/qemu/ovmf-x86_64-code.bin:/usr/share/qemu/ovmf-x86_64-vars.bin" ] ``` +### Handling disks + The `disk` block supports: * `volume_id` - (Required) The volume id to use for this disk. @@ -121,9 +98,8 @@ model is set to `virtio-scsi` * `wwn` - (Optional) Specify a WWN to use for the disk if the disk is using a scsi controller, if not specified then a random wwn is generated for the disk -If you have a volume with a template image, create a second volume using the image as the backing volume, and then use the new volume as the volume for the disk. This way the image will not be modified. -``` +```hcl resource "libvirt_volume" "leap" { name = "leap" source = "http://someurl/openSUSE_Leap-42.1.qcow2" @@ -140,20 +116,14 @@ resource "libvirt_domain" "domain1" { volume_id = "${libvirt_volume.mydisk.id}" scsi = "yes" } - - network_interface { - network_id = "${libvirt_network.net1.id}" - hostname = "master" - addresses = ["10.17.3.3"] - mac = "AA:BB:CC:11:22:22" - wait_for_lease = 1 - } } ``` -Also note that the `disk` block is actually a list of maps, so it is possible to declare several, use the literal list and map syntax or variables and interpolations, as in the following examples. +Also note that the `disk` block is actually a list of maps, so it is possible to +declare several of them by using either the literal list and map syntax as in +the following examples: -``` +```hcl resource "libvirt_domain" "my_machine" { ... disk { @@ -165,7 +135,7 @@ resource "libvirt_domain" "my_machine" { } ``` -``` +```hcl resource "libvirt_domain" "my_machine" { ... disk = [ @@ -179,53 +149,75 @@ resource "libvirt_domain" "my_machine" { } ``` -``` +```hcl resource "libvirt_domain" "my_machine" { ... disk = ["${var.disk_map_list}"] } ``` +### Handling network interfaces -The `network_interface` specifies a network interface that can be connected either to -a virtual network (the preferred method on hosts with dynamic / wireless networking -configs) or directly to a LAN. +The `network_interface` specifies a network interface that can be connected +either to a virtual network (the preferred method on hosts with +dynamic / wireless networking configs) or directly to a LAN. + +```hcl +resource "libvirt_domain" "domain1" { + name = "domain1" + + network_interface { + network_id = "${libvirt_network.net1.id}" + hostname = "master" + addresses = ["10.17.3.3"] + mac = "AA:BB:CC:11:22:22" + wait_for_lease = 1 + } +} +``` When using a virtual network, users can specify: -* `network_name` - (Optional) The name of an _existing_ network to attach this interface to. -The network will _NOT_ be managed by the Terraform/libvirt provider. -* `network_id` - (Optional) The ID of a network resource to attach this interface to. -The network will be under the control of the Terraform/libvirt provider. +* `network_name` - (Optional) The name of an _existing_ network to attach this + interface to. The network will _NOT_ be managed by the Terraform libvirt + provider. +* `network_id` - (Optional) The ID of a network resource to attach this + interface to. This is a + [network resource](/docs/providers/libvirt/r/network.html) managed by the + Terraform libvirt provider. * `mac` - (Optional) The specific MAC address to use for this interface. -* `addresses` - (Optional) An IP address for this domain in this network -* `hostname` - (Optional) A hostname that will be assigned to this domain resource in this network. -* `wait_for_lease`- (Optional) When creating the domain resource, wait until the network -interface gets a DHCP lease from libvirt, so that the computed ip addresses will be available -when the domain is up and the plan applied. +* `addresses` - (Optional) An IP address for this domain in this network. +* `hostname` - (Optional) A hostname that will be assigned to this domain + resource in this network. +* `wait_for_lease`- (Optional) When creating the domain resource, wait until the + network interface gets a DHCP lease from libvirt, so that the computed IP + addresses will be available when the domain is up and the plan applied. When connecting to a LAN, users can specify a target device with: -* `bridge` - Provides a bridge from the VM directly to the LAN. This assumes there is a bridge -device on the host which has one or more of the hosts physical NICs enslaved. The guest VM -will have an associated _tun_ device created and enslaved to the bridge. The IP range / network -configuration is whatever is used on the LAN. This provides the guest VM full incoming & -outgoing net access just like a physical machine. -* `vepa` - All VMs' packets are sent to the external bridge. Packets whose destination is a -VM on the same host as where the packet originates from are sent back to the host by the VEPA -capable bridge (today's bridges are typically not VEPA capable). -* `macvtap` - Packets whose destination is on the same host as where they originate from are -directly delivered to the target macvtap device. Both origin and destination devices need to -be in bridge mode for direct delivery. If either one of them is in vepa mode, a VEPA capable -bridge is required. -* `passthrough` - This feature attaches a virtual function of a SRIOV capable NIC directly to -a VM without losing the migration capability. All packets are sent to the VF/IF of the -configured network device. Depending on the capabilities of the device additional prerequisites -or limitations may apply; for example, on Linux this requires kernel 2.6.38 or newer. +* `bridge` - Provides a bridge from the VM directly to the LAN. This assumes + there is a bridge device on the host which has one or more of the hosts + physical NICs enslaved. The guest VM will have an associated _tun_ device + created and enslaved to the bridge. The IP range / network configuration is + whatever is used on the LAN. This provides the guest VM full incoming & + outgoing net access just like a physical machine. +* `vepa` - All VMs' packets are sent to the external bridge. Packets whose + destination is a VM on the same host as where the packet originates from are + sent back to the host by the VEPA capable bridge (today's bridges are + typically not VEPA capable). +* `macvtap` - Packets whose destination is on the same host as where they + originate from are directly delivered to the target macvtap device. Both + origin and destination devices need to be in bridge mode for direct delivery. + If either one of them is in vepa mode, a VEPA capable bridge is required. +* `passthrough` - This feature attaches a virtual function of a SRIOV capable + NIC directly to a VM without losing the migration capability. All packets are + sent to the VF/IF of the configured network device. Depending on the + capabilities of the device additional prerequisites or limitations may apply; + for example, on Linux this requires kernel 2.6.38 or newer. Example of a `macvtap` interface: -``` +```hcl resource "libvirt_domain" "my-domain" { name = "master" ... @@ -239,18 +231,23 @@ resource "libvirt_domain" "my-domain" { must be installed and running inside of the domain in order to discover the IP addresses of all the network interfaces attached to a LAN. -The optional `graphics` block allows you to override the default graphics settings. The -block supports: +### Graphics devices + +The optional `graphics` block allows you to override the default graphics +settings. + +The block supports: * `type` - the type of graphics emulation (default is "spice") * `autoport` - defaults to "yes" * `listen_type` - "listen type", defaults to "none" -On occasion we have found it necessary to set a `type` of "vnc" and a `listen_type` of "address" -with certain builds of QEMU. +On occasion we have found it necessary to set a `type` of `vnc` and a +`listen_type` of `address` with certain builds of QEMU. The `graphics` block will look as follows: -``` + +```hcl resource "libvirt_domain" "my_machine" { ... graphics { @@ -260,13 +257,17 @@ resource "libvirt_domain" "my_machine" { } ``` -Note the following: -* The `graphics` block is ignored for the architectures `s390x` and `ppc64`. +~> **Note well:** the `graphics` block is ignored for the architectures + `s390x` and `ppc64`. -The optional `console` block allows you to define a console for the domain. The block -looks as follows: -``` +### Console devices + +The optional `console` block allows you to define a console for the domain. + +The block looks as follows: + +```hcl resource "libvirt_domain" "my_machine" { ... console { @@ -278,18 +279,24 @@ resource "libvirt_domain" "my_machine" { } ``` -Note the following: -* You can repeat the `console` block to create more than one console, in the same way -that you can repeat `disk` blocks (see above) -* The `target_type` is optional for the first console -* All subsequent `console` blocks must specify a `target_type` of `virtio` -* The `source_path` is optional for all consoles +~> **Note well:** + <ul> + <li>You can repeat the `console` block to create more than one console, in the + same way that you can repeat `disk` blocks (see [above](#handling-disks)).</li> + <li>The `target_type` is optional for the first console and defaults to `serial`.</li> + <li>All subsequent `console` blocks must specify a `target_type` of `virtio`.</li> + <li>The `source_path` is optional for all consoles.</li> + </ul> See [libvirt Domain XML Console element](https://libvirt.org/formatdomain.html#elementsConsole) for more information. + +### CPU mode + The optional `cpu` block allows to configure CPU mode. Example: -``` + +```hcl resource "libvirt_domain" "my_machine" { ... cpu { @@ -306,6 +313,8 @@ resource "libvirt_domain" "my_machine" { } ``` +### Sharing filesystem between libvirt host and guest + The optional `filesystem` block allows to define one or more [filesytem](https://libvirt.org/formatdomain.html#elementsFilesystems) entries to be added to the domain. This allows to share a directory of the libvirtd host with the guest. @@ -322,7 +331,7 @@ Currently the following attributes are supported: Example: -``` +```hcl filesystem { source = "/tmp" target = "tmp" @@ -337,18 +346,19 @@ filesystem { The exported filesystems can be mounted inside of the guest in this way: -``` +```hcl sudo mount -t 9p -o trans=virtio,version=9p2000.L,rw tmp /host/tmp sudo mount -t 9p -o trans=virtio,version=9p2000.L,r proc /host/proc ``` This can be automated inside of `/etc/fstab`: -``` +```hcl tmp /host/tmp 9p trans=virtio,version=9p2000.L,rw 0 0 proc /host/proc 9p trans=virtio,version=9p2000.L,r 0 0 ``` ## Attributes Reference -* `id` - a unique identifier for the resource -* `network_interface.<N>.addresses.<M>` - M-th IP address assigned to the N-th network interface +* `id` - a unique identifier for the resource. +* `network_interface.<N>.addresses.<M>` - M-th IP address assigned to the N-th + network interface. diff --git a/docs/providers/libvirt/r/network.markdown b/website/docs/r/network.markdown index 8db2366c..1c2f2757 100644 --- a/docs/providers/libvirt/r/network.markdown +++ b/website/docs/r/network.markdown @@ -13,8 +13,8 @@ Manages a VM network resource within libvirt. For more information see ## Example Usage -``` -resource "libvirt_network" "network1" { +```hcl +resource "libvirt_network" "kube_network" { # the name used by libvirt name = "k8snet" @@ -46,10 +46,10 @@ resource "libvirt_network" "network1" { The following arguments are supported: * `name` - (Required) A unique name for the resource, required by libvirt. - Changing this forces a new resource to be created. + Changing this forces a new resource to be created. * `domain` - The domain used by the DNS server. * `addresses` - A list of (0 or 1) ipv4 and (0 or 1) ipv6 subnets in CIDR notation - format for being served by the DHCP server. Address of subnet should be used. + format for being served by the DHCP server. Address of subnet should be used. * `mode` - One of: - `none`: the guests can talk to each other and the host OS, but cannot reach any other machines on the LAN. @@ -59,9 +59,9 @@ The following arguments are supported: specific admin configuration. In the absence of host networking, it at least allows guests to talk directly to each other. - `route`: this is a variant on the default network which routes traffic from - the virtual network to the LAN _without applying any NAT_. It requires that the - IP address range be pre-configured in the routing tables of the router on - the host network. + the virtual network to the LAN **without applying any NAT**. It requires that + the IP address range be pre-configured in the routing tables of the router + on the host network. - `bridge`: use a pre-existing host bridge. The guests will effectively be directly connected to the physical network (i.e. their IP addresses will all be on the subnet of the physical network, and there will be no @@ -75,7 +75,7 @@ The following arguments are supported: both of `address` and `domain`. You can use either of the forms below to specify dns_forwarders: -``` +```hcl resource "libvirt_network" "my_network" { ... dns_forwarder { @@ -88,7 +88,7 @@ resource "libvirt_network" "my_network" { } ``` -``` +```hcl resource "libvirt_network" "my_network" { ... dns_forwarder = [ @@ -103,3 +103,6 @@ resource "libvirt_network" "my_network" { } ``` +## Attributes Reference + +* `id` - a unique identifier for the resource diff --git a/website/docs/r/volume.html.markdown b/website/docs/r/volume.html.markdown new file mode 100644 index 00000000..78ef62f8 --- /dev/null +++ b/website/docs/r/volume.html.markdown @@ -0,0 +1,67 @@ +--- +layout: "libvirt" +page_title: "Libvirt: libvirt_volume" +sidebar_current: "docs-libvirt-volume" +description: |- + Manages a storage volume in libvirt +--- + +# libvirt\_volume + +Manages a storage volume in libvirt. For more information see +[the official documentation](https://libvirt.org/formatstorage.html). + +## Example Usage + +```hcl +# Base OS image to use to create a cluster of different +# nodes +resource "libvirt_volume" "opensuse_leap" { + name = "opensuse_leap" + source = "http://download.opensuse.org/repositories/Cloud:/Images:/Leap_42.1/images/openSUSE-Leap-42.1-OpenStack.x86_64.qcow2" +} + +# volume to attach to the "master" domain as main disk +resource "libvirt_volume" "master" { + name = "master.qcow2" + base_volume_id = "${libvirt_volume.opensuse_leap.id}" +} + +# volumes to attach to the "workers" domains as main disk +resource "libvirt_volume" "worker" { + name = "worker_${count.index}.qcow2" + base_volume_id = "${libvirt_volume.opensuse_leap.id}" + count = "${var.workers_count}" +} +``` + +~> **Tip:** when provisioning multiple domains using the same base image, create +a `libvirt_volume` for the base image and then define the domain specific ones +as based on it. This way the image will not be modified and no extra disk space +is going to be used for the base image. + +## Argument Reference + +The following arguments are supported: + +* `name` - (Required) A unique name for the resource, required by libvirt. + Changing this forces a new resource to be created. +* `pool` - (Optional) The storage pool where the resource will be created. + If not given, the `default` storage pool will be used. +* `source` - (Optional) If specified, the image will be uploaded into libvirt + storage pool. It's possible to specify the path to a local (relative to the + machine running the `terraform` command) image or a remote one. Remote images + have to be specified using HTTP(S) urls for now. +* `size` - (Optional) The size of the volume in bytes (if you don't like this, + help fix [this issue](https://github.com/hashicorp/terraform/issues/3287). + If `source` is specified, `size` will be set to the source image file size. +* `base_volume_id` - (Optional) The backing volume (CoW) to use for this volume. +* `base_volume_name` - (Optional) The name of the backing volume (CoW) to use + for this volume. Note well: when `base_volume_pool` is not specified the + volume is going to be searched inside of `pool`. +* `base_volume_pool` - (Optional) The name of the storage pool containing the + volume defined by `base_volume_name`. + +## Attributes Reference + +* `id` - a unique identifier for the resource diff --git a/website/libvirt.erb b/website/libvirt.erb new file mode 100644 index 00000000..707a51e6 --- /dev/null +++ b/website/libvirt.erb @@ -0,0 +1,38 @@ +<% wrap_layout :inner do %> + <% content_for :sidebar do %> + <div class="docs-sidebar hidden-print affix-top" role="complementary"> + <ul class="nav docs-sidenav"> + <li<%= sidebar_current("docs-home") %>> + <a href="/docs/providers/index.html">All Providers</a> + </li> + + <li<%= sidebar_current("docs-libvirt-index") %>> + <a href="/docs/providers/libvirt/index.html">libvirt Provider</a> + </li> + + <li<%= sidebar_current("docs-libvirt-resource") %>> + <a href="#">Resources</a> + <ul class="nav nav-visible"> + <li<%= sidebar_current("docs-libvirt-resource-cloudinit") %>> + <a href="/docs/providers/libvirt/r/cloudinit.html">libvirt_cloudinit</a> + </li> + <li<%= sidebar_current("docs-libvirt-resource-coreos-ignition") %>> + <a href="/docs/providers/libvirt/r/coreos_ignition.html">libvirt_ignition</a> + </li> + <li<%= sidebar_current("docs-libvirt-resource-domain") %>> + <a href="/docs/providers/libvirt/r/domain.html">libvirt_domain</a> + </li> + <li<%= sidebar_current("docs-libvirt-resource-network") %>> + <a href="/docs/providers/libvirt/r/network.html">libvirt_network</a> + </li> + <li<%= sidebar_current("docs-libvirt-resource-volume") %>> + <a href="/docs/providers/libvirt/r/volume.html">libvirt_volume</a> + </li> + </ul> + </li> + </ul> + </div> + <% end %> + + <%= yield %> +<% end %> |