docs, network-binding-plugin: Document migration support #11870
Conversation
kubevirt-bot
added
release-note-none
docs/network-binding-plugin.md
Outdated
| section on how to define it. | ||
| - The backend `libvirt` and `qemu` needs to support migration for the specific | ||
| device that is used in the domain. | ||
| - The `hostdevice` devices in the domain do not support migration out-of-the-box. |
There was a problem hiding this comment.
I think this limitation is related to devices that use vfio driver, isn't it right?
nit:
| - The `hostdevice` devices in the domain do not support migration out-of-the-box. | |
| - The `hostdevice` devices in the domain doesn't support migration out-of-the-box. |
There was a problem hiding this comment.
devices are plural so I think do is the correct form.
docs/network-binding-plugin.md
Outdated
| Kubevirt. The special handling is currently implemented for core SR-IOV | ||
| binding by unplugging the device at the source before migration is started | ||
| and plugging it back at the destination after the migration completed. |
There was a problem hiding this comment.
I would present the core SR-IOV binding as an example, something along these lines:
| Kubevirt. The special handling is currently implemented for core SR-IOV | |
| binding by unplugging the device at the source before migration is started | |
| and plugging it back at the destination after the migration completed. | |
| Kubevirt. | |
| For example, Kubevirt core [SR-IOV binding](https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/#sriov) implements migration support | |
| by unplugging the device at the source before migration is started | |
| and plugging it back at the destination after the migration completed. |
There was a problem hiding this comment.
This will be incorrect.
We do not have support for hostdevice devices through the plugin infrastructure.
The SR-IOV binding is not an example of a plugin binding.
I used it to express what is needed to support something like this and explicitly mentioned we do not yet have support for it in the plugins.
There was a problem hiding this comment.
The current state is not clear enough, one might think the unplug/plug can be used for any binding plugin
I suggested to refer to how kubevirt core sr-iov binding does the "special handling" for migration(the uplug/plug thing), not to say its an example for a plugin or plugin support host devices.
There was a problem hiding this comment.
The current state is not clear enough, one might think the unplug/plug can be used for any binding plugin
I do not understand how hotplug got involved here.
The text here is about migration and in the specific section about the limitations hostdevices have.
It explicitly says hostdevices are not supported at the moment.
I suggested to refer to how kubevirt core sr-iov binding does the "special handling" for migration(the uplug/plug thing), not to say its an example for a plugin or plugin support host devices.
It explains how hostdevices are treated by the SR-IOV binding to express the challenge.
I see no point in ref to that binding because it says nothing on how it works internally. That is a user-guide document, it does not enter into such details.
Maybe you should point me to the sentence that is problematic in your opinion here and how one can interpret it wrongly.
There was a problem hiding this comment.
I do not understand how hotplug got involved here. The text here is about migration and in the specific section about the limitations hostdevices have.
The unplug/plug core SR-IOV binding does on migration, this PR also mentions.
Maybe you should point me to the sentence that is problematic in your opinion here and how one can interpret it wrongly.
Its about the phrasing, to me the "The special handling is currently implemented.." part sound as it can be used for binding plugin.
Anyhow, I am not insisting on it.
There was a problem hiding this comment.
I rephrased, please take another look.
|
/lgtm |
EdDev
force-pushed
the
docs-net-binding-plugin-migration
branch
from
df03d57
to
0d48a65
Compare
|
Thanks, it looks better |
kubevirt-bot
added
lgtm
Signed-off-by: Edward Haas <edwardh@redhat.com>
EdDev
force-pushed
the
docs-net-binding-plugin-migration
branch
from
0d48a65
to
9591437
Compare
kubevirt-bot
added
sig/network
and removed
lgtm
|
change: Rebase |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: EdDev The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubevirt-bot
added
the
approved
|
Required labels detected, running phase 2 presubmits: |
What this PR does
Document the migrations support details in the network binding plugin developer-guide.
Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.
Release note