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

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

 



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

--
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]