On 2012年02月07日 21:15, Matthias Bolte wrote:
2012/2/7 Osier Yang<jyang@xxxxxxxxxx>:
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.
A step in the right direction :)
But why should we use a string here and call virConnectGetType when we
already have a virDomainVirtType enum and the virDomainDef struct has
a virtType member that holds the required information?
node device driver is independant with hypervisor driver, and it
doesn't relates with a domain, so the only way for us to determine
which OUI should be used is to query the connection to get the
virt type.
The only scenario of using virDomainVirtType in my mind is to extend
virNodeDeviceCreateXML to accept a virt type flag, (or new API). and
in that case we need to add a new enum like virDomainVirtType in
libvirt.h too.
Not sure If I understand you correctly though. :)
Regards,
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list