Red Hat Bugzilla – Bug 1278083
Ironic introspection of qemu vm - no disk found
Last modified: 2016-07-25 10:26:42 EDT
Description of problem:
Every element on the server is detected expect the disk.
Version-Release number of selected component (if applicable):
We believe always
Steps to Reproduce:
1. Install undercloud in 7.1
2. Create an instance in qemu with virtio to introspect
3. Introspect the server
Will return a local_gb of 1, while should be more.
Having the actual size of the current disk
On the server we could observe for the log: "value for local_gb is missing or malformed"
Apparently the command (lsblk -bSo) is done here:
The following command did not return anything (as not iSCSI):
lsblk -bSo NAME,TYPE,SIZE
According to man lsblk
So we tried this one, which worked:
lsblk -bo NAME,SIZE,TYPE
NAME SIZE TYPE
vda 4444444 disk
A bug that appeared to be similar in term of error message:
Applying virsh edit to swith to SATA instead of virtio, which results in the following differences:
> diff -u vers*
--- vers1 2015-11-04 17:21:11.401642846 +0100
+++ vers2 2015-11-04 17:21:22.651994390 +0100
@@ -1,6 +1,6 @@
<disk type='block' device='disk'>
- <driver name='qemu' type='raw' cache='none' io='native'/>
+ <driver name='qemu' type='raw'/>
- <target dev='vda' bus='virtio'/>
- <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
+ <target dev='hda' bus='sata'/>
+ <address type='drive' controller='0' bus='0' target='0' unit='0'/>
Chris, this bug is not present in rhos-director-8.0, so it's useless to target it to it. If you want it to be fixed in 7.2, please mark it as such.
And yes, the easiest work around is to use SATA disk type for VM's. You can switch it back to VirtIO after introspection, if you feel like.
I'd like to have this bug fix in 7.2
Could you explain me how to "mark it as such" ?
Thanks in advance.
Convince PM's to treat it as a last-minute blocker for 7.2, which is, to be honest, extremely unlikely, provided that it has an easy work-around.
Maybe easy to apply but not really easy to explain to customers when you are on-site and they expect VirtIO disk performances, but I understand your point.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Only OSPd7 was affected by this bug, as I mentioned above.