Bug 1568822 - can't configure network on VM
Summary: can't configure network on VM
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: vdsm
Classification: oVirt
Component: General
Version: 4.20.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-18 09:45 UTC by Lucie Leistnerova
Modified: 2018-04-23 12:33 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-23 12:33:24 UTC
oVirt Team: Network
Embargoed:


Attachments (Terms of Use)
console output (16.89 KB, image/png)
2018-04-18 09:47 UTC, Lucie Leistnerova
no flags Details

Description Lucie Leistnerova 2018-04-18 09:45:16 UTC
Description of problem:
VM's network device can't be configured after the start.

Version-Release number of selected component (if applicable):
vdsm-4.20.25-1.el7ev.x86_64
ovirt-engine-4.2.3-0.1.el7.noarch

How reproducible: always


Steps to Reproduce:
1. create new VM, set ovirtmgmt network
2. Run once the VM, in Boot options: set PXE as first, uncheck 'Run stateless' and 'Enable menu to select boot device'
3. run it
4. open Console and wait for PXE to launch

Actual results: no network device configured


Expected results: network device configured and VM can connect to PXE


Additional info:
no error in engine.log
VM running on older host with vdsm-4.20.23-1.el7ev.x86_64 configures network successfully.

on newest host:
# virsh domiflist $VM; virsh dumpxml $VM | grep -A 20 '<interface'
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet0      bridge     ovirtmgmt  virtio      00:1a:44:08:30:83

    <interface type='bridge'>
      <mac address='00:1a:44:08:30:83'/>
      <source bridge='ovirtmgmt'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <link state='up'/>
      <boot order='1'/>
      <alias name='ua-ee071312-2d63-48fd-86a2-d0bb2fb5cc3a'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>


on older host:
# virsh domiflist $VM; virsh dumpxml $VM | grep -A 20 '<interface'
Interface  Type       Source     Model       MAC
-------------------------------------------------------
vnet1      bridge     ovirtmgmt  virtio      00:1a:44:08:30:83

    <interface type='bridge'>
      <mac address='00:1a:44:08:30:83'/>
      <source bridge='ovirtmgmt'/>
      <target dev='vnet1'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <boot order='1'/>
      <alias name='ua-ee071312-2d63-48fd-86a2-d0bb2fb5cc3a'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Comment 2 Lucie Leistnerova 2018-04-18 09:47:08 UTC
Created attachment 1423421 [details]
console output

Comment 3 Dan Kenigsberg 2018-04-19 19:34:20 UTC
Sorry, I do not understand what you are attempting to do, nor do I notice any difference between the <interface> xml items.

Are you able to boot from pxe at all?

Can you describe it face-2-face to Michal, who might understand you better?

Comment 4 Michal Skrivanek 2018-04-23 06:52:53 UTC
the difference is in <link state="up"/>

Comment 5 Lucie Leistnerova 2018-04-23 07:59:27 UTC
I'm trying to boot from PXE and I can't. VM's network interface is up and plugged. 
Starting it on newest 4.2.3 host failed to set up network and PXE is not loaded. On other hand starting the same VM on older 4.2 host works fine and I can boot from PXE.

Comment 6 Meni Yakove 2018-04-23 08:45:59 UTC
Francesco, might this be related to your recent vdsm-side cleanup?
Shouldn't <link state="up"/> be sent by Engine?

Comment 7 Michal Skrivanek 2018-04-23 09:55:42 UTC
(In reply to Meni Yakove from comment #6)
> Francesco, might this be related to your recent vdsm-side cleanup?
> Shouldn't <link state="up"/> be sent by Engine?

it is sent the same for both cases. Just on olde vdsm it's replaced entirely. However the problem is reported on the new host - so it's probably on the vdsm side or something with the host network configuration

Comment 8 Lucie Leistnerova 2018-04-23 10:06:10 UTC
The newest host was upgraded from the same version as the older host is (4.20.23-1.el7ev.x86_64 -> 4.20.25-1.el7ev.x86_64). I'm not aware of doing some changes in the host's settings.

Comment 9 Lucie Leistnerova 2018-04-23 12:33:24 UTC
After detailed Michal's investigation it seems, that the testing host's environment is broken and network is misconfigured. After upgrading second host, the VMs booted on it from PXE with success.
So I'll close this issue. Feel free to reopen when the problem appears again.


Note You need to log in before you can comment on or make changes to this bug.