Re: [libvirt] [PATCH] report invalid x86 cpu map error

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:

> > > > 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'".