Re:[PATCH] util: fix: duplicated index at nested loop in virNVMeDeviceListCreateReAttachList

Hi Michal, Thanks for your reply. > On 7/29/21 4:16 AM, Yi Wang wrote: > > From: Jia Zhou > > > > When loop in function virNVMeDeviceListCreateReAttachList() there may be > > reused index @i, this patch fix this by using a new @j. > > > > Signed-off-by: Jia Zhou > > Signed-off-by: Yi Wang > >

Re:[PATCH] qemu: Fix error returned value in qemuGetProcessInfo when fscanf execute failed

Hi Michal, Thanks for your reply. > On 7/15/21 8:18 AM, Yi Wang wrote: > > From: Long YunJian > > > > If fscanf execute failed, qemuGetProcessInfo shuld return -1, > > but it return 0 at the end. Zero means success for the caller, > > so we shuld return -1 in the case of failure. > > ... > >

Re: [libvirt] [PATCH] create a thread to handle MigrationParamResetto avoid deadlock

Hi Daniel, Thanks a lot for your review and reply! > On Mon, Dec 23, 2019 at 04:50:00PM +0100, Michal Prívozník wrote: > > On 12/23/19 11:12 AM, Daniel P. Berrangé wrote: > > > On Mon, Dec 23, 2019 at 03:13:10PM +0800, Yi Wang wrote: > > >> From: Li XueLei > > >> > > >> Libvirtd no longer

Re: [libvirt] [PATCH v2] qemu: fix vcpupin fail as no vcpu tid set

> more descriptive as: > qemu: fix vcpu pinning when not all vcpus are enabled Thanks. > > On Tue, Feb 26, 2019 at 10:01:28AM +0800, Yi Wang wrote: > >vcpupin will fail when maxvcpus is larger than current > >vcpu: > > > >virsh vcpupin win7 --vcpu 0 --cpulist 5-6 > >error: Requested operation is

Re: [libvirt] [PATCH] qemu: fix vcpupin fail as no vcpu tid set

Hi Jano, Thanks for your reply. > On Mon, Feb 18, 2019 at 05:21:31PM +0800, Wen Yang wrote: > >From: Yi Wang > > > >vcpupin will fail when maxvcpus is larger than current > >vcpu: > > ... > > This for loop was introduced by: > commit 34f77437da884f9cf0e2450f25f373b17cf527e2 > qemu: fix

Re: [libvirt] [PATCH] conf: fix starting a domain with cpuset=""

> On Wed, Sep 19, 2018 at 08:11:34AM +0800, wang.y...@zte.com.cn wrote: > > > On Mon, Sep 17, 2018 at 06:53:13PM +0800, wang.y...@zte.com.cn wrote: > > > > > On Sat, Sep 15, 2018 at 04:29:24PM +0800, Yi Wang wrote: > > > > > > Domain fails to start when its config xml including: > > > > > > 64 >

Re: [libvirt] [PATCH] conf: fix starting a domain with cpuset=""

> On Mon, Sep 17, 2018 at 06:53:13PM +0800, wang.y...@zte.com.cn wrote: > > > On Sat, Sep 15, 2018 at 04:29:24PM +0800, Yi Wang wrote: > > > > Domain fails to start when its config xml including: > > > > 64 > > > > > > > > # virsh create vm.xml > > > > error: Failed to create domain from

Re: [libvirt] [PATCH] conf: fix starting a domain with cpuset=""

> On Sat, Sep 15, 2018 at 04:29:24PM +0800, Yi Wang wrote: > > Domain fails to start when its config xml including: > > 64 > > > > # virsh create vm.xml > > error: Failed to create domain from vm.xml > > error: invalid argument: Failed to parse bitmap '' > > > > This patch fixes this. > >

Re: [libvirt] [PATCH v7] qemu: Introduce state_lock_timeout toqemu.conf

> On Thu, Sep 13, 2018 at 18:47:55 +0800, Yi Wang wrote: > > When doing some job holding state lock for a long time, > > we may come across error: > > > > "Timed out during operation: cannot acquire state change lock" > > > > Well, sometimes it's not a problem and users want to continue > > to

Re: [libvirt] [PATCH] qemu: Introduce state_lock_timeout to qemu.conf

> Yi Wang [2018-09-13, 10:39AM +0800]: > > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > > index 886e3fb..306772a 100644 > > --- a/src/qemu/qemu_domain.c > > +++ b/src/qemu/qemu_domain.c > > @@ -6652,9 +6652,6 @@ qemuDomainObjCanSetJob(qemuDomainObjPrivatePtr priv, > >

Re: [libvirt] [PATCH v5] qemu: Introduce state_lock_timeout toqemu.conf

Thank you both for your patience and discussion, John and Michal. I will send a new version to fix the issues referred in the discussion. > On 09/10/2018 10:22 PM, John Ferlan wrote: > > > > > > On 09/05/2018 11:09 PM, Yi Wang wrote: > >> When doing some job holding state lock for a long time, >

Re: [libvirt] [PATCH v4] qemu: Introduce state_lock_timeouttoqemu.conf

> On Wed, Sep 05, 2018 at 04:49:59PM +0800, wang.y...@zte.com.cn wrote: > >Hi Jano, > >thanks for your reply. > > > >> On Tue, Aug 28, 2018 at 04:40:16PM +0800, Yi Wang wrote: > > [...] > > >> >diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug > >> >index ddc4bbf..f7287ae 100644

Re: [libvirt] [PATCH v4] qemu: Introduce state_lock_timeout toqemu.conf

Hi Jano, thanks for your reply. > On Tue, Aug 28, 2018 at 04:40:16PM +0800, Yi Wang wrote: > >When doing some job holding state lock for a long time, > >we may come across error: > >"Timed out during operation: cannot acquire state change lock" > >Well, sometimes it's not a problem and users

Re: [libvirt] [PATCH v2] qemu: Introduce state_lock_timeout toqemu.conf

> On 08/27/2018 09:29 AM, Michal Prívozník wrote: > > On 08/27/2018 12:57 PM, Yi Wang wrote: > >> When doing some job holding state lock for a long time, > >> we may come across error: > >> "Timed out during operation: cannot acquire state change lock" > >> Well, sometimes it's not a problem and

Re: [libvirt] [PATCH v2] qemu: Introduce state_lock_timeout toqemu.conf

> On 08/27/2018 12:57 PM, Yi Wang wrote: > > When doing some job holding state lock for a long time, > > we may come across error: > > #swtpm_user = "tss" > > #swtpm_group = "tss" > > + > > +# The timeout (in seconds) waiting for acquiring state lock. > > This is rather sparse description. I

Re: [libvirt] [PATCH] qemu: Introduce state_lock_timeout to qemu.conf

Thanks for your review, Michal. I will send a v2 patch. > On 08/27/2018 08:04 AM, Yi Wang wrote: > > When doing some job holding state lock for a long time, > > we may come across error: > > "Timed out during operation: cannot acquire state change lock" > > Well, sometimes it's not a problem and

Re: [libvirt] [PATCH] [PATCH] vcpupin: add clear feature

Thanks for your reply, and I will send a new version of this patch. >On Thu, Jan 04, 2018 at 05:46:32 -0500, Yi Wang wrote: >> We can't clear vcpupin settings of XML once we did vcpupin >> command, this is not convenient under some condition such >> as migration. >> >> This patch introduces clear

Re: [libvirt] [PATCH] qemu: undefine is not allowed during domainstarting up

>On 07/22/2017 04:55 AM, Yi Wang wrote: >> Start a domain whilst undefine it, if starting failed duing ProcessLaunch, >> on which period qemu exited unexpectedly, the operation will lead to failure >> of undefine the domain until libvirtd restarted. The reason is that libvirtd >> will unlock

Re: [libvirt] [PATCH] qemu: fix migration fail of an auto-placementvm after attached memory to it

>On Sat, Jul 22, 2017 at 05:45:59 -0400, Yi Wang wrote: >> This patch fix this condition: >> -vm has the "auto" placement in vcpu >> -hot-plug memory with source node "1-3" through attach-device command >> -migrate the vm to a host with only 2 numa node >> And the migration will fail

Re: [libvirt] [PATCH] qemu: undefine is not allowed during domainstarting up

Hi Peter, Thanks for your reply. >On Sat, Jul 22, 2017 at 04:55:49 -0400, Yi Wang wrote: >> Start a domain whilst undefine it, if starting failed duing ProcessLaunch, >> on which period qemu exited unexpectedly, the operation will lead to failure >> of undefine the domain until libvirtd

Re: [libvirt]  Re: [PATCH RESEND] qemu: Remove inactive vm when failedtostart it

Hi John, I have reworked this patch on the other new thread[1], please review that patch. Thank you :-) [1] https://www.redhat.com/archives/libvir-list/2017-July/msg00921.html >On 07/12/2017 07:34 AM, wang.y...@zte.com.cn wrote: >> Hi John, >> >> Thanks for your review! >> >

Re: [libvirt] [PATCH RESEND] qemu: Remove inactive vm when failedtostart it

>On 07/12/2017 07:34 AM, wang yi59 zte com cn wrote: >> Hi John, >> >> Thanks for your review! >> > >Somehow your response is out of synch with the rest of the series - >things like this get lost very quickly. > >>> This seems to be a strange sequence of operations, but the claim is that

Re: [libvirt] [Qemu-devel] [PATCH v2] hmp: allow cpu index for "info lapic"

>On Wed, Jul 19, 2017 at 08:17:49PM +0100, Dr. David Alan Gilbert wrote: >> * Eduardo Habkost (address@hidden) wrote: >> > On Wed, Jul 19, 2017 at 10:17:36AM -0500, Eric Blake wrote: >> > > On 07/19/2017 10:07 AM, Daniel P. Berrange wrote: >> > > >> It doesn't. Perhaps we should add that as a

Re: [libvirt] [PATCH RESEND] qemu: Remove inactive vm when failed tostart it

Hi John, Thanks for your review! > This seems to be a strange sequence of operations, but the claim is that > by adding this logic to CreateWithFlags, then the problem you're facing > is resolved. However, is adding this to the Create logic the right thing > to do? > IIUC: This condition is

Re: [libvirt] [PATCH RESEND] qemu: Remove inactive vm when failed to start it

Hi all, Could someone review my patch please? > Libvirt forgets to remove inactive vm when failed to start a defined vm. > That may result in residual domain in driver->domains on such condition: > during the process of starting a vm, undefine it, and qemu exit because > of some exception.

Re: [libvirt] [PATCH] qemu: Starting a domain with custom model andallowed-fallback failed when host lacks some CPU features

Hi Jirka,Thanks for your reviewing. But in the condition I described, libvirt has no chance to translate into a different model, because it has failed in the virCPUCompare before translate and the start of the domain will report the error, it that correct? For example, a host lacks "monitor"

Re: [libvirt] [PATCH] qemu: Fix memory leak inqemuDomainUpdateMemoryDeviceInfo

Thank you Michal --- Best wishes Yi Wang 原始邮件 发件人： ＜mpriv...@redhat.com＞ 收件人：汪翼10129963 ＜libvir-list@redhat.com＞ 抄送人：刘建军10033482徐熙00121931 日 期 ：2017年05月24日 23:00 主 题 ：Re: [libvirt] [PATCH] qemu: Fix memory leak inqemuDomainUpdateMemoryDeviceInfo On 05/25/2017 04:20 AM, Yi

Re: [libvirt] [PATCH] [PATCH] rpc: fix keep alive timer segfault

Hi Michal, Thanks for your review. The problem occured in a python applicatin using libvirt-python, which has no ref(). If we unref() first in virKeepAliveTimer, we may get a segfault in virObjectUnlock() when cleanup, so I suppose that my patch is safer, :-) Here is the backtrace: