A gentle reminder, the following patch set has been pending review since
9 days.
Link to Patch set:
https://listman.redhat.com/archives/libvir-list/2023-August/241250.html
Thanks
Please look at.
On 13/07/2023 12:49, Oleg Vasilev wrote:
On 04/07/2023 13:10, Oleg Vasilev wrote:
Found by repeatedly created and destroyed channels with guest agent. More
details in the patch.
Oleg Vasilev (2):
net: add debug logs
remote: fix stream use-after-free
src/remote/remote
On 04/07/2023 13:10, Oleg Vasilev wrote:
Found by repeatedly created and destroyed channels with guest agent. More
details in the patch.
Oleg Vasilev (2):
net: add debug logs
remote: fix stream use-after-free
src/remote/remote_daemon_stream.c | 13 +++--
src/rpc/virnetmessag
Awaiting review before proceeding attempts for metadata support on other
objects.
- Shiva
Ping
On 15.12.2022 01:25, Oleg Vasilev wrote:
Presently, logs from deleted domains remain forever. Particular motivation
comes from the case when libguestfs has repeatedly created transient VMs,
which in turn created plenty of logs. This takes up space and lots of files
troubles filesystem
Hi all!
Please take a look a RFC linked below. Sorry I switched to a new email
and can't reply to it directly to draw attention.
[RFC PATCH 0/2] logging: add service to cleanup internal log files
https://listman.redhat.com/archives/libvir-list/2022-February/228817.html
Nikolay
PING
On 10/27/21 3:04 PM, zhenwei pi wrote:
QEMU version 3.1 introduced PV_SEND_IPI CPUID feature bit under
commit 7f710c32bb8 (target-i386: adds PV_SEND_IPI CPUID feature bit).
This patch adds a new KVM feature 'pv-ipi' to disable this feature
(enabled by default). Newer CPU platfor
Hi Jiri,
On 2021/1/7 2:11, Jiri Denemark wrote:
> On Tue, Jan 05, 2021 at 21:54:05 +0800, Keqian Zhu wrote:
>> On 2021/1/5 21:34, Daniel P. Berrangé wrote:
>>> On Tue, Jan 05, 2021 at 09:28:27PM +0800, Keqian Zhu wrote:
>> The purpose of QEMU commit 65ace0604551 (migration: add postcopy total
On Tue, Jan 05, 2021 at 21:54:05 +0800, Keqian Zhu wrote:
> On 2021/1/5 21:34, Daniel P. Berrangé wrote:
> > On Tue, Jan 05, 2021 at 09:28:27PM +0800, Keqian Zhu wrote:
> The purpose of QEMU commit 65ace0604551 (migration: add postcopy total
> blocktime into query-migrate)
> is to
On 2021/1/5 21:34, Daniel P. Berrangé wrote:
> On Tue, Jan 05, 2021 at 09:28:27PM +0800, Keqian Zhu wrote:
>> Hi Daniel,
>>
>> Thanks for your reply :-) Please see my words below.
>>
>> On 2021/1/4 19:58, Daniel P. Berrangé wrote:
>>> On Fri, Dec 18, 2020 at 04:38:22PM +0800, Keqian Zhu wrote:
>
On Tue, Jan 05, 2021 at 09:28:27PM +0800, Keqian Zhu wrote:
> Hi Daniel,
>
> Thanks for your reply :-) Please see my words below.
>
> On 2021/1/4 19:58, Daniel P. Berrangé wrote:
> > On Fri, Dec 18, 2020 at 04:38:22PM +0800, Keqian Zhu wrote:
> >> Hi Daniel and Jiri,
> >>
> >> On 2020/12/8 18:31,
Hi Daniel,
Thanks for your reply :-) Please see my words below.
On 2021/1/4 19:58, Daniel P. Berrangé wrote:
> On Fri, Dec 18, 2020 at 04:38:22PM +0800, Keqian Zhu wrote:
>> Hi Daniel and Jiri,
>>
>> On 2020/12/8 18:31, Jiri Denemark wrote:
>>> On Tue, Dec 08, 2020 at 09:27:39 +, Daniel P. Be
On Fri, Dec 18, 2020 at 04:38:22PM +0800, Keqian Zhu wrote:
> Hi Daniel and Jiri,
>
> On 2020/12/8 18:31, Jiri Denemark wrote:
> > On Tue, Dec 08, 2020 at 09:27:39 +, Daniel P. Berrangé wrote:
> >> On Tue, Dec 08, 2020 at 10:06:25AM +0800, zhukeqian wrote:
> >>>
> >>> On 2020/12/7 18:38, Danie
Hi Daniel and Jiri,
On 2020/12/8 18:31, Jiri Denemark wrote:
> On Tue, Dec 08, 2020 at 09:27:39 +, Daniel P. Berrangé wrote:
>> On Tue, Dec 08, 2020 at 10:06:25AM +0800, zhukeqian wrote:
>>>
>>> On 2020/12/7 18:38, Daniel P. Berrangé wrote:
On Mon, Dec 07, 2020 at 09:55:53AM +0800, zhukeq
aniel,
> > >>
> > >> On 2020/12/4 22:42, Daniel Henrique Barboza wrote:
> > >>>
> > >>>
> > >>> On 12/4/20 5:12 AM, zhukeqian wrote:
> > >>>> Hi folks,
> > >>>>
> > >>>> Kindl
;>>
> >>>
> >>> On 12/4/20 5:12 AM, zhukeqian wrote:
> >>>> Hi folks,
> >>>>
> >>>> Kindly ping. I found that this patch is not applied.
> >>>> Has reviewed by Daniel Henrique Barboza and Daniel P. Berrangé
On 2020/12/7 18:38, Daniel P. Berrangé wrote:
> On Mon, Dec 07, 2020 at 09:55:53AM +0800, zhukeqian wrote:
>> Hi Daniel,
>>
>> On 2020/12/4 22:42, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 12/4/20 5:12 AM, zhukeqian wrote:
>>>> Hi
On Mon, Dec 07, 2020 at 09:55:53AM +0800, zhukeqian wrote:
> Hi Daniel,
>
> On 2020/12/4 22:42, Daniel Henrique Barboza wrote:
> >
> >
> > On 12/4/20 5:12 AM, zhukeqian wrote:
> >> Hi folks,
> >>
> >> Kindly ping. I found that this patc
Hi Daniel,
This patch has received ACK from Daniel Henrique Barboza, and waits for your
ACK. Do you have any additional suggestion on it?
Thanks,
Keqian
On 2020/12/4 16:12, zhukeqian wrote:
> Hi folks,
>
> Kindly ping. I found that this patch is not applied.
> Has reviewed by Dan
Hi Daniel,
On 2020/12/4 22:42, Daniel Henrique Barboza wrote:
>
>
> On 12/4/20 5:12 AM, zhukeqian wrote:
>> Hi folks,
>>
>> Kindly ping. I found that this patch is not applied.
>> Has reviewed by Daniel Henrique Barboza and Daniel P. Berrangé.
>
>
On 12/4/20 5:12 AM, zhukeqian wrote:
Hi folks,
Kindly ping. I found that this patch is not applied.
Has reviewed by Daniel Henrique Barboza and Daniel P. Berrangé.
It has my ACK, but looking into the messages I see that Daniel was
inquiring about this being a bug fix or an enhancement (he
Hi folks,
Kindly ping. I found that this patch is not applied.
Has reviewed by Daniel Henrique Barboza and Daniel P. Berrangé.
Cheers,
Keqian
On 2020/7/15 14:18, Keqian Zhu wrote:
> For that Qemu supports returning incoming migration info since its commit
> 65ace0604551 (migration: add po
PING!
On 10/14/20 6:37 PM, zhenwei pi wrote:
v2->v3:
Rework patches to make each patch could be compiled,
v1->v2:
Seperate a 'all in one' patch into 4 patches.
Use a 'flags' with bit definition instead of 'action_required'
& &#x
I feel so sorry for my impolite behavior, and waitting for your review opinions
:)
On 2018/7/9 17:06, Peter Krempa wrote:
> On Mon, Jul 09, 2018 at 16:39:53 +0800, WangJie (Pluto) wrote:
>> ping...
>
> Please don't be impatient. Pinging patches after one day is kind of rud
On Mon, Jul 09, 2018 at 16:39:53 +0800, WangJie (Pluto) wrote:
> ping...
Please don't be impatient. Pinging patches after one day is kind of rude
to the reviewers. Not getting a review after 1 day does not mean we
ignored that patch. The same applies for the weekend. People don't
ping...
On 2018/7/5 10:05, Jie Wang wrote:
>>From 29482622218f525f0133be0b7db74835174035d9 Mon Sep 17 00:00:00 2001
> From: Jie Wang
> Date: Thu, 5 Jul 2018 09:52:03 +0800
> Subject: [PATCH] qemu: stop qemu progress when restore failed
>
> if qemuProcessStartC
On 2018/7/5 10:05, Jie Wang wrote:
>>From 29482622218f525f0133be0b7db74835174035d9 Mon Sep 17 00:00:00 2001
> From: Jie Wang
> Date: Thu, 5 Jul 2018 09:52:03 +0800
> Subject: [PATCH] qemu: stop qemu progress when restore failed
>
> if qemuProcessStartCPUs perform failed in qemuDomainSaveImageS
Ping?
On 2018/5/29 20:38, Jie Wang wrote:
> QEMU has add the 'align' option to 'memory-backend-file'. Expose
> this option to users by new element align.
>
> Signed-off-by: Jie Wang
> ---
> docs/formatdomain.html.in | 18 ++
ping
On 2018/1/5 10:53, Jie Wang wrote:
> offset and len can also be equal to 0 on failed if blockjob return
> status:"BLOCK_JOB_COMPLETED" with error:"File descriptor in bad state",
> so we need to check 'error' in this case.
> ---
> src/qemu/qe
Ping
On 2018/1/5 10:53, Jie Wang wrote:
> offset and len can also be equal to 0 on failed if blockjob return
> status:"BLOCK_JOB_COMPLETED" with error:"File descriptor in bad state",
> so we need to check 'error' in this case.
> ---
> src/qemu/qe
On 2017/2/25 9:41, WangJie (Captain) wrote:
> Hello, I got a question here. When we create consistent active external
> snapshots with flag “VIR_DOMAIN_SNAPSHOT_CREATE_QUIESCE” , the
> qemuDomainSnapshotFSFreeze will be called firstly to freeze all filesystems
> in vm, and then create snapshot
On Mon, Feb 15, 2016 at 04:38:51PM +0300, Pavel Fedin wrote:
> Hello! Sorry, but i did not get any answer to the last question. Would it be
> OK to require and implicitly add only
> shared mode ?
No, I really think setting shared must be an explicit action
by the app configuring libvirt. Autom
Hello! Sorry, but i did not get any answer to the last question. Would it be
OK to require and implicitly add only
shared mode ?
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: libvir-list-boun...@redhat.com [mailto:lib
Some guests may be slower to start than 30 seconds. Use domifstats
to wait for 10 packets to be sent by the guest (usually the DHCP ones
are the first ones).
---
scripts/nwfilter/100-ping-still-working.t | 13 +++--
scripts/nwfilter/210-no-mac-spoofing.t| 13 +++--
scripts
ets to be sent by the guest (usually the DHCP ones
> are the first ones).
> ---
> scripts/nwfilter/100-ping-still-working.t | 13 +++--
> scripts/nwfilter/210-no-mac-spoofing.t| 13 +++--
> scripts/nwfilter/230-no-mac-broadcast.t | 13 +++--
> script
From: Cédric Bosdonnat
Some guests may be slower to start than 30 seconds. Use domifstats
to wait for 10 packets to be sent by the guest (usually the DHCP ones
are the first ones).
---
scripts/nwfilter/100-ping-still-working.t | 13 +++--
scripts/nwfilter/210-no-mac-spoofing.t| 13
Hello!
> Sorry about all the delays, I'll be more responsive going forward.
>
> For my part I've been offline for 2 weeks on my honeymoon, just came back
> today...
Wow, congratulations then! I didn't know, of course, this is very important
thing.
And of course i know about LinuxCon too, unf
On 08/27/2015 02:37 AM, Pavel Fedin wrote:
> Hello! I remember you were worrying about a temporary hack in qemu's
> postparse, because test suite
> could not generate proper capability cache. I promised to solve this, and
> here is (almost) a
> solution, i've outlined one small problem to solve
Hello! I remember you were worrying about a temporary hack in qemu's
postparse, because test suite
could not generate proper capability cache. I promised to solve this, and here
is (almost) a
solution, i've outlined one small problem to solve together in the cover
message. Since then, no
respon
On Tue, Aug 04, 2015 at 02:08:02PM +0300, Pavel Fedin wrote:
Hello! Can anybody tell me what is wrong with this? Ignored for a long time.
I'm not sure why I'm in Cc, it's usually enough to just ping the
series. Looking at previous mails it looks like you're adding pe
Hello! Can anybody tell me what is wrong with this? Ignored for a long time.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com]
> On Behalf Of Pavel
> F
PING
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com]
> On Behalf Of Pavel
Fedin
> Sent: Friday, July 17, 2015 2:28 PM
> To: libvir-
Knock-knock!!!
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com]
> On Behalf Of Pavel
Fedin
> Sent: Thursday, July 09, 2015 12:11 PM
> To: libvir-list@r
Hi,
Can you please review "nodedev: add RDMA and tx-udp_tnl-segmentation NIC
capabilities" patch [1]?
[1] - http://www.redhat.com/archives/libvir-list/2015-June/msg00921.html
Thanks,
Moshe Levi.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/lis
Sorry I was offline 12-16, I'll review this before end of the week
- Cole
On 06/16/2015 04:06 AM, Pavel Fedin wrote:
> Hello ?
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
>
>> -Original Message-
>> From: libvir-list-boun...@redhat.com
Knock-knock???
Sorry for possibly repeated PING, but i see that mailing list for some reason
strips
CC:'s if specified without real name, so retry with name this time.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message
Hello ?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
> -Original Message-
> From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com]
> On Behalf
Of
> Pavel Fedin
> Sent: Thursday, June 11, 2015 9:41 AM
> To: libvir-list@redhat.
On Friday, March 28, 2014 11:28:19 AM Mike Latimer wrote:
> Using a statically defined vnet0 may fail if multiple VMs are running on the
> test machine. Switch to mac address, but replace '00' with '0' to match the
> output of ebtables.
>
> ---
> scripts
Using a statically defined vnet0 may fail if multiple VMs are running on the
test machine. Switch to mac address, but replace '00' with '0' to match the
output of ebtables.
---
scripts/nwfilter/100-ping-still-working.t | 4 ++--
1 file changed, 2 insertions(+), 2 deleti
On 03/25/2014 07:15 AM, Wangrui (K) wrote:
> macvtap0 is belong to vm at the dest side. When migrate begins macvtap0 will
> send the packet like this:
>
> 07:57:59.233270 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1
> group record(s), lengt 28
> 07:58:00.096088 I
tap will not respond ping
request when being migrated
On 03/18/2014 02:12 AM, Wangrui (K) wrote:
> A vm which uses macvtap will not respond ping request, when the vm is being
> migrated.
>
> I found that on the destination side the macvtap will send a IPv6 packet at
> the begin of
On 03/18/2014 02:12 AM, Wangrui (K) wrote:
> A vm which uses macvtap will not respond ping request, when the vm is being
> migrated.
>
> I found that on the destination side the macvtap will send a IPv6 packet at
> the begin of migration to update the route table in switch
A vm which uses macvtap will not respond ping request, when the vm is being
migrated.
I found that on the destination side the macvtap will send a IPv6 packet at the
begin of migration to update the route table in switch, however VM is still on
the src.
In this case , what can I do to avoid
On 03/22/2012 03:02 PM, Martin Kletzander wrote:
I'd rather do it using the get() method for dictionaries with some
default, i.e. params.get('flags', None).
Just my $0.02
Martin
Thanks, This belongs to enhancement work, let us do it a little later.
Probably, we need a cleanup patch f
On 03/21/2012 06:13 PM, Guannan Ren wrote:
> On 03/21/2012 08:46 PM, Peter Krempa wrote:
>> For some tests it's not needed to ping the guest in the startup process.
>> This patch adds a flag to the start and destroy test to skip such
>> attempts (that consume a lot
On 03/21/2012 08:46 PM, Peter Krempa wrote:
For some tests it's not needed to ping the guest in the startup process.
This patch adds a flag to the start and destroy test to skip such
attempts (that consume a lot of time)
---
repos/domain/destroy.py |
For some tests it's not needed to ping the guest in the startup process.
This patch adds a flag to the start and destroy test to skip such
attempts (that consume a lot of time)
---
repos/domain/destroy.py | 54 ++
repos/domain/start.py |
I have several pending patches that are probably worth inclusion in
0.8.5; would anyone like to review them?
https://www.redhat.com/archives/libvir-list/2010-October/msg00726.html -
virsh help text relating to integer arguments
https://www.redhat.com/archives/libvir-list/2010-October/msg00728
On Tue, Dec 08, 2009 at 04:00:14PM +0100, Paolo Bonzini wrote:
> http://permalink.gmane.org/gmane.comp.emulators.libvirt/18779
> [libvirt] [PATCH 1/2] add --crash support to "virsh dump"
>
> http://permalink.gmane.org/gmane.comp.emulators.libvirt/18811
> [libvirt] [PATCH 2/2 v2] add --live support
http://permalink.gmane.org/gmane.comp.emulators.libvirt/18779
[libvirt] [PATCH 1/2] add --crash support to "virsh dump"
http://permalink.gmane.org/gmane.comp.emulators.libvirt/18811
[libvirt] [PATCH 2/2 v2] add --live support to "virsh dump"
Thanks!
Paolo
--
Libvir-list mailing list
Libvir-lis
n' method will
> > > return
> > > success, regardless of whether XenD is even present. The attached patch
> > > makes the open method do a 'ping' to see if XenD is actually there,
> > > returning
> > > failure if it is not. This ensures that
en present. The attached patch
> > makes the open method do a 'ping' to see if XenD is actually there,
> > returning
> > failure if it is not. This ensures that the XenD driver backend doesn't get
> > activated when connecting to alternate non-Xen backends, such a
On Mon, Jun 12, 2006 at 04:01:33PM +0100, Daniel P. Berrange wrote:
> Currently the XenD driver's implementation of the 'open' method will return
> success, regardless of whether XenD is even present. The attached patch
> makes the open method do a 'ping'
Currently the XenD driver's implementation of the 'open' method will return
success, regardless of whether XenD is even present. The attached patch
makes the open method do a 'ping' to see if XenD is actually there, returning
failure if it is not. This ensures that the Xe
64 matches
Mail list logo
