https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# harvester
a
This message was deleted.
šŸ‘ 1
šŸ‘€ 1
w
here is my pool configs
Untitled
h
@red-king-19196 may know if this is possible today. Please create a GitHub issue and let us know the number here. If this is not possible and you are a Prime member, it would take priority in our Roadmap. Having said that, how do you want to tell the new VM to get the pre-allocated IP from the dhcp pool? Preserving the VM name or the MAC?
w
@happy-cat-90847 ā€” hereā€™s my current thought process: For the first use case, my approach would be: When a VM is initially created, it receives an IP from the DHCP pool, and we persist the MAC ā†”ļø IP mapping If the VM is deleted and later redeployed, we: ā€¢ Reuse the same MAC address (since we can specify it during VM creation in the UI) ā€¢ Ensure the DHCP reservation remains tied to that MAC This way, DHCP treats it as the same client and assigns the same IP as before. However, I also have a second use case where certain applications use a VIP internally (not tied to any VM NIC). In this case: ā€¢ The IP still needs to come from the same DHCP pool or need ip from the same vm network pool. ā€¢ But it wonā€™t be requested via DHCP (no MAC/client associated) Iā€™m not sure what the recommended approach is to handle this scenario within the current model. Would appreciate any guidance. These are my thoughts ATM
r
Hi @witty-musician-14961. Thanks for being around with us. If I recall correctly, VirtualMachineNetworkConfig (vmnetcfg) is a child resource of VirtualMachine. The vmnetcfg resource will be purged in a cascading manner if the VM is deleted. The vmnetcfg resources are basically DHCP leases. What you want to achieve looks like static leases to me. This could be done if you create the vmnetcfg beforehand. But currently, there is no nice UI around it. The only way is to interact with the API directly, i.e., kubectl. You can give it a try.
w
@red-king-19196 do you have sample/example config, by referring to that i can try on my env. Most of my users prefer CLI/API way as they use IaC so UI is not a mandatory requirements atleast for our use case.
r
If you create a VM, there will be a vmnetcfg resource created by the VM DHCP controller. You can copy the vmnetcfg or take it as an example.
Let me check if I can find an example.
Copy code
apiVersion: <http://network.harvesterhci.io/v1alpha1|network.harvesterhci.io/v1alpha1>
kind: VirtualMachineNetworkConfig
metadata:
  labels:
    <http://harvesterhci.io/vmName|harvesterhci.io/vmName>: <vm-name>
  name: <name>
  namespace: <namespace>
spec:
  networkConfig:
  - macAddress: <mac-address>
    networkName: <network-namespaced-name>
  vmName: <vm-name>
šŸ™Œ 1
Just pre-create the vmnetcfg resource from the above template, the VM should be able to get the desired IP through DHCP after it boots up.
w
ok so i would need to know the MAC address before the VM created?
h
@witty-musician-14961 if you find this to work - and you need the rancher provisioning to reuse it, we may need to update the ticket.
r
It depends on your use case. If you already know the MAC address and want to book the IP address for the VM, pre-create the vmnetcfg resource is the way.
If you want to preserve the IP address for a specific VM, even after itā€™s deleted, Iā€™d imagine youā€™ll need to keep the vmnetcfg resource by removing the OwnerReference.
I know these look kind of hack-ish. We do have plans to extend VM DHCP controllerā€™s capability to cover more use cases.
w
Got it ā€” so for pre-creating 
vmnetcfg
, the MAC needs to be known beforehand since DHCP mapping is MAC-based. Just to confirm, is there any supported way to: ā€¢ Create a VM, have it obtain an IP dynamically from DHCP, and then ā€œlock inā€ or persist that IP assignment afterward (without needing to predefine MAC or vmnetcfg upfront)? Also, I still have a second related use case: Some applications require a VIP that exists inside the application layer, not tied to any VM NIC. In this case: ā€¢ The IP still needs to come from the same DHCP pool ā€¢ But it is not associated with a VM interface or MAC address ā€¢ It behaves more like a logical/virtual IP owned by the application itself
r
For the VIP use case, itā€™s not covered in our original user stories. So itā€™s unsupported at the moment. I saw you already created a GH issue. Thatā€™s great. We can look into it.
šŸ™Œ 1
w
as a workaround for now do you recommend to keep appending exclude list of ip in the pool configs?
r
The VIP one looks more like a generic DHCP use case.
as a workaround for now do you recommend to keep appending exclude list of ip in the pool configs?
which use cases are you referring to?
w
VIP use case
r
Actually, I am unsure about that part because I never tested it. But I find it interesting and want to know more about it. The VIP must be assigned to some interfaces in the VM, right?
BTW
Create a VM, have it obtain an IP dynamically from DHCP, and then ā€œlock inā€ or persist that IP assignment afterward (without needing to predefine MAC or vmnetcfg upfront)?
Try removing the 
OwnerReference
part from the vmnetcfg. Itā€™s similar to ā€œlock inā€ a DHCP lease.
An auto-generated vmnetcfg resource looks like the following:
Copy code
$ kubectl get virtualmachinenetworkconfigs.network test-vm -o yaml
apiVersion: network.harvesterhci.io/v1alpha1
kind: VirtualMachineNetworkConfig
metadata:
  creationTimestamp: "2024-02-15T13:48:02Z"
  finalizers:
  - wrangler.cattle.io/vm-dhcp-vmnetcfg-controller
  generation: 2
  labels:
    harvesterhci.io/vmName: test-vm
  name: test-vm
  namespace: default
  ownerReferences:
  - apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    name: test-vm
    uid: a9f8ce12-fd6c-4bd2-b266-245d8e77dae3
  resourceVersion: "826809"
  uid: 556440c7-eeeb-4daf-9c98-60ab39688ba8
spec:
  networkConfig:
  - macAddress: ca:70:82:e6:84:6e
    networkName: default/net-48
  vmName: test-vm
status:
  conditions:
  - lastUpdateTime: "2024-02-15T13:48:20Z"
    status: "True"
    type: Allocated
  - lastUpdateTime: "2024-02-15T13:48:02Z"
    status: "False"
    type: Disabled
  networkConfig:
  - allocatedIPAddress: 192.168.48.84
    macAddress: ca:70:82:e6:84:6e
    networkName: default/net-48
    state: Allocated
Remove the following from the above makes it an orphan resource so it wonā€™t be GCā€™d
Copy code
ownerReferences:
  - apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    name: test-vm
    uid: a9f8ce12-fd6c-4bd2-b266-245d8e77dae3
šŸ‘ 1
w
The VIP must be assigned to some interfaces in the VM, right?
Not always. In some implementations (like HA/VRRP setups), a VIP is assigned to a VM interface and temporarily exists on that active nodeā€™s NIC. However, in other architectures such as load balancers or service-based systems, the VIP is not bound to any VM interface at all and is handled at a higher abstraction layer. So a VIP does not inherently need to be tied to a VM interfaceā€”it depends on the design and implementation.
i will test above shared steps and update here
r
Got your point. Iā€™d say this is somewhat out of scope for the VM DHCP controller. And youā€™re right, marking them as excluded from the IPPool and maybe setting up an additional DHCP server on the subnet should be the way to go.
w
That's application(solarwinds) one of our teams trying to deploy in VM
h
I think you can do this with the kube-vip and just use a static IP for the LoadBalancer resource
Which is probably better. This is consumed on a Kubernetes cluster right?
w
I don't know if that app supports using LB outside the application(solarwinds)
Solution that is offered by solarwinds tool is VM based solution. App team will deploy two VMs and setup ha vip inside the application itself
As per the requirements of that application ha vip and the VM ips should be in same subnet for the ease of failover and operations/maintenance.
r
So the VIP does not need to be assigned by a DHCP server?
Just seeing this > Is there a way to let end users (namespace owners) reserve or manage specific IPs for their use casesā€”without giving them direct access to the DHCP pool configuration itself? Another idea is to let them create ā€œdummyā€ vmnetcfg resources to occupy seats in the pool.
w
So the VIP does not need to be assigned by a DHCP server?
Yes, thatā€™s correct ā€” in our case both VM IPs and VIPs must come from the same subnet/network pool. Thatā€™s exactly why Iā€™m trying to understand the right mechanism here. If VIPs are taken from the same DHCP-managed pool, then DHCP still needs to be aware of those IPs somehow to prevent reallocation. From what I understand so far, DHCP only protects IPs it explicitly knows about (via MAC/vmnetcfg reservation or pool exclusion). So Iā€™m trying to confirm whether VIPs are expected to also be represented as some form of reservation object (like vmnetcfg without a real VM), or if there is another supported pattern for this within the current design.
r
This is exactly what the 
exclude
field is for.
w
@red-king-19196 just to update i have tested removing ownerref method it worked. here is the flow i followed
Copy code
Deploy VM 
ā†“
VM boots, gets a random IP (e.g. 192.168.48.84) by DHCP, auto MAC assigned 
ā†“
Controller auto-creates vmnetcfg with that MAC + IP
ā†“
I have recorded the MAC and IP and remove owneref
kubectl patch vmnetcfg to remove ownerRef  ā† the "lock in" step
ā†“
Delete VM ā†’ vmnetcfg SURVIVES (no ownerRef, GC ignored it)
IP stays reserved in the dhcp pool
ā†“
Redeploy VM with the same MAC hardcoded in spec with same VM name
ā†’ same IP every time
šŸ‘ 2
This is exactly what the 
exclude
field is for.
question - if add any thing in 
exclude
list of ip pool , to take that into effect do i need to restart dhcp agent pod every time i modify pool configs? if so by restarting will it causes any issues.
r
no, ip allocation happens on the control plane. any ippool changes will be reconciled by the controller manager, no agent activities involved, thus you don't need to restart the agent.
šŸ™Œ 1
a
My only complaints about this dhcp-vm-extension are: 1. Never appears in the UI 2. Immutable configs. Therefore if a user wants to shrink or expand a DHCP range or exclude IPsā€¦.you cannot do this without deleting the manifest and adding it back. Oh and that cannot be done with active VMs using the network.
Other than thisā€¦works like a champ on v1.7.1 after getting through the upgrade headaches.
w
@acceptable-analyst-61974 thank you for sharing your experience, point 2 is interesting. In this case it is going to be challenging in my case when I want to add an ip to exclude list. I already have some of VMs using dhcp pool. @red-king-19196 do you know of any workarounds?
šŸ‘ 1
a
It is pretty standard networking option for just about every other dhcp service. Hopefully it's a feature that gets added soon so we are not having to delete and recreate bc it is immutable.
18 Views
Open in Slack
PreviousNext
Powered by