/dev/tap devices created on physical host rather than container when running in kind about macvtap-cni HOT 19 CLOSED

I have a workaround,
create your cluster and nodes in cluster.yml with /dev mounted on /dev on the kind host:
Minimal example:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraMounts:
  - hostPath: /dev
    containerPath: /dev
    propagation: HostToContainer

Encountered this myself as well, hopes this helps.

from macvtap-cni.

In trying to dig into it more, it looks like it might be related to devtmpfs not being namespace aware: https://www.redhat.com/archives/libvir-list/2018-July/msg00325.html, not sure if things have changed since then.

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

from macvtap-cni.

/remove-lifecycle rotten

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

/remove-lifecycle stale

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

/remove-lifecycle stale

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

/remove-lifecycle stale

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

/remove-lifecycle stale

from macvtap-cni.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from macvtap-cni.

I think this workaround makes sense, since kind clusters are not meant to run production workloads.

Thanks for reporting it @aviv000 !

from macvtap-cni.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

from macvtap-cni.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

from macvtap-cni.

@kubevirt-bot: Closing this issue.

from macvtap-cni.

whoops.

Closing since the workaround provided in #39 (comment) is good enough.

from macvtap-cni.