Displaying 7 results from an estimated 7 matches for "peric".
Did you mean:
eric
2019 Sep 19
1
Re: [PATCH nbdkit 0/2] Add new retry filter.
On Thu, Sep 19, 2019 at 01:47:45PM +0200, Nenad Peric wrote:
> A theoretical way to test this against any other protocol is to have a
> firewall rule which can be triggered locally which just drops the traffic
> and then re-enables the traffic in a while (short or long, can be
> decided/tweaked).
We generally want our tests to run without...
2018 Sep 25
0
Re: OpenStack output - server_id
...ANQwMf/rN5406P0up9qTR1owxlRxSUf0ydKSdqcsZH/m5Ua4w5t9fPCHxCmOXiVfTW5iFKZOIGQwdcH8f5j5UnX/Q50dyrvy2QIw+nzLQcGHa5ZZKPFcXmAO7NBx7pIdrf76FtIVwnF4FA8AAKrsZc4We/IAAhX/SUNYZ3JHjp/M=",
"uuid": "7ee62bdc-1c9d-4193-bb8f-fdbbbdfded0f"
}
The information we need is the uuid.
@Nenad Peric <nperic@redhat.com>, this comes from our lab. I've enabled
DHCP on the external network, but that don't mean that all networks will
use it. In the conversion host project, I'd enable it.
On Mon, Sep 24, 2018 at 9:16 PM Nenad Peric <nperic@redhat.com> wrote:
>
>
>...
2018 Sep 24
2
Re: OpenStack output - server_id
On Mon, Sep 24, 2018 at 6:30 PM Richard W.M. Jones <rjones@redhat.com>
wrote:
> On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote:
> > Hi,
>
> Hi Fabien, sorry I didn't respond to this earlier as I was doing some
> work. If you CC me on emails then you can usually get a quicker
> response.
>
> > I've read the virt-v2v OpenStack output code
2016 Mar 24
0
nut-ipmipsu 2.7.3-2.7.4 crash on ipmi_sdr_ctx_destroy in libfreeipmi_cleanup
...d8)[0x7fec04a679d8]
/lib64/libfreeipmi.so.16(ipmi_sdr_ctx_destroy+0x42)[0x7fec04a3d1d2]
nut-ipmipsu(+0x4432)[0x55de01669432]
nut-ipmipsu(+0x4ee9)[0x55de01669ee9]
nut-ipmipsu(+0x3a38)[0x55de01668a38]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7fec040cb700]
nut-ipmipsu(+0x3ed9)[0x55de01668ed9]
Zoran Pericic
-------------- next part --------------
2019 Sep 19
1
Re: Thoughts on nbdkit automatic reconnection
I have an update on the networking issue:
- After the deep dive into the logs of the firewall by customer's security
team, it turns out that even though there were some disconnections, the
time-stamps do not match.
This means that we got the disconnected by something else (ESXi or
conversion host perhaps)
- As we mentioned in the chat briefly, there could be general keep-alive
issues on both
2019 Sep 19
6
[PATCH nbdkit 0/2] Add new retry filter.
This is a retry filter implementation as outlined here:
https://www.redhat.com/archives/libguestfs/2019-September/msg00167.html
It is only lightly tested. One way to test it is to try an SSH copy
(see the commit message for patch 2/2), and in the middle of the copy
kill the per-connection sshd on the remote machine. You will see that
the copy recovers after a few seconds. Add the nbdkit -v
2019 Sep 19
0
Re: [PATCH nbdkit 0/2] Add new retry filter.
A theoretical way to test this against any other protocol is to have a
firewall rule which can be triggered locally which just drops the traffic
and then re-enables the traffic in a while (short or long, can be
decided/tweaked).
This way, there is no need to think about which protocol is used, when we
kill the connectivity.
The only consideration could probably be that the dropped connections