1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
---
layout: "libvirt"
page_title: "Libvirt: libvirt_domain"
sidebar_current: "docs-libvirt-domain"
description: |-
Manages a virtual machine (domain) in libvirt
---
# libvirt\_domain
Manages a VM domain resource within libvirt. For more information see
[the official documentation](https://libvirt.org/formatdomain.html).
## Example Usage
```
resource "libvirt_domain" "default" {
name = "test"
}
```
## 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.
* `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.
* `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.
The `disk` block supports:
* `volume_id` - (Required) The volume id to use for this 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.
```
resource "libvirt_volume" "leap" {
name = "leap"
source = "http://someurl/openSUSE_Leap-42.1.qcow2"
}
resource "libvirt_volume" "mydisk" {
name = "mydisk"
base_volume_id = "${libvirt_volume.leap.id}"
}
resource "libvirt_domain" "domain1" {
name = "domain1"
disk {
volume_id = "${libvirt_volume.mydisk.id}"
}
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
}
}
```
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.
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.
* `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.
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.
Example of a `macvtap` interface:
```
resource "libvirt_domain" "my-domain" {
name = "master"
...
network_interface {
macvtap = "eth0"
}
}
```
**Warning:** the [Qemu guest agent](http://wiki.libvirt.org/page/Qemu_guest_agent)
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.
|