On Thu, Sep 8, 2016 at 2:46 AM, Laine Stump <laine(a)laine.org> wrote:
On 09/07/2016 05:57 AM, Amador Pahim wrote:
>
> On Wed, Sep 7, 2016 at 11:41 AM, Daniel P. Berrange <berrange(a)redhat.com>
> wrote:
>>
>> On Wed, Sep 07, 2016 at 11:18:58AM +0200, Amador Pahim wrote:
>>>
>>> The <drive>DomainInterfaceAddresses, when using the source type
>>> LEASE, does not need the domain to be running. It only checks the
>>> dhcp lease file and gets the address information from a valid lease,
>>> if any.
>>>
>>> This patch removes the virDomainObjIsActive(vm) check from the LEASE
>>> query type on both qemu and lxc drivers, keeping it only for query
>>> type AGENT on qemu driver (since lxc does not support AGENT type).
>>
>> I don't think we should do this. IMHO it only makes sense to ask for
>> the IP address when the guest is actually running. The fact that we
>> might still happen to have an old IP address stored in the lease
>> file is merely a happy accident and not something we should guarantee
>> by exposing ability to get it in the API.
>
> The fact that the guest is running does not mean the lease information is
> accurate. Guest IP can be manually changed. IP can be allocated by
> someone else between the true virDomainObjIsActive(vm) and the actual
> DHCPACK. We don't guarantee the information in any case, unless you
> change the query type to AGENT. One can parse the lease file by itself
> (and check if the lease is not expired), it's cheaper than create(), query
> the lease addresses, destroy(). This patch tries to avoid both.
(A short explanation of your use case might help us to understand why you
would want to learn the former IP address of a non-running guest.)
When the guest is running, of course the information in the lease file might
be incorrect, but that would most likely be caused by a malicious or
malfunctioning guest. In general though, the lease information probably is
correct, and the IP address you get back could be used to contact the guest
(from the host, at least, and assuming necessary ports were open in guest
and host firewalls, and that the guest was listening on the appropriate
port).
If the guest *isn't* running though, then by definition the lease
information is incorrect - you definitely aren't going to be able to reach
the guest via that address, so it's a bit misleading for libvirt to suggest
it.
Ok, thank you both for the feedback.