Hello,
When I try to clone a VM template, it takes more than 3minutes for a VM, it's a bit long but it works without throwing any error message.
If I add another VM, via Terraform Telmate provider, same instance with
Now I want 2 or 4 instances at the same time, still with Terraform,
I looked at the logs, and I found in dmesg that qemu is stuck:
However, it seems the drive is not the bottleneck here :
There is the lsblk output (for when there was only 2 instances creating sorry):
But if you look at the process, they seems to be in deadlock, so waiting for drive.
The configuration is :
* HP DL 380 Gen9
* 96 GB DDR4 ECC
* 2x Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
* 1x SSD Samsung EVO 850 - via HPe embedded software raid
There is only 1 drive for now, installed with ext4 / lvm from the wizard.
I know it's not overkill regarding storage, but I feel the drive itself is not the bottleneck here.
There is the terraform instance configuration :
For now, I'll try to increase timeout, but Telmate Terrform provider is buggy and it doesn't works everytime.
Do you have an idea of what can cause this ?
When I try to clone a VM template, it takes more than 3minutes for a VM, it's a bit long but it works without throwing any error message.
If I add another VM, via Terraform Telmate provider, same instance with
count = 2, it takes long too but no error message either.Now I want 2 or 4 instances at the same time, still with Terraform,
count = 4, and it doesn't works :
Code:
proxmox_vm_qemu.old_k3s_worker_instance[3]: Still creating... [5m50s elapsed]
╷
│ Error: vm locked, could not obtain config
│
│ with proxmox_vm_qemu.old_k3s_worker_instance[3],
│ on instance.tf line 1, in resource "proxmox_vm_qemu" "old_k3s_worker_instance":
│ 1: resource "proxmox_vm_qemu" "old_k3s_worker_instance" {
│
╵
╷
│ Error: vm locked, could not obtain config
│
│ with proxmox_vm_qemu.old_k3s_worker_instance[0],
│ on instance.tf line 1, in resource "proxmox_vm_qemu" "old_k3s_worker_instance":
│ 1: resource "proxmox_vm_qemu" "old_k3s_worker_instance" {
│
╵
╷
│ Error: vm locked, could not obtain config
│
│ with proxmox_vm_qemu.old_k3s_worker_instance[2],
│ on instance.tf line 1, in resource "proxmox_vm_qemu" "old_k3s_worker_instance":
│ 1: resource "proxmox_vm_qemu" "old_k3s_worker_instance" {
│
╵
╷
│ Error: vm locked, could not obtain config
│
│ with proxmox_vm_qemu.old_k3s_worker_instance[1],
│ on instance.tf line 1, in resource "proxmox_vm_qemu" "old_k3s_worker_instance":
│ 1: resource "proxmox_vm_qemu" "old_k3s_worker_instance" {
│
╵
I looked at the logs, and I found in dmesg that qemu is stuck:
Code:
[ +0.000005] INFO: task qemu-img:20060 blocked for more than 120 seconds.
[ +0.000054] Tainted: P O 5.15.39-1-pve #1
[ +0.000046] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ +0.000059] task:qemu-img state:D stack: 0 pid:20060 ppid: 19869 flags:0x00004002
[ +0.000006] Call Trace:
[ +0.000002] <TASK>
[ +0.000002] __schedule+0x33d/0x1750
[ +0.000006] ? __pagevec_release+0x30/0x70
[ +0.000007] ? __cond_resched+0x1a/0x50
[ +0.000004] ? write_cache_pages+0x24d/0x460
[ +0.000005] ? __set_page_dirty_no_writeback+0x40/0x40
[ +0.000006] schedule+0x4e/0xb0
[ +0.000003] io_schedule+0x46/0x70
[ +0.000005] wait_on_page_bit_common+0x114/0x3e0
[ +0.000007] ? filemap_invalidate_unlock_two+0x40/0x40
[ +0.000007] wait_on_page_bit+0x3f/0x50
[ +0.000006] wait_on_page_writeback+0x26/0x80
[ +0.000006] __filemap_fdatawait_range+0x97/0x110
[ +0.000008] filemap_write_and_wait_range+0x88/0xd0
[ +0.000008] blkdev_put+0x1d0/0x210
[ +0.000006] blkdev_close+0x27/0x30
[ +0.000006] __fput+0x9f/0x260
[ +0.000007] ____fput+0xe/0x10
[ +0.000006] task_work_run+0x6d/0xa0
[ +0.000006] exit_to_user_mode_prepare+0x1a4/0x1b0
[ +0.000005] syscall_exit_to_user_mode+0x27/0x50
[ +0.000005] ? __x64_sys_close+0x12/0x40
[ +0.000004] do_syscall_64+0x69/0xc0
[ +0.000003] ? syscall_exit_to_user_mode+0x27/0x50
[ +0.000005] ? do_syscall_64+0x69/0xc0
[ +0.000004] ? asm_exc_page_fault+0x8/0x30
[ +0.000006] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ +0.000006] RIP: 0033:0x7f8049b9e11b
[ +0.000003] RSP: 002b:00007fff1f91c5c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
[ +0.000004] RAX: 0000000000000000 RBX: 000055fff7551090 RCX: 00007f8049b9e11b
[ +0.000002] RDX: 00007f803fc81ca8 RSI: 0000000000000000 RDI: 0000000000000008
[ +0.000003] RBP: 000055fff754ad30 R08: 0000000000000000 R09: 000055fff7542130
[ +0.000002] R10: 0000000000000008 R11: 0000000000000293 R12: 000055fff74fd3b0
[ +0.000002] R13: 0000000000000000 R14: 000055fff5a8ef00 R15: 0000000000000000
[ +0.000004] </TASK>
However, it seems the drive is not the bottleneck here :
Code:
root@pve1:~# iostat --human
Linux 5.15.39-1-pve (pve1) 08/10/2022 _x86_64_ (48 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.1% 0.0% 0.1% 0.5% 0.0% 99.4%
Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd
dm-0 0.02 0.5k 0.0k 0.0k 4.2M 0.0k 0.0k
dm-1 3.94 29.8k 17.8k 0.0k 229.6M 136.9M 0.0k
dm-10 0.00 0.0k 0.0k 0.0k 116.0k 0.0k 0.0k
dm-11 0.00 0.0k 0.0k 0.0k 116.0k 0.0k 0.0k
dm-12 0.00 0.0k 0.0k 0.0k 116.0k 0.0k 0.0k
dm-13 46.70 0.3k 186.7k 0.0k 2.2M 1.4G 0.0k
dm-14 46.70 0.3k 186.7k 0.0k 2.2M 1.4G 0.0k
dm-15 0.02 0.4k 0.0k 0.0k 3.3M 0.0k 0.0k
dm-16 46.70 0.3k 186.7k 0.0k 2.2M 1.4G 0.0k
dm-17 46.70 0.3k 186.7k 0.0k 2.2M 1.4G 0.0k
dm-2 1.09 1.5k 2.8k 0.0k 11.7M 21.8M 0.0k
dm-3 212.24 644.4k 2.2M 0.0k 4.8G 17.2G 0.0k
dm-4 212.24 644.4k 2.2M 0.0k 4.8G 17.2G 0.0k
dm-6 0.02 0.5k 0.0k 0.0k 3.9M 0.0k 0.0k
dm-7 0.01 0.2k 0.0k 0.0k 1.2M 0.0k 0.0k
dm-8 14.15 877.4k 0.0k 0.0k 6.6G 0.0k 0.0k
dm-9 0.00 0.0k 0.0k 0.0k 116.0k 0.0k 0.0k
sda 0.02 0.6k 0.0k 0.0k 4.4M 0.0k 0.0k
sdb 167.42 742.8k 2.3M 0.0k 5.6G 17.4G 0.0k
There is the lsblk output (for when there was only 2 instances creating sorry):
Code:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 298.1G 0 disk
sdb 8:16 0 465.8G 0 disk
├─sdb1 8:17 0 1007K 0 part
├─sdb2 8:18 0 512M 0 part /boot/efi
└─sdb3 8:19 0 465.3G 0 part
├─pve-swap 253:0 0 8G 0 lvm [SWAP]
├─pve-root 253:1 0 96G 0 lvm /
├─pve-data_tmeta 253:2 0 3.5G 0 lvm
│ └─pve-data-tpool 253:4 0 338.4G 0 lvm
│ ├─pve-data 253:5 0 338.4G 1 lvm
│ ├─pve-vm--100--disk--0 253:6 0 32G 0 lvm
│ ├─pve-vm--9000--cloudinit 253:7 0 4M 0 lvm
│ ├─pve-base--9000--disk--0 253:8 0 2.2G 1 lvm
│ ├─pve-vm--102--cloudinit 253:9 0 4M 0 lvm
│ ├─pve-vm--101--cloudinit 253:10 0 4M 0 lvm
│ ├─pve-vm--102--disk--0 253:11 0 2.2G 0 lvm
│ └─pve-vm--101--disk--0 253:12 0 2.2G 0 lvm
└─pve-data_tdata 253:3 0 338.4G 0 lvm
└─pve-data-tpool 253:4 0 338.4G 0 lvm
├─pve-data 253:5 0 338.4G 1 lvm
├─pve-vm--100--disk--0 253:6 0 32G 0 lvm
├─pve-vm--9000--cloudinit 253:7 0 4M 0 lvm
├─pve-base--9000--disk--0 253:8 0 2.2G 1 lvm
├─pve-vm--102--cloudinit 253:9 0 4M 0 lvm
├─pve-vm--101--cloudinit 253:10 0 4M 0 lvm
├─pve-vm--102--disk--0 253:11 0 2.2G 0 lvm
└─pve-vm--101--disk--0 253:12 0 2.2G 0 lvm
But if you look at the process, they seems to be in deadlock, so waiting for drive.
Code:
root 1855 0.0 0.1 345608 124424 ? Ss 13:02 0:00 pvedaemon
root 1856 0.0 0.1 353796 129376 ? S 13:02 0:02 \_ pvedaemon worker
root 19866 0.0 0.1 361028 127048 ? Ss 15:07 0:00 | \_ task UPID:pve1:00004D9A:000B8497:62F3ADAB:qmclone:9000:terraform-prov@pve!token_terraform_pve_deploy:
root 20018 1.3 0.0 832156 25080 ? Dl 15:08 0:06 | \_ /usr/bin/qemu-img convert -p -n -f raw -O raw /dev/pve/base-9000-disk-0 zeroinit:/dev/pve/vm-102-disk-0
root 1857 0.0 0.1 354000 132160 ? S 13:02 0:01 \_ pvedaemon worker
root 19865 0.0 0.1 361232 127104 ? Ss 15:07 0:00 | \_ task UPID:pve1:00004D99:000B8496:62F3ADAB:qmclone:9000:terraform-prov@pve!token_terraform_pve_deploy:
root 19972 1.5 0.0 832164 25404 ? Dl 15:07 0:07 | | \_ /usr/bin/qemu-img convert -p -n -f raw -O raw /dev/pve/base-9000-disk-0 zeroinit:/dev/pve/vm-101-disk-0
root 19870 0.0 0.1 361232 127104 ? Ss 15:07 0:00 | \_ task UPID:pve1:00004D9E:000B849C:62F3ADAB:qmclone:9000:terraform-prov@pve!token_terraform_pve_deploy:
root 20044 1.0 0.0 832156 25224 ? Dl 15:08 0:04 | \_ /usr/bin/qemu-img convert -p -n -f raw -O raw /dev/pve/base-9000-disk-0 zeroinit:/dev/pve/vm-104-disk-1
root 1858 0.0 0.1 354132 130180 ? S 13:02 0:02 \_ pvedaemon worker
root 19869 0.0 0.1 361364 127236 ? Ss 15:07 0:00 \_ task UPID:pve1:00004D9D:000B849B:62F3ADAB:qmclone:9000:terraform-prov@pve!token_terraform_pve_deploy:
root 20060 0.9 0.0 832156 25108 ? Dl 15:08 0:04 \_ /usr/bin/qemu-img convert -p -n -f raw -O raw /dev/pve/base-9000-disk-0 zeroinit:/dev/pve/vm-103-disk-0
The configuration is :
* HP DL 380 Gen9
* 96 GB DDR4 ECC
* 2x Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz
* 1x SSD Samsung EVO 850 - via HPe embedded software raid
There is only 1 drive for now, installed with ext4 / lvm from the wizard.
I know it's not overkill regarding storage, but I feel the drive itself is not the bottleneck here.
There is the terraform instance configuration :
YAML:
resource "proxmox_vm_qemu" "old_k3s_worker_instance" {
count = 4
name = "old-k3s-worker-instance-${count.index + 1}"
target_node = "pve1"
clone = var.pve_template_name
# VM settings
agent = 0 #guest agent
os_type = "cloud-init"
cores = 4
sockets = "1"
cpu = "host"
memory = 8 * 1024
scsihw = "virtio-scsi-pci"
bootdisk = "scsi0"
sshkeys = <<EOF
ssh-rsa AAAAB3N...PxdQ== ubuntu
EOF
ssh_user = "ubuntu"
disk {
slot = 0
size = "15G"
type = "scsi"
storage = "local-lvm"
iothread = 1
}
network {
model = "virtio"
bridge = "vmbr11"
}
# lifecycle {
# ignore_changes = [
# network
# ]
# }
ipconfig0 = "ip=10.0.11.${count.index + 11}/24,gw=10.0.11.1"
}
For now, I'll try to increase timeout, but Telmate Terrform provider is buggy and it doesn't works everytime.
Do you have an idea of what can cause this ?