cloudinit는 terraform 및 libvirt 공급자가 만든 qemu/kvm 시스템에서 작동하지 않습니다.

cloudinit는 terraform 및 libvirt 공급자가 만든 qemu/kvm 시스템에서 작동하지 않습니다.

Terraform 및 libvirt 공급자와 함께 cloudinit를 사용하여 qemu/kvm 하이퍼바이저에서 가상 머신을 프로비저닝하려고 합니다. 머신을 부팅할 수 있지만 cloudinit가 시작되지 않습니다. 나는 terraform을 사용하지 않고 kvm을 사용하여 사용자 데이터 파일을 제공하기 위해 웹 서버를 실행하는 두 번째 터미널로 시스템을 시작하여 테스트했기 때문에 사용된 사용자 데이터가 제대로 작동한다는 것을 알고 있습니다. 모두 Ubuntu 18.04에서 실행되었습니다.

우분투와 센토스의 클라우드 이미지를 사용해 보았습니다. 둘 다 가상 머신을 생성하고 로그인 프롬프트로 부팅합니다. 그러나 어느 쪽도 실제로 사용자 데이터의 내용을 제공하지는 않습니다. 또한 낮은 버전의 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와 동일, 테스트 중인 두 배포판 간의 유일한 변경 사항은 호스트 이름입니다)

#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 웹 서버를 시작한 후입니다. 커널/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수정되지 않은 클라우드 이미지를 사용하여 부트 도메인의 콘솔을 모니터링하는 경우 (다음 중 하나 시도)우분투의 QCOW2 이미지) base_volume_id에 있는 것처럼 libvirt_volumecloud-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.우분투 자동 설치 프로그램, 아니요클라우드 초기화.

Cloud-init는 Ubuntu의 자동 설치 프로그램에서 사용되지만 cloud-init 자체는 autoinstallyaml 키를 사용하지 않습니다.

우분투와 센토스의 클라우드 이미지를 사용해 보았습니다.

알아채다cloud-init는 centos를 지원합니다., 하지만 Ubuntu의 자동 설치 프로그램은 그렇게 하지 않을 것 같습니다. 대신 cloud-init를 사용하려면 다음을 확인해 보세요.그리고지도 시간.

제안

.tf 파일에서 다음 줄을 자세히 살펴보세요.

data "template_file" "user_data" {
    template = file("${path.module}/cloud_init.cfg")
}

Subiquity는 그것으로부터 구성을 추출할 것으로 예상합니까 cloud_init.cfg? 나는 그것을 의심한다.

관련 정보