On Thu, Apr 4, 2019 at 9:02 AM Dan Kenigsberg <danken@redhat.com> wrote:
On Wed, Apr 3, 2019 at 5:55 PM Dominik Holler <dholler@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