[libvirt] [PATCH v6] npiv: Auto-generate WWN if it's not specified

Osier Yang jyang at redhat.com
Thu Feb 9 04:53:53 UTC 2012


On 2012年02月07日 22:03, Osier Yang wrote:
> On 2012年02月07日 21:29, Eric Blake wrote:
>> On 02/07/2012 06:38 AM, Osier Yang wrote:
>>> The auto-generated WWN comply with the new addressing schema of WWN:
>>>
>>> <quote>
>>> the first nibble is either hex 5 or 6 followed by a 3-byte vendor
>>> identifier and 36 bits for a vendor-specified serial number.
>>> </quote>
>>>
>>> We choose hex 5 for the first nibble. And for the 3-bytes vendor ID,
>>> we uses the OUI according to underlying hypervisor type, (invoking
>>> virConnectGetType to get the virt type). e.g. If virConnectGetType
>>> returns "QEMU", we use Qumranet's OUI (00:1A:4A), if returns
>>> ESX|VMWARE, we use VMWARE's OUI (00:05:69). Currently it only
>>> supports qemu|xen|libxl|xenapi|hyperv|esx|vmware drivers. The last
>>> 36 bits are auto-generated.
>>
>>> +
>>> +#define QUMRANET_OUI "001a4a"
>>> +#define VMWARE_OUI "000569"
>>> +#define MICROSOFT_OUI "0050f2"
>>> +#define XEN_OUI "00163e"
>>> +
>>> +int
>>> +virRandomGenerateWWN(char **wwn,
>>> + const char *virt_type) {
>>
>> I don't like this interface - it makes virrandom.c know too much. A
>> better interface would be:
>>
>> virRandomGenerateWWN(char **wwn, const char *oui)
>>
>> where the caller is responsible for determining the appropriate OUI for
>> the hypervisor to be passed in.
>>
>
> I have thought this, but the problem is we want auto-generate the WWN,
> the nodedevice driver doesn't known which OUI should be passed to
> virRandomGenerateWWN in this case, unless we extend the API
> virNodeDeviceCreateXML to accept a flag, or introduce a new API. I
> guess we won't want to see this in this period. :-)
>
> Regards,
> Osier
>

Hi, Eric,

How about my excuse, ;-)

Osier




More information about the libvir-list mailing list