search for: qemudomainobjendjob

...te: > 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 is wrong. > 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) That message doesn't indicate that a domain is being destroyed, just that libvirt performed some operation on the domain that modified it in some way. > and my domain gets whacked. If your domain is terminated, the...

On 04/21/2015 05:53 PM, Matthew Schumacher wrote: > 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

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 at it, due to issues with snapshotting, I ended up with two domains where libvirt insists the disk source is incorrect which causes many things to...

On 04/28/2015 06:03 PM, Matthew Schumacher wrote: > > 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

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

...: deinitializing FS storage file > 0x7fb8cc0d75f0 (block:/dev/sr0) > 2015-04-20 23:50:20.387+0000: 25373: info : virObjectUnref:259 : > OBJECT_UNREF: > obj=0x7fb8cc0155b0 > 2015-04-20 23:50:20.387+0000: 25373: debug : qemuDomainObjEndJob:1542 : > Stopping job: modify (async=none vm=0x7fb8cc0d8510 name=test) > 2015-04-20 23:50:20.387+0000: 25373: info : virObjectRef:296 : > OBJECT_REF: > obj=0x7fb8cc0155b0 > 2015-04-20 23:50:20.387+0000: 25373: debug : qe...

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/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

...leBackendFileDeinit:1369 : deinitializing FS storage file 0x7fb8cc0d75f0 (block:/dev/sr0) 2015-04-20 23:50:20.387+0000: 25373: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x7fb8cc0155b0 2015-04-20 23:50:20.387+0000: 25373: debug : qemuDomainObjEndJob:1542 : Stopping job: modify (async=none vm=0x7fb8cc0d8510 name=test) 2015-04-20 23:50:20.387+0000: 25373: info : virObjectRef:296 : OBJECT_REF: obj=0x7fb8cc0155b0 2015-04-20 23:50:20.387+0000: 25373: debug : qemuProcessStop:5089 : Shut...

...RECV_REPLY: mon=0x7fe784255020 reply={"return": {}, "id": "libvirt-373"} 2020-10-12 02:11:33.852+0000: 6825: debug : qemuDomainObjExitMonitorInternal:5615 : Exited monitor (mon=0x7fe784255020 vm=0x55f086c81ea0 name=cartridge) 2020-10-12 02:11:33.852+0000: 6825: debug : qemuDomainObjEndJob:1140 : Stopping job: async nested (async=migration in vm=0x55f086c81ea0 name=cartridge) 2020-10-12 02:11:33.852+0000: 6825: error : virPortAllocatorSetUsed:299 : internal error: Failed to reserve port 49153 2020-10-12 02:11:33.852+0000: 6825: debug : qemuMigrationParamsReset:1206 : Resetting migrat...

...: virObjectUnref:350 : OBJECT_UNREF: obj=0x7f20840008c0 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:352 : OBJECT_DISPOSE: obj=0x7f20840008c0 2018-02-27 09:27:43.788+0000: 16656: info : virObjectUnref:350 : OBJECT_UNREF: obj=0x7f2030101cb0 2018-02-27 09:27:43.788+0000: 16656: debug : qemuDomainObjEndJob:5594 : Stopping job: modify (async=none vm=0x7f20300fa6e0 name=6ec499397d594ef2a64fcfc938f38225) ====================================================== But it fails. Best Regards, Star Guo -----邮件原件----- 发件人: Michal Privoznik [mailto:mprivozn@redhat.com] 发送时间: 2018年2月27日 16:53 收件人: Star Guo...

...n")); goto endjob; } if (!(persistentDef = virDomainObjGetPersistentDef(driver->caps, vm))) goto endjob; sa_assert(persistentDef); persistentDef->running_mode = opt; ret = virDomainSaveConfig(driver->configDir, persistentDef); ret = 0; endjob: if (qemuDomainObjEndJob(driver, vm) == 0) vm = NULL; cleanup: if (vm) virDomainObjUnlock(vm); return ret; } xuanmao_001 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120620/8f9cccae/attachment.htm>

...if (ret < 0) + goto out; + } else { + ret = qemuDomainDetachDevicePersistent(vmdef, device); + if (ret < 0) + goto out; + } + ret = virDomainSaveConfig(driver->configDir, vmdef); + +out: + virDomainDeviceDefFree(device); +endjob: + if (qemuDomainObjEndJob(vm) == 0) + vm = NULL; + if (vm) + virDomainObjUnlock(vm); + /* Note: insert of newdev is done by copy */ +unlock_out: + qemuDriverUnlock(driver); + return ret; +} + static int qemudDomainAttachDeviceFlags(virDomainPtr dom, const c...

Here is v11. Fixed comments/bugs and updated against the latest libvirt.git. Changes v10->v11: - fixed comments on each patches - fixed cgroup handling in patch 3. - fixed MODIFY_CURRENT handling in patch 4. most of diff comes from refactoring qemu/qemu_driver.c -- conf/domain_conf.c | 40 ++ conf/domain_conf.h | 5 libvirt_private.syms | 3 qemu/qemu_driver.c | 727

...'in shutdown’, and the libvirt log is as follows: “active” is my test vm’s name. 2019-08-05 08:39:57.001+0000: 25889: warning : qemuDomainObjBeginJobInternal:4308 : Starting job: modify (vm=0x7f7bbc145fe0 name=active, current job=none async=none) 2019-08-05 08:39:57.003+0000: 25889: warning : qemuDomainObjEndJob:4522 : Stopping job: modify (async=none vm=0x7f7bbc145fe0 name=active) 2019-08-05 08:39:57.003+0000: 25881: warning : qemuMonitorJSONIOProcessEvent:235 : type: POWERDOWN, vm: active, cost 0.008 secs 2019-08-05 08:39:57.854+0000: 25881: warning : qemuMonitorJSONIOProcessEvent:235 : type: SHUTDOWN, v...

...7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.678+0000: 50516: debug : qemuTeardownImageCgroup:123 : Not updating cgroups for disk path '08085a31f8c43f278ed2f649ee166b1f@08085a31f8c43f278ed2f649ee166b1f', type: network 2018-02-26 13:09:13.682+0000: 50516: debug : qemuDomainObjEndJob:4979 : Stopping job: modify (async=none vm=0x7f7294100af0 name=6ec499397d594ef2a64fcfc938f38225) 2018-02-26 13:09:13.983+0000: 50520: debug : virDomainLookupByName:412 : conn=0x7f7278000aa0, name=6ec499397d594ef2a64fcfc938f38225 2018-02-26 13:09:13.990+0000: 50518: debug : virDomainGetInfo:2431 :...