3

Upon cloning a base image, I need to reconfigure basic settings. Regenerating the ssh host key, changing static IP assignments, setting the host name, etc.

Because of the network setup, DHCP is not an option. That more or less rules out SSHing in with a predefined key or running a startup script since I can't provide the IP externally.

I'd most like to mount the filesystem of the new machine on Dom0, but the lvm volumes are exported and it appears to be Bad Form to import them so the Dom0 machine can see them.

What's your best suggestion for altering files in a cloned VM before boot? Must be non-interactive, and I'm going to guess out the gate that scripting access via xe console is not going to work well.

1
  • I'm sure there are good reasons, but I'm curious to hear more about why DHCP isn't an option. Thanks! Mar 23, 2012 at 5:19

4 Answers 4

5

You should do what some deployment systems (Open Nebula for instance) do - create a tiny second drive consisting of the personalization data.

Configure your image to expect this second drive to be there (perhaps with a known UUID or filesystem name) and if it is there, read out the personalization data and apply it to the OS during boot.

The other cool option that Open Nebula does is actually embed the IP address into the MAC address. Decode that inside your domU and you're set!

Or, just use IPv6 autoconfig. :)

1
  • +1 These are the two solutions that I was going to propose, although I'd like to know more about why DHCP isn't an option. I usually just use DHCP and configure my DHCP server with static entries for MACs that I assign to the VMs (ok, not really, I clone the VMs, then run a script that collects their MACs and generates the appropriate dhcpd.conf block, which I then stick into my dhcpd server before booting them; but same difference really). Mar 23, 2012 at 5:18
4

Because of the network setup, DHCP is not an option. That more or less rules out SSHing in with a predefined key or running a startup script since I can't provide the IP externally.

What about using a static IP as a "build IP", boot the image on this known IP with a known key and kick off a script that logs in, reconfigures, and reboots?

2

Configure the base image to

  • auto-ip
  • download a configuration tarball
    • via ftp or something simple
    • base the tarball name on something unique to the machine, like the MAC addy
    • from a known address (eg 169.254.0.1 or fe80::1)
  • unpack the tar to apply the configuration
  • reboot

Also has the ability to get really creative if you want; auto-generate the tarball on download request, possibly based on database information, and generally based on a configuration skeleton.

1

Apparently, vgexport/vgimport is not necessary to move drives from one system to another. It is an administrative policy tool to prevent access to volumes in the time it takes to move them.

vgchange -a y marked all volumes as usable, but that didn't help me because they're not direct partitions. They're virtual disk images that have partition tables inside them.

Then I came across the script below at http://www.mceith.com/blog/?p=112. Direct attachment of disks to the VM... adjust as needed, the re-call to unmount.

#!/bin/bash
# [email protected] 2011
if [ ! -n "$1" -o ! -n "$2" -o ! -n "$3" ]; then
echo "Usage: $0 <target vm uuid> <control domain uuid> <mount|umount>"
exit 1
fi

case "$3" in
mount)
if [ -f /tmp/tmpvbd ]; then
echo "VBD allready exists!"
exit 1
fi

# Get uuid of vm you want to configure
VMUUID=`xe vbd-list vm-uuid=$1 params=vdi-uuid empty=false --minimal`

# Create VBD link to VM VDI on dom0
NEWVM=`xe vbd-create vm-uuid=$2 vdi-uuid=$VMUUID device=1`

# Plug it to dom0
xe vbd-plug uuid=$NEWVM

VM_VDEV=`xe vbd-list uuid=$NEWVM params=device --minimal`1

# Lag
sleep 1

# Mount it
mount /dev/$VM_VDEV /mnt/newvm

echo $NEWVM > /tmp/tmpvbd
# Do what ever you like
# ....
;;

umount)

if [ ! -f /tmp/tmpvbd ]; then
echo "No VBDs mounted?"
exit 1
fi

umount /mnt/newvm

NEWVM=`cat /tmp/tmpvbd`

# Unplug
xe vbd-unplug uuid=$NEWVM

xe vbd-destroy uuid=$NEWVM

rm -f /tmp/tmpvbd
;;
esac

exit $?
1
  • vgexport/vgimport was the tool for safely exporting/importing a VG. Linux' lvm stack has just diverged from the original design a lot. with shared access to disks it can still be helpful to export/import, but since there's no exclusive or readonly activation modes, those things become moot. Oct 25, 2017 at 20:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .