Bug 1120265

did it report the ip before the export?
on step no. 4, after import, did you run the vm and check that the ip is not reported?

(In reply to Omer Frenkel from comment #1)
> did it report the ip before the export?
> on step no. 4, after import, did you run the vm and check that the ip is not
> reported?

Yes, before the export made at the step 3, it reported IP address.
I ran the VM and saw that IP address not been received at all, so this might be the very reason for IP not being reported.

Re-checked the issue, I was testing it on 3.3.1 engine environment.

if the vm did not receive ip from the network, and it does not have an ip, it is expected that you will not see ip in the ui.

did you check if the ip is missing because of network configuration on the vm or something that is related to ovirt?

it sounds like not a bug, any objection to close it?

(In reply to Omer Frenkel from comment #4)
> if the vm did not receive ip from the network, and it does not have an ip,
> it is expected that you will not see ip in the ui.
> 
> did you check if the ip is missing because of network configuration on the
> vm or something that is related to ovirt?
> 
> it sounds like not a bug, any objection to close it?

I object, once you had a working VM with IP address , then exported it to export domain, then imported as another VM, you have to get IP address as there have to be inheritance of existed network NIC interface, the bug actually on that IP not received, the network configuration have to be checked by network team for anyway, I expect importing VM and then running it and then getting the IP address from DHCP, different of course as well as new MAC to be created.

Lior, any thoughts on this?

Network config on original VM:
[root@localhost ~]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.35.88.57  netmask 255.255.255.0  broadcast 10.35.88.255
        inet6 fe80::21a:4aff:fea5:fb8c  prefixlen 64  scopeid 0x20<link>
        ether 00:1a:4a:a5:fb:8c  txqueuelen 1000  (Ethernet)
        RX packets 24592  bytes 72023696 (68.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 137  bytes 17799 (17.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 6  bytes 560 (560.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 560 (560.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

agent status on original VM:
[root@localhost ~]# service ovirt-guest-agent status
Redirecting to /bin/systemctl status  ovirt-guest-agent.service
ovirt-guest-agent.service - oVirt Guest Agent
   Loaded: loaded (/usr/lib/systemd/system/ovirt-guest-agent.service; enabled)
   Active: active (running) since Mon 2014-07-21 18:55:58 IDT; 1min 53s ago
  Process: 961 ExecStartPre=/bin/chown ovirtagent:ovirtagent /run/ovirt-guest-agent.pid (code=exited, status=0/SUCCESS)
  Process: 950 ExecStartPre=/bin/touch /run/ovirt-guest-agent.pid (code=exited, status=0/SUCCESS)
  Process: 922 ExecStartPre=/sbin/modprobe virtio_console (code=exited, status=0/SUCCESS)
 Main PID: 966 (python)
   CGroup: /system.slice/ovirt-guest-agent.service
           └─966 /usr/bin/python /usr/share/ovirt-guest-agent/ovirt-guest-agent.py

Jul 21 18:55:58 localhost.localdomain systemd[1]: Started oVirt Guest Agent.


These are after export/import was performed-see attachment.

Created attachment 919683 [details]
ifconfig

I also found that both VMs has the same UUID for the /etc/sysconfig/network-scripts/ifcfg-eth0 and that's the reason that VM created from TEMPLATE or just imported, won't receive IP as it's already given for the same UUID for original VM, please consider for if this works as designed or not with PM.

In case I'm making many VMs from template I'd expect getting unique UUIDs for each and every created VM from template, same for importing of VMs.

isn't this a known issue with rhel templates and sys-unconfig?
michal - i'd hoped this would be solved for a rhel 7 guest?
Nikolai - this isn't related to the hosts being rhel 7, right? would happen on rhel 6 hosts as well?

(In reply to Itamar Heim from comment #10)
it is a known issue. not solved yet (there's a virt-sysprep hook, though)

There's network BZ 1080752 about cloud-init flows where you should be able to override network (we do support generic override/rerun of cloud-init/sysprep in Run Once since 3.4), and a virt BZ 1100489 for generic virt-sysprep processing after clone. IMHO the "clone" case should handle import as well

*** This bug has been marked as a duplicate of bug 1100489 ***

(In reply to Itamar Heim from comment #10)
> isn't this a known issue with rhel templates and sys-unconfig?
> michal - i'd hoped this would be solved for a rhel 7 guest?
> Nikolai - this isn't related to the hosts being rhel 7, right? would happen
> on rhel 6 hosts as well?

Yes, it's not related to OS, only to making a VMs from template or VMs from pool or importing VMs from export domain, while all of them made from original RHEL7.0 OS running over original VM from which they were created.

No connection to host itself. f