Terraformおよびlibvirtプロバイダと一緒にcloudinitを使用して、qemu / kvmハイパーバイザーで仮想マシンをプロビジョニングしようとしています。マシンを起動できますが、cloudinitは起動しません。私は、terraformを使用せずにkvmを使用してユーザーデータファイルを提供するためにWebサーバーを実行している2番目の端末でシステムを起動してテストしたため、使用されたユーザーデータが正しく機能することを知っています。すべてUbuntu 18.04で実行されました。
UbuntuとCentusのクラウドイメージを試してみました。両方とも仮想マシンを作成し、ログインプロンプトで起動します。しかし、どちらも実際にユーザーデータの内容を提供しません。また、低バージョンのlibvirtプロバイダ(まだ利用可能)を試してみましたが、同じ結果が出ました。
他の人も同様の問題があるかどうかを確認するために広範な検索を行いました。私が見つけたほとんどのサイト/問題はStackExchangeサイトとgithubの問題とバグレポートから来ましたが、残念ながらドキュメントには含まれていませんでした。これはすべてユーザーデータから欠落している可能性があります。それらのどれも私が使用しているlibvirtプロバイダのバージョンを使用していませんが、ほとんど常にバージョン0.6.2を使用しています。 main.tfファイルでこのバージョンのプロバイダを試しましたが、initコマンドはバージョンが存在しないためダウンロードできないというエラーを返しました。
main.tf(centosとubuntuの唯一の違いはクラウドイメージファイル/場所とプレフィックス変数です)
terraform {
required_providers {
libvirt = {
source = "dmacvicar/libvirt"
version = "0.7.0"
}
}
}
# instantiate the provider
provider "libvirt" {
uri = "qemu:///system"
}
variable "prefix" {
default = "terraform_centos"
}
data "template_file" "user_data" {
template = file("${path.module}/cloud_init.cfg")
}
resource "libvirt_cloudinit_disk" "commoninit" {
name = "commoninit.iso"
user_data = data.template_file.user_data.rendered
}
resource "libvirt_volume" "qcow_volume" {
name = "${var.prefix}.img"
source = "https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2"
format = "qcow2"
}
resource "libvirt_domain" "centos" {
name = var.prefix
vcpu = 2
memory = 4096
disk {
volume_id = libvirt_volume.qcow_volume.id
}
cloudinit = libvirt_cloudinit_disk.commoninit.id
console {
type = "pty"
target_port = "0"
target_type = "serial"
}
console {
type = "pty"
target_type = "virtio"
target_port = "1"
}
network_interface {
network_name = "default"
}
}
ユーザーデータファイル(main.tfと同じ、テスト中の2つのディストリビューション間の唯一の変更はホスト名です)
#cloud-config
autoinstall:
version: 1
identity:
hostname: terraform_centos
username: vagrant
password: $6$dnWt7N17fTD$8.m3Rgf400iSyxLa/kUtunGUgE3N4foSg/y31HNnsGBUTpoMOmS3O9U/nJFvZjXpQTrLFrAcK5vok5EI0KZA90
locale: en_US
keyboard:
layout: us
ssh:
install-server: true
authorized-keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== vagrant insecure public key
allow-pw: true
storage:
layout:
name: direct
packages:
- gcc
- build-essential
late-commands:
- "echo 'vagrant ALL=(ALL) NOPASSWD: ALL' >> /target/etc/sudoers.d/vagrant"
- "chmod 440 /target/etc/sudoers.d/vagrant"
最後に、cloudinitを実際に動作させるkvmコマンドがあります。これは、他のシェルで高速Python Webサーバーを起動した後です。カーネル/initrdにアクセスできるように、isoイメージを/mntにマウントします。
kvm -no-reboot -m 4096 -drive file=focal.img,format=raw,cache=none,if=virtio -cdrom ~/isoImages/ubuntu-20.04.5-live-server-amd64.iso -kernel /mnt/casper/vmlinuz -initrd /mnt/casper/initrd -append 'autoinstall ds=nocloud-net;s=http://_gateway:3003/' -vnc :1
Qemu/kvm バージョン情報
$ virsh version
Compiled against library: libvirt 4.0.0
Using library: libvirt 4.0.0
Using API: QEMU 4.0.0
Running hypervisor: QEMU 2.11.1
地形バージョン情報
$ terraform version
Terraform v1.3.6
on linux_amd64
+ provider registry.terraform.io/dmacvicar/libvirt v0.7.0
+ provider registry.terraform.io/hashicorp/template v2.2.0
どちらのディストリビューションでもクラウドイメージを使用しているため、ログインして仮想マシンのログを直接確認できるデフォルトのユーザー名/パスワードはありません。 virt-managerおよびvirshコンソールコマンドを使用してコンソールにアクセスできます。どちらもログインプロンプトにあり、迷子になったユーザーはログインエラーメッセージを返します。
追加情報が必要な場合はお知らせください。私はこれを行うために何をすべきかについての提案を歓迎します。
答え1
Brett-holmanが述べたように、問題は配信するcloud-init YAMLである可能性が高いです。virsh console --domain your-kvm-domain
未変更のクラウドイメージを使用してブートドメインのコンソールを監視する場合(次のいずれかを試してください)UbuntuのQCOW2イメージ)base_volume_id
のように、libvirt_volume
cloud-initのinitプロセスの出力を見ることができます。
このリポジトリでTerraformを試してください。https://github.com/mattsn0w/terraform_kvm
私はそれを私の家の研究室の基盤として使用し、職場で空気が遮断された環境のために使用します。現在、Terraformプロバイダのv0.7.1を
使用してAL2、CentOS 7、RHEL 8および9、Ubuntu 18、20、および22 LTSを正常に設定しています。dmacvicar/libvirt
クラウドイメージにcloud-initがインストールされている場合は、これをかなり構成できます。
イメージのcloud-initバージョンをドキュメントと一致させる必要があることを指摘する価値があります。このレビューの最新バージョンはv23.3.3
答え2
言う
実際にSubiquityを構成していることに注意してくださいyaml
。Ubuntu自動インストーラ、いいえクラウド初期化。
Cloud-initはUbuntuのサイレントインストーラで使用されますが、cloud-init自体はautoinstall
yamlキーを使用しません。
UbuntuとCentusのクラウドイメージを試してみました。
気づくcloud-initはcentosをサポートしています。しかし、Ubuntuの自動インストーラはそうしないようです。代わりにcloud-initを使用するには、次の点を確認してください。はいそして地図時間。
提案
.tfファイルで次の行を詳しく見てください。
data "template_file" "user_data" {
template = file("${path.module}/cloud_init.cfg")
}
Subiquityはそれから構成を抽出すると予想していますかcloud_init.cfg
?私はそれを疑う。