enable static IP -> capsul mapping via libvirt (manage MAC addresses)

j3s commented

2021-09-18 07:39:25 +00:00

Owner

this is what i was talking about last night in terms of dynamically updating the net config: https://listman.redhat.com/archives/libvir-list/2012-September/msg01380.html

looks like the order could be:

create vm definition, (this would include the mac address that we assign to their network interface.)
find a subnet with free IP space
find an unused IP address
update the appropriate netconfig dynamically by assigning an unused IP to that mac address
when shutting down, we'd sort of do the opposite. the source of truth could be the network config (which is accessible via API) since it dictates which IPs are supposed to be "in use".

We would also need to implement a cronjob that backs up the network configs, easy enuff.

then users could stop their VMs indefinitely, and there wouldn't be any worries about IPs being released. then we could just charge for the IP and disk, but not the RAM or CPU.

this is what i was talking about last night in terms of dynamically updating the net config: https://listman.redhat.com/archives/libvir-list/2012-September/msg01380.html looks like the order could be: create vm definition, (this would include the mac address that we assign to their network interface.) find a subnet with free IP space find an unused IP address update the appropriate netconfig dynamically by assigning an unused IP to that mac address when shutting down, we'd sort of do the opposite. the source of truth could be the network config (which is accessible via API) since it dictates which IPs are supposed to be "in use". We would also need to implement a cronjob that backs up the network configs, easy enuff. then users could stop their VMs indefinitely, and there wouldn't be any worries about IPs being released. then we could just charge for the IP and disk, but not the RAM or CPU.

j3s commented

2021-09-18 07:39:34 +00:00

Author

Owner

~j3s4 months ago · edit
This mapping is still enabled and must be turned off. Mapping should only be enable for maintenance events.

~j3s closed duplicate ticket #714 months ago
~foresta month ago · edit
BUMP this is high priority to mitigate future capsul outages & hopefully get back up and running sooner

~forest referenced this from #89

~j3s4 months ago · edit This mapping is still enabled and must be turned off. Mapping should only be enable for maintenance events. ~j3s closed duplicate ticket #714 months ago ~foresta month ago · edit BUMP this is high priority to mitigate future capsul outages & hopefully get back up and running sooner ~forest referenced this from #89

forest commented

2021-12-15 17:13:08 +00:00

Owner

I think we just need to update the start method that the users have access to to do the same thing as the admin panel one and then this can be closed.

forest commented

2021-12-16 15:48:57 +00:00

Owner

capsul-flask should probably take ownership of mac addresses and tell each capsul what its mac address is, if possible.
- To make the DHCP config declarative so we can rebuild the whole config any time it changes
- instead of imperatively updating it 1 vm at a time

Networking Configuration

.
--network=NETWORK,opt1=val1,opt2=val2
...
Other available options are:
....

mac

Fixed MAC address for the guest; If this parameter is omitted, or the value "RANDOM" is specified a suitable address will be randomly generated. For Xen virtual machines it is required that the first 3 pairs in the MAC address be the sequence '00:16:3e', while for QEMU or KVM virtual machines it must be '52:54:00'.

looks like it should be easy to specify the mac before the VM exists 👍️

I started working on this on the manage-mac branch but didn't get far, I think this is slightly lower priority than all the other outage mitigation tasks now that the admin panel exists.

- capsul-flask should probably take ownership of mac addresses and tell each capsul what its mac address is, if possible. - To make the DHCP config declarative so we can rebuild the whole config any time it changes - instead of imperatively updating it 1 vm at a time > ## Networking Configuration > > . > --network=NETWORK,opt1=val1,opt2=val2 > ... > Other available options are: > .... > ### mac > > Fixed MAC address for the guest; If this parameter is omitted, or the value "RANDOM" is specified a suitable address will be randomly generated. For Xen virtual machines it is required that the first 3 pairs in the MAC address be the sequence '00:16:3e', while for QEMU or KVM virtual machines it must be '52:54:00'. looks like it should be easy to specify the mac before the VM exists 👍️ I started working on this on the `manage-mac` branch but didn't get far, I think this is slightly lower priority than all the other outage mitigation tasks now that the admin panel exists.

forest changed title from ~~enable static IP -> capsul mapping via libvirt~~ to enable static IP -> capsul mapping via libvirt (manage MAC addresses)

2021-12-16 15:49:29 +00:00

forest commented

2021-12-17 23:35:42 +00:00

Owner

This is also needed so I can implement

capsul-flask admin panel start/stop dhcp fixing logic should be ported to the start/stop that the users have access to as well

properly...

Right now the mac address(es) are not stored in the DB. So that above task is blocked until we get mac managed by capsul-flask.

This is also needed so I can implement > capsul-flask admin panel start/stop dhcp fixing logic should be ported to the start/stop that the users have access to as well properly... Right now the mac address(es) are not stored in the DB. So that above task is blocked until we get mac managed by capsul-flask.

enable static IP -> capsul mapping via libvirt (manage MAC addresses) #11

Networking Configuration

mac