List,
Two years ago there was discussion on implementing QEMU's
block-dirty-bitmap backup solution:
https://www.redhat.com/archives/libvir-list/2016-June/msg00380.html
https://www.redhat.com/archives/libvir-list/2016-April/msg00401.html
But I haven't seen anything since, and looking through g
:53 PM, Matthew Schumacher wrote:
> Hello List,
>
> I'm trying to get libvirt to work on slackware64-current
> (slackware64-14.2 beta) and while it compiles just fine, it refuses to
> run because of an undefined symbol:
>
> 2016-03-01 20:09:26.822+: 27849: error : virDriv
Hello List,
I'm trying to get libvirt to work on slackware64-current
(slackware64-14.2 beta) and while it compiles just fine, it refuses to
run because of an undefined symbol:
2016-03-01 20:09:26.822+: 27849: error : virDriverLoadModule:73 :
failed to load module
/usr/lib64/libvirt/connection
Posted to https://bugzilla.redhat.com/show_bug.cgi?id=1217185
I just stumbled on another bug while snapshotting and think it's related
to 1210903 and 1197592 as it seems like some sort of race condition
because it depends on what logging is in place and doesn't happen every
time.
Here are the det
On 04/28/2015 05:13 PM, Laine Stump wrote:
> Bah. Your debug symbols aren't enough to give a full stack trace - what
> I was really looking for was those things marked as ??.
>
> However, your debug output shows several things leading up tothe
> qemuProcessStop that might have been the reason for
> On Friday 10 April 2015 13:07:38 Matthew Schumacher wrote:
>> Hello List,
>>
>> Seems like blockcopy --wait doesn't work work qemu-2.2.x.
>>
>> I found someone else having the same problem, but it never went anywhere:
>>
>> https://www.redha
On 04/22/2015 08:19 AM, Laine Stump wrote:
> If you're compiling yourself, then you should be all set to run under
> gdb. libvirt-debuginfo is just a separate subpackage that contains all
> the symbol and line number info from the build so that backtraces in
> gdb make sense. Try attaching gdb to
On 04/20/2015 05:42 PM, Laine Stump wrote:
> Well, this is when the qemu process is killed (I'm pretty clever, eh? :-)
>
> I have 3 questions:
>
> 1) what version of libvirt are you running and on what distro?
>
> 2) can you reproduce this reliably?
>
> 3) If the answer to 2 is "yes", do you have t
On 04/20/2015 05:12 PM, Laine Stump wrote:
> On 04/20/2015 08:45 PM, Matthew Schumacher wrote:
>> List,
>>
>> I was under the impression that I could restart libvirtd without it
>> destroying my VMs, but am not finding that to be true.
> If not, then something
List,
I was under the impression that I could restart libvirtd without it
destroying my VMs, but am not finding that to be true. When I killall
libvirtd then my VM's keep running, but then when I start libvirtd it
calls qemuDomainObjEndJob:1542 : Stopping job: modify (async=none
vm=0x7fb8cc0d8510
Hello List,
Seems like blockcopy --wait doesn't work work qemu-2.2.x.
I found someone else having the same problem, but it never went anywhere:
https://www.redhat.com/archives/libvirt-users/2015-January/msg00045.html
I went ahead and did some more debugging and created a bug report:
https://bu
11 matches
Mail list logo
