similar to: Block Commit: [100 %]error: failed to pivot job for disk vda (Bug filed)

> 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.redhat.com/archives/libvirt-users/2015-January/msg00045.html >> >> I went ahead and did some more

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.redhat.com/archives/libvirt-users/2015-January/msg00045.html > > I went ahead and did some more debugging and created a bug report: >

On Tuesday 28 April 2015 17:13:38 Matthew Schumacher wrote: > Got a chance to work on this today, and posted a bunch of debug on the > bug ticket: > > https://bugzilla.redhat.com/show_bug.cgi?id=1210903 > > Hopefully that helps track this down. Currently it works for me again. Linux-4.0.3, Qemu-2.3.0, Libvirt-1.2.15. cheers t.

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 the libvirt-debuginfo > package installed, and can you

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 the libvirtd process and do > something like "thread apply all bt" - if

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 it being called: > > 1) virStorageFileBackendFileReadHeader() complains

On 01/07/2015 07:19 AM, Thomas Stein wrote: > Hello. > > I'm seeing this error while doing a backup of a VM. > > + virsh blockcommit kaltura vda --active --verbose --pivot > Block Commit: [100 %]error: failed to pivot job for disk vda > error: internal error: unable to execute QEMU command > 'block-job-complete': The active block job for device >

Am 07.01.15 um 18:26 schrieb Thomas Stein: >> Based on this message, it is qemu that is refusing to do the pivot, but >> I don't know if that is because of permissions on the destination file, >> or something else (that is, it may still be a libvirt bug for not >> putting things in the right state for the qemu command to have a chance >> of succeeding). What

On Wednesday 07 January 2015 09:46:09 Eric Blake wrote: > On 01/07/2015 07:19 AM, Thomas Stein wrote: > > Hello. > > > > I'm seeing this error while doing a backup of a VM. > > > > + virsh blockcommit kaltura vda --active --verbose --pivot > > Block Commit: [100 %]error: failed to pivot job for disk vda > > error: internal error: unable to execute

Matthew Schumacher wrote: > List, > > I think I found a bug here because I can repeatably get the same kernel > (checked with md5sum) to decompress and to fail with the error: > > invalid compressed format (err=2) > > --System halted > > > Here is how I can reproduce the problem: > > Boot 2.6.8-rc1 > Run md5sum on 2.6.8-rc1 kernel >

Hello. I'm seeing this error while doing a backup of a VM. + virsh blockcommit kaltura vda --active --verbose --pivot Block Commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed I'm on qemu 2.2.0 and libvirt-1.2.11. Does

Hi, Is it possible to "pivot" to a new image without doing blockcopy or blockpull? I know how to use snapshots and blockpull to create a new image and pivot to using it live, but what I would like to do is to have a VM switch from using imageA.qcow2 to image2.qcow2 while running. I don't see why this wouldn't be possible since some of the existing libvirt tools can do this when

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 name=test) and my domain gets whacked. Any way to disable this behavior? Also, while I'm

Hi Eric, Thanks for the info. I see the value in this, but it isn't quite what I was looking for. Basically what I want to do is to switch between snapshots quickly. For instance, I am currently working on designing a HA SQL implementation with failover. So right now I have 5 VM's running postgresql as a replication group. I am trying a lot of different things and often have to take a

I am getting a bad username or password error when I try to logon to the domain from a windows 2000 server. I can't find anything wrong with my config and I'm using a root user that is in the directory with the uid and gid set to 0. The only thing I see in the logs is something about incorrect password length, but I checked that my passwords are encrypted and I can access shares as

I searched around but didn't find an answer to my question, hopefully someone here knows how to fix this problem. The issue is actually pretty simple, if I use "security = user" and add a user with smbpasswd then I can connect to the share from windows 2003 server. However, if I set "security = server" then define the same windows 2003 server as the password server then I

List, I purchased 2 g729 licenses but I can't get it to answer a g729 call from a cisco router with a vwic card. In the debug output below you will see that asterisk thinks it only supports: (gsm|ulaw|alaw|h263) when it should support g729 according to the config also listed below. The real odd thing is I can place g729 calls to the router, just not from the router to *. Anyone have any

Thank you Eric, On 2014-02-05 17:23, Eric Blake wrote: > Yes, live storage migration is possible; although at the moment, qemu is > lacking a way to restart the operation if it fails midstream, so libvirt > only allows the operation if you are willing to temporarily make your > guest transient. What does this mean? Will I loose anything if - for example - there is not enough space on

I am experimenting with the blockcopy command, and after figuring out how to integrate qemu-nbd, nbd-client and dumpxml/undefine/blockcopy/define/et. al. I have one remaining question: What's the point? The "replication" disk file is not, from what I can ascertain, bootable. I expect this operation to create a pristine copy of my source qcow2 file (at a given point in time)

Versions -------- (Libvirt locally built from a recent git commit -ec7b922): $ rpm -q libvirt-daemon-kvm qemu-system-x86 libvirt-daemon-kvm-1.2.6-1.fc20.x86_64 qemu-system-x86-2.0.0-1.fc21.x86_64 Test ---- [All images are qcow2 files.] We have this simple chain: base <- snap1 Let's quickly examine the contents of 'base' and 'snap1' images: