Packer: virtualbox-ovf builder issue

[doorhinge]

I originally posted this here: #793, but I think it's a different issue. I'm using Packer 0.5.1 with CentOS 6.4 and VirtualBox 4.3.6 and I'm experiencing an issue with the virtualbox-ovf builder. After creating an ovf file using the virtualbox-iso builder, I try to run the virtualbox-ovf builder and it fails because it never successfully connects via SSH and eventually times out:

Also, here's a gist (https://gist.github.com/doorhinge/8337429) containing:

• The kickstart file used with the virtualbox-iso builder.
• The template used with the virtualbox-ovf builder.
• The Packer log when running the virtualbox-ovf builder.

[wingyplus]

@doorhinge please check

• user and password, Can it login with vagrant user.
• ip of network interface in ovf, Can it receive the ip. I found some trouble if has vm use NAT interface in Virtualbox when packer import vm it use other interface and vm not receive ip.

[doorhinge]

• Yes it can login with vagrant.
• How would I find the IP of the network interface? Also, how would I test to see if it can receive the IP?

[wingyplus]

@doorhinge I login to VM. I use ifconfig -a to see what have interface network and check the /etc/network/interface to check interface does auto ip .

[doorhinge]

This the output I get when I login to the VM and run ifconfig -a:

eth0      Link encap:Ethernet  HWaddr 08:00:27:54:BD:77  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe54:bd77/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:308 errors:0 dropped:0 overruns:0 frame:0
          TX packets:195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:33890 (33.0 KiB)  TX bytes:27495 (26.8 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

This is the contents of the /etc/sysconfig/network-scripts/ifcfg-eth0 file:

DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="08:00:27:54:BD:77"
IPV6INIT="yes"
MTU="1500"
NM_CONTROLLED="yes"
ONBOOT="yes"
TYPE="Ethernet"
UUID="7e9e5303-aac5-45c9-9002-3c102aa80dbb"

[wingyplus]

@doorhinge You has packer log? please post it in this issue.

[doorhinge]

The Packer log is here: https://gist.github.com/doorhinge/8337429#file-packer-log. It looks like it has issues connecting via SSH.

[doorhinge]

Any idea?

[wingyplus]

Can you ssh to virtualbox manually when packer mapping port in localhost to guest?

[doorhinge]

I'm not sure I understand what you mean. Are you asking if I can SSH into the VirtualBox image that I created with the virtualbo-iso builder? How would I test that?

Would I just run the image and then try to SSH in?

And by the way, thanks for your help!

[apetresc]

I believe I'm experiencing the exact same issue (except not with CentOS).

I have a box being created with packer of type virtualbox-iso. Everything is great on that box, and if I export it to Vagrant it runs perfectly.

However, if I take the generated .ovf and feed it to another virtualbox-ovf builder, networking just fails to come up. I am not able to SSH into it through the mapped port, and if I log in from VirtualBox the logs are littered with networking errors.

I'm not sure what the virtualbox-iso builder does that's so different from virtualbox-ovf but it's causing severe problems for me (and some others on IRC it seems)

[doorhinge]

@apetresc that's exactly my issue.

[wingyplus]

@doorhinge run the image and then try to SSH in.

You has packer build centos config with virtualbox-iso builder? I want to build to ovf and test it on virtualbox-ovf builder.

[doorhinge]

How would I SSH in to the image? Do I have to use port forwarding? My virtualbox-iso Packer config is here: https://gist.github.com/doorhinge/8949631 and the kickstart file is here: https://gist.github.com/doorhinge/8337429#file-ks-cfg.

[wingyplus]

you will SSH by set network interface to NAT and set port forwarding

thank you

On Wed, Feb 12, 2014 at 10:32 AM, Karl [email protected] wrote:

How would I SSH in to the image? Do I have to use port forwarding? My
virtualbox-iso Packer config is here:
https://gist.github.com/doorhinge/8949631 and the kickstart file is here:
https://gist.github.com/doorhinge/8337429#file-ks-cfg.

—
Reply to this email directly or view it on GitHubhttps://github.com/mitchellh/packer/issues/866#issuecomment-34835668
.

[doorhinge]

So I ran the image and tried to SSH in using:

ssh -p 3499 [email protected]

and this is the output:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /Users/karl.loebach/.ssh/config
debug1: /Users/karl.loebach/.ssh/config line 1: Applying options for *
debug1: /Users/karl.loebach/.ssh/config line 10: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 3499.
debug1: Connection established.
debug1: identity file /Users/karl.loebach/.ssh/id_rsa type 1
debug1: identity file /Users/karl.loebach/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: Connection closed by remote host

It looks like it successfully connects, but it just hangs and the connection is eventually closed.

[mitchellh]

Based on the logs, the OpenSSH log, and this thread, it sounds like the machine is somehow being configured in such a way that Packer can't SSH in.

It sounds like the OpenSSH server config might have something in it preventing access for the user. Based on the hang when you ran ssh manually. Nothing indicates at the moment that this is a Packer issue, unfortunately.

Let me know if you find out this is wrong.

[miroswan]

I know why this is happening. After the ovf is imported, the eth0 interface has the incorrect MAC address. You would have to run ifconfig eth0 | grep Ethernet | awk '{ print $5}' to get the correct MAC address. Next, you add it to the ifcfg-eth0 file. After running service network restart, you'll be able to SSH into the machine.

This may be an issue specific to CentOS. Not sure how people want to handle this to get it working with this builder.

-- Edit --

I can see now that your Mac addresses do match. This, however, was the cause of my issue with this builder.

[mrwilby]

I'm having exactly the same issue as the OP. Using centos 6.5, packer v0.5.2, using virtualbox-ovf after successfully building a base image using virtualbox-iso.

It's verbatim the same problem as I see.

Any suggestions? I didn't follow the suggestion regarding mac addresses above. Can somebody clarify? Thanks!

Update:
The problem in my case seems to be that the centos VM's eth0 has been renamed to eth1. Centos doesn't have a config file for eth1 and as such, no DHCP lease is attempted. If I log into the VM manually and perform a sudo dhclient (get DHCP lease) then packer is able to connect over SSH shortly afterwards.

From reading here http://www.cyberciti.biz/tips/vmware-linux-lost-eth0-after-cloning-image.html it sounds like the mac address is the key.

Is packer somehow doing anything to modify the mac address? Is there a way to "pin" the address so that the same address is used for both the packer virtualbox-iso and virtualbox-ovf invocations?

[mkuzmin]

I had the same issue with my Ubuntu guest: on start the guest OS wasn't able to detect its network configuration.
Maybe there is some elegant way to solve it within a guest, but this Packer option "import_opts": "keepnatmacs" helped me.
I was wrong. That option hides the error message in Packer, but leaves incorrect configuration within the guest OS. The same error happens later, when new virtual machine is cloned out of Vagrant box.

A correct solution is to modify rules within /etc/udev/rules.d/

[mrwilby]

Thanks. I worked around this in the end by wacking a couple of files - basically like this http://6.ptmc.org/?p=164

[rjnienaber]

I ran into this exact same issue and I managed to resolve it by adding the following to my Packer script:

"vboxmanage": [
  ["modifyvm", "{{.Name}}", "--macaddress1", "080027a79e8f"]
],

@mkuzmin's comment tipped me off and I found the old mac address in my /etc/udev/rules.d/70-persistent-net.rules file. I saw a line like the following:

 # PCI device 0x8086:0x100e (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:a7:9e:8f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Which contained the old mac address, along with a new line for an eth1 interface. Once I made the addition to my script, everything worked fine.

[vitorcoxta]

I just ran into this issue as well. I ran a virtualbox-iso builder to create a CentOS 6 virtualbox, and then ran a virtualbox-ovf builder to import the ovf previously created and run some stuff.
When I run Packer on this last builder, it hangs waiting for SSH to become available, eventually exiting for timeout. If I login into the virtualbox while packer is waiting for SSH, and if I run

ifconfig

I just get information about 1 network interface: lo.

However, if I manually import the ovf and run it, ifconfig gets information about 2 network interfaces: eth0 and lo, and in this case I am able to SSH into the virtualbox from the host machine.

@mitchellh, probably this is an indicator of a Packer issue?

In the meantime, I managed to get this done with @rjnienaber tip (thanks!).

[jhulten]

Also seeing this issue.

@rjnienaber : Are you adding the modifyvm to the virtualbox-iso builder or the virtualbox-ova builder or both?

[rjnienaber]

@jhulten I have a scenario where I have one builder for an .ovf image from scratch using virtualbox-iso and then I use that image as input to another builder using virtualbox-ovf. I've only added it to build files that are downstream from the initial builder.

I think the problem here is that by design, VirtualBox reinitialises MAC addresses when importing an image. It seems that VirtualBox takes the view that when you clone a VM, you probably still want to run the original VM in which case duplicate MAC addresses could play havoc with the network.

[rickard-von-essen]

As @mitchellh hinted about and @rjnienaber already suggested this is about how EL(CentOS etc) handles how to name network interfaces.

"The correct solution" as implemented in the bento boxes can be found in:

• https://github.com/chef/bento/blob/master/scripts/centos/cleanup.sh - for EL/CentOS/RHEL etc
• https://github.com/chef/bento/blob/master/scripts/debian/networking.sh - for Debian based distros.

EDIT: Updated links @bish0polis

[bish0polis]

@rickard-von-essen : those URLs are 404 now. (updated)

I have seen a number of folks either whack the persistent-net.rules file, or delete that file AND symlink it to /dev/null to prevent it being recreated. I'm not sure if that's what 'the correct solution' may be, but preventing that temporary/permanent cache/config from preventing a clean reconfig may be an idea elsewhere.

[andrewfraley]

I had this issue with the virtualbox-ovf provider and a CentOS 7 image. By default it was putting the VM into bridged network mode. The fix was to do:

["modifyvm", "{{.Name}}", "--nic1", "nat"

[davestj]

Just want to point out the fact that if all these people have to hack their way around this issue, it is indeed and in fact, a packer problem even if its an indirect issue. The problem is people expect it to work, not have to hack their way around things to get it to work, when we have to do this, this fits the description of a bug/product defect. FYI

[rickard-von-essen]

The problem is people expect it to work, not have to hack their way around things to get it to work

@davestj They are not hacking around. They are supplying a correct config of their OS. Is see no descriptions of bugs above, just people struggling with the (advanced) topic of administrating and automating the setup of Linux.

[michalciolek]

Script from https://github.com/chef/bento/blob/master/debian/scripts/networking.sh fix the problem.

[bby-bishopclark]

@rickard-von-essen : the EL/Centos URL is 404 now

[rickard-von-essen]

Superold closed issue...

[bby-bishopclark]

Sorry. I forgot we have no attention span. That'll fix the links.

[SwampDragons]

@bby-bishopclark if you navigate to the bento repo (which doesn't belong to Packer) then you'll find that the directory structure has been slightly changed.

https://github.com/chef/bento/blob/master/centos/scripts/cleanup.sh

For future users: just navigate to the base bento repo if the links 404. It's still highly likely that this repo will contain a working example for you.