`constellation mini up` times out
Opened this issue · 0 comments
3u13r commented
Issue description
constellation mini up
times out during creation.
To reproduce
Steps to reproduce the behavior:
- Download the CLI
- Execute
constellation mini up --debug
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:121 Checked arch and os
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:126 Checked that /dev/kvm exists
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:134 Checked CPU cores - there are 8
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:152 Scanned for available memory
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:160 Checked available memory, you have 31GB available
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:170 Checked for free space available, you have 25GB available
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:177 Preparing configuration
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:202 Configuration path is ""
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:224 Prepared configuration
2023-04-06T11:36:01Z DEBUG cmd/miniup.go:231 Creating mini cluster
An error occurred: exit status 1
Error: couldn't retrieve IP address of domain id: 29962dc6-14e7-4524-89d9-320f90ce2c3b. Please check following:
1) is the domain running proplerly?
2) has the network interface an IP address?
3) Networking issues on your libvirt setup?
4) is DHCP enabled on this Domain's network?
5) if you use bridge network, the domain should have the pkg qemu-agent installed
IMPORTANT: This error is not a terraform libvirt-provider error, but an error caused by your KVM/libvirt infrastructure configuration/setup
timeout while waiting for state to become 'all-addresses-obtained' (last state: 'waiting-addresses', timeout: 5m0s)
with module.worker.libvirt_domain.instance_group[0],
on modules/instance_group/main.tf line 15, in resource "libvirt_domain" "instance_group":
15: resource "libvirt_domain" "instance_group" {
Attempting to roll back.
Rollback succeeded.
Error: creating cluster: exit status 1
Error: couldn't retrieve IP address of domain id: 29962dc6-14e7-4524-89d9-320f90ce2c3b. Please check following:
1) is the domain running proplerly?
2) has the network interface an IP address?
3) Networking issues on your libvirt setup?
4) is DHCP enabled on this Domain's network?
5) if you use bridge network, the domain should have the pkg qemu-agent installed
IMPORTANT: This error is not a terraform libvirt-provider error, but an error caused by your KVM/libvirt infrastructure configuration/setup
timeout while waiting for state to become 'all-addresses-obtained' (last state: 'waiting-addresses', timeout: 5m0s)
with module.worker.libvirt_domain.instance_group[0],
on modules/instance_group/main.tf line 15, in resource "libvirt_domain" "instance_group":
15: resource "libvirt_domain" "instance_group" {
Environment
constellation version
:2.7.0-pre.0.20230405160928-1c03b066a61b
constellation-conf.yaml
version: v2 # Schema version of this configuration file.
image: v2.6.0 # Machine image version used to create Constellation nodes.
name: mini # Name of the cluster.
stateDiskSizeGB: 8 # Size (in GB) of a node's disk to store the non-volatile state.
kubernetesVersion: v1.25.8 # Kubernetes version to be installed into the cluster.
microserviceVersion: v2.7.0-pre.0.20230405160928-1c03b066a61b # Microservice version to be installed into the cluster. Defaults to the version of the CLI.
debugCluster: false # DON'T USE IN PRODUCTION: enable debug mode and use debug images. For usage, see: https://github.com/edgelesssys/constellation/blob/main/debugd/README.md
# Supported cloud providers and their specific configurations.
provider:
# Configuration for QEMU as provider.
qemu:
imageFormat: raw # Format of the image to use for the VMs. Should be either qcow2 or raw.
vcpus: 2 # vCPU count for the VMs.
memory: 2048 # Amount of memory per instance (MiB).
metadataAPIServer: ghcr.io/edgelesssys/constellation/qemu-metadata-api:v2.7.0-pre.0.20230330151913-6a2c9792e0ce@sha256:8283f9606366beaf05142aeef09a905085bc7cde071f43b43290a7f087994264 # Container image to use for the QEMU metadata server.
libvirtSocket: "" # Libvirt connection URI. Leave empty to start a libvirt instance in Docker.
libvirtContainerImage: ghcr.io/edgelesssys/constellation/libvirt:v2.7.0-pre.0.20230330151913-6a2c9792e0ce@sha256:56d218cc501d471d25f6a6da940db48a008a040bc26dea1fe8a61edf9ca7ce73 # Container image to use for launching a containerized libvirt daemon. Only relevant if `libvirtSocket = ""`.
nvram: production # NVRAM template to be used for secure boot. Can be sentinel value "production", "testing" or a path to a custom NVRAM template
firmware: "" # Path to the OVMF firmware. Leave empty for auto selection.
# Measurement used to enable measured boot.
measurements:
4:
expected: dfd62a251a234d2eccdbb4659e4990c330f3e4a4456f7274c769ad43c174c7c4
warnOnly: false
8:
expected: "0000000000000000000000000000000000000000000000000000000000000000"
warnOnly: false
9:
expected: a13d79910d9d98480c0d5c3f197d383d5d26895e350225e219bf286a7402e780
warnOnly: false
11:
expected: "0000000000000000000000000000000000000000000000000000000000000000"
warnOnly: false
12:
expected: c2b1e24a8ff734ea9546622da8ba438c6799be6b6cb4e6593d9411e9ea084c0c
warnOnly: false
13:
expected: "0000000000000000000000000000000000000000000000000000000000000000"
warnOnly: false
15:
expected: "0000000000000000000000000000000000000000000000000000000000000000"
warnOnly: false
- VM type used to run Constellation.
Miniconstellation was started on an Azure VM of typeStandard_D8as_v5
.
Expected behavior
The miniconstellation should be correctly created and initialized.
Additional info
We currently think that it has to do with using an AMD VM as the host. But note, that we could only reproduce this in a cloud environment. Using local AMD machines worked fine.
Mitigation
Switch the Azure VM's type to Standard_D8s_v5
.