On Mon, Jan 14, 2019 at 15:40:32 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 14, 2019 at 04:15:01PM +0100, Jiri Denemark wrote:
On Mon, Jan 14, 2019 at 15:03:26 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 14, 2019 at 03:36:38PM +0100, Jiri Denemark wrote:
On Mon, Jan 14, 2019 at 14:21:42 +0000, Daniel P. Berrangé wrote:
On Mon, Jan 14, 2019 at 02:56:43PM +0100, Jiri Denemark wrote:
On Mon, Jan 14, 2019 at 20:07:34 +0800, zhenwei pi wrote: > Let libvirtd handle invalid x86 cpu map error, and report the real reason. > > This issue can be reproduced : > 1, rm -rf /share/libvirt/cpu_map > 2, start libvirtd > 3, virsh create INSTANCE.xml > > Libvirtd reports error : > error: invalid argument: Failed to parse group 'tss' > > In face, libvirtd gets invalid cpu map. > With this patch, libvirtd reports error : > error: unsupported configuration: invalid x86 cpu map > > Signed-off-by: zhenwei pi <pizhenwei@bytedance.com> > --- > src/cpu/cpu_x86.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c > index d3a88da21d..91419d91d4 100644 > --- a/src/cpu/cpu_x86.c > +++ b/src/cpu/cpu_x86.c > @@ -2902,8 +2902,11 @@ virCPUx86ValidateFeatures(virCPUDefPtr cpu) > virCPUx86MapPtr map; > size_t i; > > - if (!(map = virCPUx86GetMap())) > + if (!(map = virCPUx86GetMap())) { > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > + _("invalid x86 cpu map")); > return -1; > + }
This is definitely not the right place to fix the issue. virCPUx86GetMap is called from a lot of places and your patch would only fix one of them. Moreover the message itself is not very helpful as it doesn't say why the CPU map is invalid. The right solution would be to show the error reported from virCPUx86LoadMap. However, it is called inside virCPUx86DriverOnceInit, which is only called once per libvirtd life time. I think you'd need to store that error and reuse it everytime cpuMap is NULL inside virCPUx86GetMap.
VIR_ONCE_GLOBAL_INIT already keeps a record of errors raised in the initializer & re-raises them
Eh, good to know :-) Anyway, it seems it doesn't really work and mostly some random unrelated error is reported. In my case I see
virsh # cpu-models x86_64 error: failed to get CPU model names error: Storage volume not found: no storage vol with matching path '/vm/systemrescuecd-x86-2.5.1.iso'
So there's definitely a bug to be fixed somewhere.
Hmm, what steps did you use to get into that situation ? It works as expected for me, re-reporting the original error.
I just moved away the CPU map file. But it appears I have a domain defined pointing to a non-existent disk image. It seems the problem shows up when multiple errors are raised when libvirtd is starting up.
Can you elaborate on that - what guest & storage pool config do you have. I'm struggling to see how to exercise the codepath that reports that error during startup.
While I had a domain pointing to an inexistent disk image, it did not actually cause the strange error reported by virCPUx86GetMap. This is what caused the error to be reported: I have a directory storage pool in /vm, which is autostarted on libvirtd startup. That directory contained sysres1.qcow file with systemrescuecd-x86-2.5.1.iso backing file. But the backing file was missing. The storage driver refreshes all active pools and once it gets to sysres1.qcow, virStorageBackendVolOpen fails with "Storage volume not found: no storage vol with matching path '/vm/systemrescuecd-x86-2.5.1.iso'". Jirka