On Monday, April 20, 2020 11:27:59 A.M. EDT Mark Asselstine wrote:
> On Monday, April 20, 2020 10:22:06 A.M. EDT Michal Privoznik wrote:
> > On 4/20/20 3:54 PM, Mark Asselstine wrote:
> > > No problem. Thanks for taking the patches and making the necessary
> > > tweak
On Monday, April 20, 2020 10:22:06 A.M. EDT Michal Privoznik wrote:
> On 4/20/20 3:54 PM, Mark Asselstine wrote:
> > No problem. Thanks for taking the patches and making the necessary tweaks.
>
> In return, I've just posted a follow up patches that remove the device
> on
On Monday, April 20, 2020 9:30:56 A.M. EDT Michal Privoznik wrote:
> On 4/20/20 3:09 PM, Mark Asselstine wrote:
> > On Monday, April 20, 2020 6:11:25 A.M. EDT Michal Privoznik wrote:
> >> On 4/16/20 5:57 PM, Mark Asselstine wrote:
> >>> The udev monitor thread &quo
On Monday, April 20, 2020 6:11:25 A.M. EDT Michal Privoznik wrote:
> On 4/16/20 5:57 PM, Mark Asselstine wrote:
> > The udev monitor thread "udevEventHandleThread()" will lag the
> > actual/real view of devices in sysfs as it serially processes udev
> > monitor even
On Saturday, April 18, 2020 9:25:57 A.M. EDT Martin Kletzander wrote:
> On Thu, Apr 16, 2020 at 11:57:45AM -0400, Mark Asselstine wrote:
> >It is possible and common to rename some devices, this is especially
> >true for ethernet devices such as veth pairs.
> >
> >In the
no link info. In the case
described above we will eventually get the link info as we work
through the queue of monitor events and get to the 'move' event.
https://bugzilla.redhat.com/show_bug.cgi?id=1557902
Signed-off-by: Mark Asselstine
---
src/util/virnetdev.c | 11 +++
1 fil
a device such as above results in a "move" event, not
a "remove" followed by and "add" or vise versa. This change will add
the new/destination device to our records but unfortunately there is
no usable mechanism to identify the old/source device to remove it
from the records. So
On Tuesday, September 25, 2018 5:20:26 AM EDT Michal Privoznik wrote:
> On 09/24/2018 05:11 PM, Mark Asselstine wrote:
> > A deadlock situation can occur when autostarting a LXC domain 'guest'
> > due to two threads attempting to take opposing locks while holding
> > opposing
lock. The remaining work that takes place between the
old call location of virNetClientSetCloseCallback() and the new
location is unaffected by the move.
Signed-off-by: Mark Asselstine
---
NOTE I am not intimately familiar with the libvirt code, so although I
am confident of the cause of the issue I am not sure this is the
