Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1154377

Summary: eth0 interface missing from cloned vm from template
Product: Red Hat Enterprise Virtualization Manager Reporter: Raz Tamir <ratamir>
Component: ovirt-engineAssignee: Nobody <nobody>
Status: CLOSED NOTABUG QA Contact:
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.4.1-1CC: ecohen, gklein, iheim, lpeer, lsurette, lvernia, michal.skrivanek, ofrenkel, ratamir, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---Keywords: AutomationBlocker, AutomationTriaged, Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-21 08:14:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
vdsm and engine logs
none
Screenshot none

Description Raz Tamir 2014-10-19 11:35:49 UTC
Created attachment 948242 [details]
vdsm and engine logs

Description of problem:
After cloning vm from template, that was created from vm with os, When trying to get the machine IP through ifconfig, no eth0 interface exists.

in the base vm, that the template created from, when running ifconfig eth0 interface exists


Version-Release number of selected component (if applicable):
rhevm-3.5.0-0.11.beta.el6ev.noarch
vdsm-4.16.6-1.el6ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. create vm with os
2. make template from that vm
3. clone new vm from that template

Actual results:


Expected results:


Additional info:

Comment 1 Omer Frenkel 2014-10-20 07:28:36 UTC
i dont see any suspicious error in the log, the nic device looks ok as well:

{nicModel=pv, address={bus=0x00, domain=0x0000, slot=0x03, type=pci, function=0x0}, specParams={outbound={}, inbound={}}, macAddr=00:1a:4a:73:92:03, device=bridge, linkActive=true, type=interface, filter=vdsm-no-mac-spoofing, network=rhevm, deviceId=488a56dc-27b9-4c7d-bf94-43349d71e115}

i assume it some network config issue, Lior, can you take a look?

Comment 2 Lior Vernia 2014-10-20 07:52:52 UTC
Does the NIC appear in oVirt? How about when running "ip addr" inside the guest? ifconfig doesn't report NICs in down state (although I would expect the NIC to be in up state, it would be less strange than it being missing), and is generally being deprecated - please use the "ip" command instead.

Comment 3 Raz Tamir 2014-10-20 08:25:30 UTC
Created attachment 948459 [details]
Screenshot

Hi Lior,
The nic appears in oVirt.
I also ran 'ip addr' command and the output screenshot is attached

Comment 4 Lior Vernia 2014-10-20 10:09:04 UTC
Sat with Raz, and just to summarize our findings:
1. The original VM has one NIC, with MAC address X, as "eth0".
2. The cloned VM gets one NIC, with MAC address X+1, as "eth1" - in the udev rules "eth0" is still reserved to MAC address X.
3. However, there is only an ifcfg-eth0 file (identical to the one on the original VM, i.e. with MAC address X), and no ifcfg-eth1 file.

Could this be some sealing issue? Was there something that Raz should have done manually on the VM before creating a template from it, or is it something performed by oVirt that might have changed under its feet by RHEL 6.6?

Comment 5 Michal Skrivanek 2014-10-20 12:11:41 UTC
which test case is this blocking?
you're supposed to clone from a sealed/unconfigured template. This is not the case here.
This is a known issue, see bug 1100489 and bug 1080752 for further discussion

Comment 6 Raz Tamir 2014-10-21 07:15:34 UTC
Hi Michal,
What do you mean by sealed/unconfigured template?
bug 1100489 and bug 1080752 are about MAC addresses duplication issues, this is not the case here

Comment 7 Michal Skrivanek 2014-10-21 08:14:23 UTC
http://www.ovirt.org/Sealing_Linux_VM

Comment 9 Michal Skrivanek 2014-10-22 16:39:26 UTC
I suppose something must have changed in the setup of the original VM?
Is this perhaps on RHEL 6.6 or 7.0 now? Maybe the behavior there is different in case of udev detecting an existing MAC

In any case the test should be changed to do a proper sealing (or just don't configure the original VM), then it should still pass on 3.4 and also on 3.5 or a new RHEL

Comment 11 Michal Skrivanek 2014-10-27 09:49:31 UTC
*** Bug 1154388 has been marked as a duplicate of this bug. ***