Bug 1955195

I'm not sure that based on bug 1945532 implementing support for 'yank' is justified.

Firstly this bug doesn't mention it but the connection get's stuck when 'blockdev-del'-ing the NBD connections used for non-shared-storage migration. This also needs to be investigated by the qemu team, since the closing handshake of NBD isn't very useful and creates a pointless failure scenario.

Secondly it's important to mention that the bug occurs with a non-standard topology, where the NBD and migration connections are proxied via a third-party tool which can have influence on the behaviour.

Thirdly libvirt added the support for migration using UNIX sockets so that it can be proxied specifically to use in Kubevirt, thus kubevirt should start using it before we spend time on something which might not be needed later on.

As of such I don't think we should invest into implementing this until:

1) qemu decides that the NBD connection behaviour is okay from their point of view
2) Kubevirt investigates that their proxy isn't the main problem here and try the migration with unix sockets which may have better error handling.

(In reply to Peter Krempa from comment #1)
> I'm not sure that based on bug 1945532 implementing support for 'yank' is
> justified.
> 
> Firstly this bug doesn't mention it but the connection get's stuck when
> 'blockdev-del'-ing the NBD connections used for non-shared-storage
> migration. This also needs to be investigated by the qemu team, since the
> closing handshake of NBD isn't very useful and creates a pointless failure
> scenario.

Can you chime into the bug conversation and mention it please?

> 
> Secondly it's important to mention that the bug occurs with a non-standard
> topology, where the NBD and migration connections are proxied via a
> third-party tool which can have influence on the behaviour.

Agreed, but regardless - connection disruption can happen for whatever reason and it may take quite a long time until TCP realizes that. Wouldn't 'yank' help in such situation?

> 
> Thirdly libvirt added the support for migration using UNIX sockets so that
> it can be proxied specifically to use in Kubevirt, thus kubevirt should
> start using it before we spend time on something which might not be needed
> later on.

IIUC their proxy consists of two parts: one that's redirecting TCP onto UNIX socket and vice verca and the other that's passing data between these UNIX sockets. My hunch is that it's the latter that's disrupting the migration (because otherwise QEMU would see TCP FIN packet) and given that, while taking away another moving part is generally good it may not help. Anyway - this is discussion we should be having on that bug.

> 
> As of such I don't think we should invest into implementing this until:
> 
> 1) qemu decides that the NBD connection behaviour is okay from their point
> of view
> 2) Kubevirt investigates that their proxy isn't the main problem here and
> try the migration with unix sockets which may have better error handling.

I still think that it beneficial for libvirt to implement this command even if it doesn't fix the Kubevirt bug.

I think there are two parts of this:

1) yank could be used unconditionally to abort migration block jobs in case
we're aborting the whole migration as it makes little sense trying to finish
them nicely. This should make the probability of getting stuck in QMP a bit
lower.

2) virDomainAbortJob could get a new flag to forcefully abort the migration
using yank instead of migrate_cancel.

Both part need the yank command to be supported by QEMU, of course. And in
addition to that at least the second part would need support for out-of-band
QMP commands (OOB) in libvirt. The first part might be possible even without
OOB, but I don't know for sure. In other words, while 1) might be quite
simple, 2) will most likely be not simple at all.

I suspect getting the use of 'yank' right needs some care to make sure we don't kill any connections we want to keep around,
and to make sure the qmp is always free to issue a yank.

@vromanso how important is this for us? Please adjust severity

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.