| 2019-02-15 18:55:48 |
Pedro Guimarães |
bug |
|
|
added bug |
| 2019-02-15 18:56:26 |
Pedro Guimarães |
summary |
KVM containers fail at creation with: Failed to get shared "write" lock Is another process using the image? |
KVM instances fail at creation with: Failed to get shared "write" lock Is another process using the image? |
|
| 2019-02-15 19:00:08 |
Pedro Guimarães |
description |
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos or even creating new images:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
|
| 2019-02-15 19:34:50 |
Pedro Guimarães |
description |
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
Juju version: 2.5.0
Qemu version: qemu-system-x86 2.11+dfsg-1ubuntu7.9
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
|
| 2019-02-25 18:07:54 |
Pedro Guimarães |
bug |
|
|
added subscriber Canonical Field High |
| 2019-02-25 18:08:01 |
Pedro Guimarães |
tags |
|
cpe-onsite |
|
| 2019-03-15 15:48:44 |
Bogdan Suchok |
bug |
|
|
added subscriber Canonical Field Critical |
| 2019-03-15 16:54:10 |
Corey Bryant |
bug task added |
|
qemu (Ubuntu) |
|
| 2019-03-15 20:29:01 |
Christian Ehrhardt |
description |
Juju version: 2.5.0
Qemu version: qemu-system-x86 2.11+dfsg-1ubuntu7.9
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
Juju version: 2.5.0
Qemu version: qemu-system-x86 2.11+dfsg-1ubuntu7.9
When creating multiple KVM instances using Juju, some fail with "exit status 13".
Looking at the unit-machine logs, I can see what seems to be a race-condition between qemu-img create and virsh start commands:
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:24 running: qemu-img [create -b /var/lib/juju/kvm/guests/bionic-amd64-backing-file.qcow -f qcow2 /var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow
8G]
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:25 running as uid: 64055, gid: 117
2019-02-15 16:31:27 DEBUG juju.container.kvm run_linux.go:36 output: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/guests/bionic-
amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:481 create root image: Formatting '/var/lib/juju/kvm/guests/juju-720d5c-1-kvm-3.qcow', fmt=qcow2 size=8589934592 backing_file=/var/lib/juju/kvm/
guests/bionic-amd64-backing-file.qcow cluster_size=65536 lazy_refcounts=off refcount_bits=16
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [define /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml]
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:21 output: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm wrappedcmds.go:204 created domain: Domain juju-720d5c-1-kvm-3 defined from /var/lib/juju/containers/juju-720d5c-1-kvm-3/juju-720d5c-1-kvm-3.xml
2019-02-15 16:31:27 DEBUG juju.container.kvm run.go:19 virsh [start juju-720d5c-1-kvm-3]
2019-02-15 16:31:29 DEBUG juju.container.kvm run.go:21 output: error: Failed to start domain juju-720d5c-1-kvm-3
error: internal error: qemu unexpectedly closed the monitor: 2019-02-15T16:31:28.826568Z qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.80000001H:ECX.svm [bit 2]
2019-02-15T16:31:28.839983Z qemu-system-x86_64: -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1: Failed to get shared "write" lock
Is another process using the image?
2019-02-15 16:31:29 ERROR juju.provisioner.kvm kvm-broker.go:152 failed to start container: kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1
2019-02-15 16:31:29 WARNING juju.provisioner provisioner_task.go:1282 failed to start machine 1/kvm/3 (kvm container creation failed: failed to start domain "juju-720d5c-1-kvm-3": exit status 1), retrying
in 10s (10 more attempts)
It never works (on all 10x trials).
There is a lot of reports on qemu-img's request for write lock although reading infos:
https://bugs.launchpad.net/qemu/+bug/1721788
https://bugs.launchpad.net/nova/+bug/1718295
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1718133
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028
One solution seems to be passing --force-share to qemu-img command. That may be risky in a scenario where Juju AND other things are using qemu at the same time, as discussed on: https://bugs.launchpad.net/qemu/+bug/1721788/comments/1
Can we create a new image file for every VM to deploy? Or --force-share is an alternative?
Either way, there seems to be no work-around besides changing Juju at the moment. |
|
| 2019-03-15 20:41:29 |
Christian Ehrhardt |
bug task added |
|
libvirt (Ubuntu) |
|
| 2019-03-15 20:41:34 |
Christian Ehrhardt |
libvirt (Ubuntu): status |
New |
Fix Released |
|
| 2019-03-15 20:41:37 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Fix Released |
|
| 2019-03-17 20:40:33 |
Tim Penhey |
juju: status |
New |
Triaged |
|
| 2019-03-17 20:40:36 |
Tim Penhey |
juju: importance |
Undecided |
High |
|
| 2019-03-17 20:40:52 |
Tim Penhey |
juju: assignee |
|
Richard Harding (rharding) |
|
| 2019-03-18 10:28:59 |
Joseph Phillips |
juju: status |
Triaged |
In Progress |
|
| 2019-03-18 10:29:12 |
Joseph Phillips |
juju: assignee |
Richard Harding (rharding) |
Joseph Phillips (manadart) |
|
| 2019-03-18 15:51:34 |
Joseph Phillips |
juju: milestone |
|
2.5.3 |
|
| 2019-03-18 15:51:39 |
Joseph Phillips |
juju: status |
In Progress |
Fix Committed |
|
| 2019-03-18 16:33:29 |
Arno van Huyssteen |
bug |
|
|
added subscriber Arno van Huyssteen |
| 2019-03-18 19:04:00 |
Joseph Phillips |
juju: status |
Fix Committed |
In Progress |
|
| 2019-03-19 04:52:39 |
Joseph Phillips |
juju: status |
In Progress |
Fix Committed |
|
| 2019-03-26 02:09:44 |
Canonical Juju QA Bot |
juju: status |
Fix Committed |
Fix Released |
|
