You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Gary Dixon <Ga...@quadris.co.uk.INVALID> on 2023/01/09 17:24:12 UTC
RVR not leasing DHCP IPv4 address
Hi all
Hypervisor: KVM
CS : 4.15.2
Came across an issue today with RVR's in a VPC very similar to this issue : https://issues.apache.org/jira/browse/CLOUDSTACK-6665
If we destroy a VM and expunge - on the RVR Master router if we run 'arp' command we still see its MAC to IP entry. We then run scripts/API calls to re-provision the VM from a template using the same static IP. The VM boots but then gets an APIPA 169.254.x.x IP address in the guest OS (Windows server2022)
On the RVR in the dnsmasq.log we see:
Jan 9 15:12:59 dnsmasq-dhcp[3588]: not using configured address 10.200.0.62 because it is leased to 02:00:48:d7:00:35
Jan 9 15:12:59 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38 no address available
Jan 9 15:13:03 dnsmasq-dhcp[3588]: not using configured address 10.200.0.62 because it is leased to 02:00:48:d7:00:35
Jan 9 15:13:03 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38 no address available
Jan 9 15:13:08 dnsmasq-dhcp[3588]: not using configured address 10.200.0.62 because it is leased to 02:00:48:d7:00:35
Jan 9 15:13:08 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38 no address available
If we restart the dnsmaq service on the RVR then the VM is able to lease its 'statis' IP
Strangely we don't see this behaviour on a different VPC with RVR's
Any ideas ?
BR
Gary
Gary Dixon
Senior Technical Consultant
T: +44 161 537 4990
E: vms@quadris-support.com
W: www.quadris.co.uk
The information contained in this e-mail from Quadris may be confidential and privileged for the private use of the named recipient. The contents of this e-mail may not necessarily represent the official views of Quadris. If you have received this information in error you must not copy, distribute or take any action or reliance on its contents. Please destroy any hard copies and delete this message.
Re: RVR not leasing DHCP IPv4 address
Posted by Wei ZHOU <us...@gmail.com>.
Hi Gary,
It seems to be a bug. Can you create a github issue ?
-Wei
On Mon, 9 Jan 2023 at 18:24, Gary Dixon <Ga...@quadris.co.uk.invalid>
wrote:
> Hi all
>
>
>
> Hypervisor: KVM
>
> CS : 4.15.2
>
>
>
> Came across an issue today with RVR’s in a VPC very similar to this issue
> : https://issues.apache.org/jira/browse/CLOUDSTACK-6665
>
>
>
> If we destroy a VM and expunge – on the RVR Master router if we run ‘arp’
> command we still see its MAC to IP entry. We then run scripts/API calls to
> re-provision the VM from a template using the same static IP. The VM boots
> but then gets an APIPA 169.254.x.x IP address in the guest OS (Windows
> server2022)
>
> On the RVR in the dnsmasq.log we see:
>
> Jan 9 15:12:59 dnsmasq-dhcp[3588]: not using configured address
> 10.200.0.62 because it is leased to 02:00:48:d7:00:35
>
> Jan 9 15:12:59 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38
> no address available
>
> Jan 9 15:13:03 dnsmasq-dhcp[3588]: not using configured address
> 10.200.0.62 because it is leased to 02:00:48:d7:00:35
>
> Jan 9 15:13:03 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38
> no address available
>
> Jan 9 15:13:08 dnsmasq-dhcp[3588]: not using configured address
> 10.200.0.62 because it is leased to 02:00:48:d7:00:35
>
> Jan 9 15:13:08 dnsmasq-dhcp[3588]: DHCPDISCOVER(eth3) 02:00:6c:a3:00:38
> no address available
>
>
>
> If we restart the dnsmaq service on the RVR then the VM is able to lease
> its ‘statis’ IP
>
>
>
> Strangely we don’t see this behaviour on a different VPC with RVR’s
>
> Any ideas ?
>
>
>
> BR
>
>
>
> Gary
>
>
> Gary Dixon
> Senior Technical Consultant
> T: +44 161 537 4990
> E: *v* <+44%207989717661>ms@quadris‑support.com
> W: www.quadris.co.uk
> The information contained in this e-mail from Quadris may be confidential
> and privileged for the private use of the named recipient. The contents of
> this e-mail may not necessarily represent the official views of Quadris.
> If you have received this information in error you must not copy,
> distribute or take any action or reliance on its contents. Please destroy
> any hard copies and delete this message.
>