VMware Workspace ONE Community
jseide86
Enthusiast
Enthusiast

Clone of vIDM appliance is not able to set correct IP

Hi

So I've been following the directons on VMware Docs for vIDM: Clone the Virtual Appliance for cloning the appliance, but when the clone is finished booting it has the same IP as the original VM. The hostname has changed though, just not the IP.

I've followed the steps mentioned in the guide to the letter, including

     1. checked udev/rules.d/ for the persistent-.net.rules file (which was not present)

     2. adjusted the vapp option attributes on the clone

The original VM info:

hostname: vidm-prod-01.corp.local.net

ip-address: 10.1.63.21

During boot of the clone I see the following messages:

Detect ovfenv

Try custom ovfenv

Try standard ovfenv

Configuring networking from ovfenv

     Hostname     :     vidm-prod-02.corp.local.net

     DNS          :     10.1.1.1,10.1.2.2

     IPv4 Address :     10.1.63.22

     IPv4 Netmask :     255.255.255.0

     IPv4 Gateway :     10.1.63.1

     IPv6         :     Unconfigured

save hostname vidm-prod-02.corp.local.net

== set_ipv4 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

== set_ipv6 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

hostname: Host name lookup failure

Unable to set hostname to vidm-prod-02, reverting to previous hostname: vidm-prod-02.corp.local.net

== set_ipv4 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

== set_ipv6 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

hostname: Host name lookup failure

restart networking

Shutting down (localfs) network interfaces:

     eth0     device: Intel Corporation 82545EM Gigabit Ethernet Co done

Setting up (localfs) network interfaces:

     eth0     device: Intel Corporation 82545EM Gigabit Ethernet Co

     eth0     IP address: 10.1.63.21/24                             waiting

     lo

     lo       IP address: 127.0.0.1/8

     secondary lo IP address: 127.0.0.2/8

     lo       is up

Waiting for mandatory devices:  eth0

30 29

     eth0     device: Intel Corporation 82545EM Gigabit Ethernet Co

     eth0     IP address: 10.1.63.21/24

     eth0     is up                                                 done

save hostname vidm-prod-02.corp.local.net

== set_ipv4 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

== set_ipv6 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

==============

Host name has been set to vidm-prod-02.corp.local.net

save hostname vidm-prod-02.corp.local.net

== set_ipv4 ==

DEFULT_INT: eth0

DEFAULT_IPV4: 10.1.63.21

HN: vidm-prod-02

DN: corp.local.net

==============

== set_ipv6 ==

DEFULT_INT: eth0

DEFAULT_IPV6:

HN: vidm-prod-02

DN: corp.local.net

Host name has been set to vidm-prod-02.corp.local.net

Setting up (localfs) network interfaces:

     lo

     lo     IP address: 127.0.0.1/8

            IP address: 127.0.0.2/8                                 done

     eth0   device: Intel Corporation 82545EM Gigabit Ethernet Co

     eth0     IP address: 10.1.63.21/24                             done  

I've checked wether reverse lookup is functioning from the appliance's subnet, and it seems fine:

sshuser@vidm-prod-01:~> dig +noall +answer -x 10.1.63.22

22.63.1.10.in-addr.arpa. 3600 IN      PTR     vidm-prod-02.corp.local.net.

Anyone got any ideas on what could be wrong? Thanks!

Reply
0 Kudos
8 Replies
pbjork
VMware Employee
VMware Employee

Hi..

This sounds weird. I've never seen the clone operation fail..

The steps I always do are:

1. Power down master node.

2. Make sure A and PTR records for new slave node exist in DNS.

3. Clone powered down master.

4. Modify OVF properties on the clone to reflect new FQDN (as the hostname in OVF) and unique node ip-address

5. Power on master node

6. Power on slave node

Do remember we only support a minimum of 3 nodes in a cluster..

Reply
0 Kudos
jseide86
Enthusiast
Enthusiast

OK, I guess I'll have to submit a case to VMware Support, then.

I've verified all the steps you've mentioned;

- A & PTR records exist in DNS, verified by lookups and visual inspection in the DNS console

- Modified the OVF properties like mentioned in the product documentation - tried with and without static hostname assignment as well (in case the lookup was failing)

- Power operations done accordingly with what you're describing

I'm planning to do a 3-node * 2 site setup for IDM, so 6 nodes in total.

Thanks for your time

Reply
0 Kudos
johandijkstra
Enthusiast
Enthusiast

I have seen this!
Where are you cloning the appliances?

We have seen similar problems when cloning to an other vcenter / maybe also to an other host...
Try to clone the appliance to the same host, fix the configuration and then move the appliance to an other host.

Reply
0 Kudos
johandijkstra
Enthusiast
Enthusiast

Hmmm... now I am not sure if we had problems with hostname or ip address...but maybe my idea is worth a try!

Reply
0 Kudos
pbjork
VMware Employee
VMware Employee

Which version of vIDM are you using? is it 3.0? Have you tried a version 3.1? Brand new 3.1 or updated from earlier versions?

Reply
0 Kudos
jseide86
Enthusiast
Enthusiast

pbjork

We're using Identity Manager 3.1. New install, not an upgrade.

johandijkstra

Cool, thanks, I'll try that and report back!

Edit: I tried, but there was no change when deploying the clone to the same ESXi host as the original VM. Worth a shot, I guess..

Reply
0 Kudos
makapoor
Contributor
Contributor

Any luck getting past this? We're working on a 2 site 3 node cluster/site with vIDM 3.2 and are having the same issue with cloning one of our appliances.

Reply
0 Kudos
makapoor
Contributor
Contributor

After digging around in /usr/local/horizon/scripts/networkwizard.hzn we found that we needed to delete the following backup files from the source appliance before creating a clone.

/etc/sysconfig/network/routes.bak

/etc/resolv.conf.bak

/etc/sysconfig/networking/devices/ifcfg-eth0.bak

Reply
0 Kudos