[libvirt] pool default not starting on f10

Cole Robinson crobinso at redhat.com
Tue May 5 17:51:45 UTC 2009


Jason Guiditta wrote:
> On Tue, 2009-05-05 at 12:59 -0400, Cole Robinson wrote:
>> Jason Guiditta wrote:
>>> Hello, hopefully this is something simple I just don't understand how to
>>> debug, but right now, it is keeping me from creating any new VMs.  As
>>> stated in the subject, I am running F10, on x86_64 arch.  Libvirt
>>> version is 0.6.1-5.fc10.  Using virt-manager to create a new vm, when I
>>> get to the step to create a disk image, I get the error:
>>> 'Storage parameter error. internal error storage pool is not active'.
>>> Running 
>>>
>>> virsh pool-start default
>>>
>>> gets me:
>>> error: Failed to start pool default
>>> error: out of memory
>>>
>>> Note there is no reason my machine would be out of memory, is has 6GB
>>> and nothing else running (and tried this right after booting)
>>>
>>> virsh pool-list --all
>>>
>>> shows default is inactive and 'yes' for autostart
>>>
>>> I would be happy to file a bug if needed, but thought I would throw this
>>> out to the list first to see if I was just unaware of some simple fix.
>>> Let me know if there are other details I can provide to make this easier
>>> to solve. Thanks,
>>>
>>> -j
>> Can you try the following:
>>
>> su -
>> service libvirtd stop
>> libvirtd
>>
>> Then from another terminal:
>>
>> sudo virsh pool-start default
>>
>> And see if anything more informative is printed in the 'libvirtd'
>> terminal: there may be a useful error that we are squashing somewhere.
>>
>> Thanks,
>> Cole
>>
> Cole, ok, I tried that, and here is what I got:
> libvirtd
> libvir: Storage error : cannot open volume
> '/var/lib/libvirt/images/f10-dev-server-base.img': No such file or
> directory
> libvir: Storage error : out of memory
> 

Hmm, strange. That 'No such file' is the legit error, not really sure
what would be causing it though. The 'out of memory' that comes next is
where the squashing takes place, since the last error is what's reported
to the user.

> So, since it seemed to be looking for that .img file (couldnt find any
> refs to it in /etc/libvirt/qemu/), I cp'ed an existing img file and gave
> it that name.  Apparently that was a bad idea, as I now get:
> 
> libvirtd
> 13:29:42.148: error : invalid storage volume pointer in no storage vol
> with matching path
> libvir: Storage error : invalid storage volume pointer in no storage vol
> with matching path
> 13:29:42.170: error : invalid storage volume pointer in no storage vol
> with matching path
> libvir: Storage error : invalid storage volume pointer in no storage vol
> with matching path
> 

This isn't necessarily a bad thing, if it isn't reported to the user,
then the lookup failure was probably expected.

> 
> This list continues for some time.  I have pastebin'ed the full output
> if you want it here: http://pastebin.com/d3f4ae378
> 
> At this point, virsh pool-start default gives me 
> 13:32:14.223: error : internal error pool already active
> libvir: Storage error : internal error pool already active
> 
> from my console with libvirtd running.  If I go ahead and try to create
> a VM again with virt-manager (reopened since I restarted libvirtd), I
> get:
> 13:32:43.791: error : Domain not found
> libvir: QEMU error : Domain not found
> 13:32:51.720: error : Domain not found
> libvir: QEMU error : Domain not found
>

There are likely also expected lookup failures, so no worries.

> from libvirtd at each step.  If you don't have anything else you want me
> to try, I will look up the libvirt build steps and try applying that
> patch you sent. Thanks,
> 

Thanks for the offer, but it's probably not necessary. The above output
confirmed the OOM squashing. I'm curious how the 'File not found' error
managed to happen though. I'll poke through the code somemore

Thanks,
Cole




More information about the libvir-list mailing list