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

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