[ovirt-devel] Re: Suspend resume and DHCP
On Thu, Apr 4, 2019 at 9:02 AM Dan Kenigsberg <danken(a)redhat.com> wrote:
On Wed, Apr 3, 2019 at 5:55 PM Dominik Holler <dholler(a)redhat.com> wrote:
>
> Hello,
> would you help me to understand if the dhcp client in an oVirt guest
> should refresh his dhcp configuration after the guest is resumed?
> If this is the case, how this should be triggered?
>
> The reason why I ask is, that if a VM suspends on a first host, and
> resumes on a second one, libvirt's nwfilter losses the IP address of
> the guest, which means that the guest is not reachable until he
> refreshes dhcp config, if the clean-traffic filter with
> CTRL_IP_LEARNING=dhcp is used.
Do you know if libvirt's nwfilter transfers the IP address during live
migration? I'd suspect that you'd have the same problem there.
I believe that libvirt should handle this in BOTH cases (live
migration and suspend/resume). It should store the learned IP in the
suspended data and revive it on the target host.
Not my expertise, but regardless of the below :-), I agree with you.
Calling in +Laine Stump for his opinion.
Regardless of this, I think that a guest should request a dhcp renewal
upon resume. After all, it may have been suspended for few years.
I think most, if not all, dhcp clients, would renew, once they
realized that time passed by (which is a non-trivial, but different,
issue), if their lease expired. I think Dominik's question was
about the case that the lease was _not_ expired.
This can be done if we add a "resumed" notification to the
guest
agent, and have libvvirt/Vdsm trigger after resume.
That's also just fine for me. I very briefly looked at all relevant
agents (ovirt, spice, qemu) and didn't find 'dhcp' in any of them.
So I agree it makes sense to file an RFE on one of them for this.
However, we can't always rely on this - the agent might not be
available, etc.
> This scenario might happen in OST basic-suite-master and
> basic-suite-4.3 in verify_suspend_resume_vm0.
I suspect that we can work around this bug in OST by requesting Engine
to resume vm0 on the same host it was suspended from
And also, for this very specific use case, to simply have much
shorter leases. It seems like we currently use dnsmasq's default,
which is one hour. I guess setting it to even 2 minutes won't do
much damage, but of course this needs testing.
Best regards,
--
Didi