Goal

Today NAT-ing bindings (like masquerade) need to be used with the pod network in case that live migration needs to be used. The drawback of NAT-ted bindings so far is, that the VM is getting a "private" ip, which is not visible outside the VM (and pod). This epic is about implementing a mechanism to give a VM an IP on the pod network connected vNIC that is the same internally and externally. The suggested method for that is to bind VM a ClusterIP of a Service.

User Stories

• As a VM owner,
  I want my VM with an IP on the pod network that is the same internally and externally,
  so that the tools I am using inside the VM see the same IP that other cluster participants see - this is important i.e. for kubeadm.
• As a developer,
  I want to have a VM with a stable IP on the network,
  so that after a live migraiton I can still reach the VM using the same IP.

Non-Requirements

• List of things not included in this epic, to alleviate any doubt raised during the grooming process.

Notes

The approach that is being investigated is to assign VM to a Service. ClusterIP of the service can be then used to access the VM. To ensure that VM sees the same IP internally, we use this ClusterIP as the link-local IP for the masquerade binding (this has a complication where we need to reserve two Service IPs, one for masquerade gateway and one for the guest). Finally, we will need to make sure that outgoing traffic has this public Service IP set as the source, that can be done on the NAT.

• Option (c) in https://docs.google.com/document/d/10qxExvWgYqh5ig9rwkcvQsyok1TIYWx4vcXA_U-0Ib8/edit#bookmark=id.zdryfeqfavzw
• Spike: https://issues.redhat.com/browse/CNV-5471

Owners

Done Checklist