yahoo-eng-team team mailing list archive

[Cyril Roelandt <1779781@xxxxxxxxxxxxxxxxxx>]

$ git tag --contains 475193b11dcda3b8c82a6bdd3faa54607d2b3272
26.0.0
26.0.0.0b2
26.0.0.0b3
26.0.0.0rc1


I don't think another patch is needed, so let's mark this as "fix released".

** Changed in: glance
       Status: In Progress => Fix Committed

** Changed in: glance
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1779781

Title:
  virt/vmware not suport VirtualSriovEthernetCard

Status in Glance:
  Fix Released
Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Description
  ===========
  In nova/virt/vmwareapi/vm_util.py:

  Through the code, this type of "VirtualSriov\
  EthernetCard" network card can be managed. 
  But in fact, "VirtualSriovEthernetCard" can 
  not be achieved through the current code 
  architecture.

  Steps to reproduce
  ==================
  In horizon:
  * Choose a image that you need to launch；
  * Update the metadata of this image:
    hw_vif_model: VirtualSriovEthernetCard
    (hw_vif_model in `VMware Driver Options`)
  * Create a VM from this image;
  * At this time, the background of nova will
    report an error.

  Actual result
  =============
   ”VirtualSriovEthernetCard“ is actually a
   physical NIC, unlike other virtual NICs
   that can directly configure properties.

   The sriovbacking attribute must be configured
   in its spec, which contains information about
   vf and pf. This information needs to be
   obtained through the vsphere client. 
   
   The vf/pf information included 'system_id'
   which is needs to be get after vm_vmotion is
   created. But in current code architecture, 
   this is impossible to achieve

  Environment
  ===========
  1.Version:
    Not related to the version;
  2.Hypervisor:
    compute_driver: vmwareapi.VMwareVCDriver;
  3.Storage:
    Not related to the storage.
  4.Networking:
    core_plugin: vmware_nsx.plugin.NsxDvsPlugin;

  Logs & Configs
  ==============
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall [req-31efa6ac-de11-4352-bec6-49c75a0a847a 72b0403e87184504bfaec9bcff45109c e387c7a4f9fc4e1aa5be07c7e1bfba0e - default default] in fixed duration looping call: VimFaultException: Invalid configuration for device '0'.
  Faults: ['InvalidDeviceSpec']
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Traceback (most recent call last):
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall   File "/usr/lib/python2.7/site-packages/oslo_vmware/common/loopingcall.py", line 75, in _inner
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall     self.f(*self.args, **self.kw)
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall   File "/usr/lib/python2.7/site-packages/oslo_vmware/api.py", line 452, in _poll_task
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall     raise task_ex
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall VimFaultException: Invalid configuration for device '0'.
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Faults: ['InvalidDeviceSpec']
  2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall

  Solution
  ==============
   According to the logic of the code, this type
   of network card is available, but in fact it is 
   confusing here. According to the current code
   architecture, the problem cannot be fixed. I 
   suggest to delete the corresponding code snippet
   and add comments to remind users.
   In the future, if necessary, support this type
   of network card by adding BP.

  Here upon is my cordial suggest！ :)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1779781/+subscriptions