Re: RFC: Implement virDomainGetIPAddress()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[snip]
>> Wait a minute there please. The MAC address should be unique in the
>> system so user should be using just one IP address per one MAC address.
>> Since MAC address should be unique in the system then the IP address
>> assigned to this MAC address should be just one, shouldn't it ?
> You can easily add multiple IP address to an interface (and therefore
> to the same MAC address)
>
> ip addr add 192.168.0.17 dev eth0
> ip addr add 192.168.0.42 dev eth0

In this case, yes. Like I said, I didn't consider that option nor it
didn't come to my mind at all since I'm not familiar with networking too
much for the cases I never used.

>> Nevertheless I think you know more about networking options than I do so
> Well, I know that there is no strict 1:1 mapping between MAC and IP
> addresses and I want that this fact is consider in the discussion here
> and we don't add a new API that turns out to be too simple/restricted
> in the end. Whether we really want/need to cover this case is a
> different question.

I can see the point and I think it's always good to discuss the
possibilities that arise in the process.

>> when I consider the scenario you wrote me about I don't like the idea of
>> leaving the parsing to the caller and for the scenario of multiple IP
>> addresses in the return value I recommend a new prototype:
>>
>> char **virDomainGetIPAddress(virDomainPtr domain, char *devmac, unsigned int *count, unsigned int flags);
>>
>>
>> where count will be the output parameter with the number of elements in
>> the return value. It should be used like:
>>
>> virDomainPtr domain = ...;
>> char *macaddr = "11:22:33:44:55:66";
>> char **ips = NULL;
>> int count = -1;
>>
>> ips = virDomainGetIPAddress(domain, macaddr, &count, 0);
>>
>> for (i = 0; i < count; i++) {
>>  ... ips[i] ...
>>  ... free(ips[i]) ...
>> }
>>
>>
>> The return value allocation should be done by the function itself and
>> the called should free the result (ips in this case).
> That's a possible way to deal with this, yes.
>
> And now lets spin this a bit further and consider IPv6 addresses.
>
> ipv4s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV4);
> ipv6s = virDomainGetIPAddress(domain, macaddr, &count, VIR_DOMAIN_ADDRESS_IPV6);
>
> This are the simple cases where the caller explicitly requests only
> one version and knows the version of the returned IP addresses. But
> what about this
>
> ips = virDomainGetIPAddress(domain, macaddr, &count,
> VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6);

For this the virSocketAddr representation would be better, right.
However my scenario didn't count with the option of definiting

VIR_DOMAIN_ADDRESS_IPV4 | VIR_DOMAIN_ADDRESS_IPV6

together.

Michal

-- 
Michal Novotny <minovotn@xxxxxxxxxx>, RHCE, Red Hat
Virtualization | libvirt-php bindings | php-virt-control.org

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]