[SOLVED] Hotplug of NICs in CentOS 7 VM

[apoz]

Hi all,

I'm facing some problem and may be someone could have experience with already.

In my virtualization host (running qemu-kvm) I have a VM running CentOS 7 (guest).After some network configuration change in the host, I'd like to dettach and attach the network interface of the VM.
I follow these steps:

• 1.- Dump the xml of the VM in qemu-kvm (virsh dumpxml)
  2.- Dettach the interface of the VM using the MAC as index (virsh detach-interface --mac XXXXXXXX)
  3.- Attach a new device to the vm with the part of the xml extracted in 1 for it to have even the same MAC (virsh attach-device)

The problem I'm having is that the interface does not come up automatically. If I do an 'ifup' of the interface, it comes up good. But it does not happen automatically (as I'd expect).

Is there any configuration I'm missing for the interface to come up automatically? Who should put the interface up, network system in CentOS or pci hotplug functionality?

If someone could provide some hint about what could be the problem, I'd appreciate.

The version I'm running the VM is CentOS Linux release 7.3.1611 (Core)

My network configuration files:

Code: Select all

$ cat /etc/sysconfig/network
NETWORKING=yes
NOZEROCONF=yes

Code: Select all

$cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
TYPE=Ethernet
IPV6INIT=yes
IPV6ADDR=2a02:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

Thanks!

[hunter86_bg]

What is the output of

Code: Select all

virsh domiflist Guest

[apoz]

This is the output of domiflist:

Code: Select all

virsh # domiflist one-166
Interface  Type       Source     Model       MAC
-------------------------------------------------------
one-166-0  bridge     br_mgmt    virtio      02:00:XX:XX:XX:XX
one-166-1  bridge     br_1003    rtl8139     02:00:XX:XX:XX:XX

May be it could be related to the model of the NIC in qemu-kvm? (the one we find missing is the first one, that is the one that provides the management interface)

Thanks!

[TrevorH]

There's no driver for the 8139 chipset in CentOS 7, use a different model.

[hunter86_bg]

Trevor you are wrong.

The "Hypervisor default" defaults to "rtl8139" (tested on RHEL7.3) and the device name in the machine will be "ensXY" instead of "ethXY".
That's why @apoz config is not working. "Virtio" NIC models are detected as "ethXY" in the new naming style.

@apoz you can either set it as virtio, or fix your config , or pass a specific kernel parameter to grub's entry to disable the new naming convention.

[apoz]

Hi all,

thanks for the responses!

EDIT: Some relevant information, as the machine is managed by Opennebula (http://opennebula.org), I have Network manager disabled. And the network configuration is configured by Opennebula driver. May be the hotplug of devices is something not implemented in Opennebula driver? How does Network Manager handle the device attachments (an script hooked to some event)?

I simplified the scenario leaving just one interface in the machine, and I'm still seeing the same problem (I'm afraid the problem is not related to the interface naming).

I left the VM with CentOS 7 with just 1 interface named eth0 and model virtio.

Code: Select all

virsh # domiflist one-20
Interface  Type       Source     Model       MAC
-------------------------------------------------------
one-20-0   bridge     br_mgmt    virtio      02:XX:XX:XX:XX:XX

Then I detach and reattach the interface to the VM, and the interface is again created with the 'eth0' name (that's why I think the problem is not related to the naming of the interface), but it remains in DOWN state.

Code: Select all

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 02:00:0a:5f:54:5d brd ff:ff:ff:ff:ff:ff
    

The configuration file is still created with the ip configuration:

Code: Select all

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
TYPE=Ethernet
NETMASK=255.255.255.128
IPADDR=10.95.84.93
GATEWAY=10.95.84.1

If I do a ifup eth0, the interface gets in UP state and the IPs get configured and everything works fine.

The dmesg logs when the interface is reattached:

Code: Select all

[581978.331057] pci 0000:00:03.0: BAR 6: assigned [mem 0x80000000-0x8003ffff pref]
[581978.342051] pci 0000:00:03.0: BAR 1: assigned [mem 0x80040000-0x80040fff]
[581978.346360] pci 0000:00:03.0: BAR 0: assigned [io  0x1000-0x101f]
[581978.361706] virtio-pci 0000:00:03.0: enabling device (0000 -> 0003)
[581978.401529] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver

and lspci looks 'fine':

Code: Select all

00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
	Subsystem: Red Hat, Inc Device 0001 
		Physical Slot: 3
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 1000 [size=32]
	Region 1: Memory at 80040000 (32-bit, non-prefetchable) [size=4K]
	[virtual] Expansion ROM at 80000000 [disabled] [size=256K]
	Capabilities: [40] MSI-X: Enable+ Count=3 Masked-
		Vector table: BAR=1 offset=00000000
		PBA: BAR=1 offset=00000800
	Kernel driver in use: virtio-pci
	Kernel modules: virtio_pci

I'd need the ifup to be executed automatically.

Is there any configuration I have to set for that to happen automatically?
Who should be responsible for setting the interface up?, the virtio-pci driver? the network service in CentOS 7?

Thank you very much in advance!

Regards,
Andrés

[apoz]

I found out what was going on.

There was a bug in the reconfiguration script in Opennebula that was called by udev rule.
As there was no network 'context' information change, it was trying to set up again the interface configurations.

Thank you very much for the help!

Regards,
Andrés