Creating a virtual test lab – part#2

In my previous post, I outlined how to prepare and install your system. In part#2, I’ll outline how I’m configuring cobbler and creating my virtual test lab.

cobbler check


The first time you setup cobbler, it’s always a good idea to run cobbler check. A sample run on my newly installed system shows …

# cobbler check
#0: The 'server' field in /etc/cobbler/settings must be set to something other
than localhost, or kickstarting features will not work.  This should be a
resolvable hostname or IP for the boot server as reachable by all machines that
will use it.
#1: For PXE to be functional, the 'next_server' field in /etc/cobbler/settings
must be set to something other than 127.0.0.1, and should match the IP of the
boot server on the PXE network.
#2: Must enable selinux boolean to enable Apache and web services components,
run: setsebool -P httpd_can_network_connect true
#3: service cobblerd is not running 
#4: service xinetd is not running
#5: change 'disable' to 'no' in /etc/xinetd.d/tftp
#6: service httpd is not running
#7: since iptables may be running, ensure 69, 80, 25150, and 25151 are
unblocked
#8: One or more kickstart templates references default password 'cobbler' and
should be changed for security reasons: /etc/cobbler/sample.ks,
/etc/cobbler/legacy.ks, /etc/cobbler/sample_end.ks

Lesson for the reader

Take a few moments to walk through each of the recommendations. I’m leaving out the actions performed to resolve the above issues, they are outside the scope of this post. If you have questions, toss them in the blog and I’ll be happy to help.

After making the recommended corrections, running cobbler check again shows:

# cobbler check
The following potential problems were detected:
#0: since iptables may be running, ensure 69, 80, 25150, and 25151 are
unblocked
#1: One or more kickstart templates references default password 'cobbler' and
should be changed for security reasons: /etc/cobbler/sample.ks,
/etc/cobbler/legacy.ks, /etc/cobbler/sample_end.ks

Assuming you have opened up the recommended ports in your firewall, you should be safe to proceed. Let’s start getting things ready for the big event.

What To Wear?


Okay a stretch, but the whole point of this is so we can easily try on different distributions. I’m going to use several versions of Fedora, but cobbler doesn’t limit you to Red Hat Enterprise Linux or Fedora-based derivatives (see SupportForOtherDistros). I’m also fortunate in that all the distros I want are available via NFS on a nearby system. If that wasn’t the case, you may need to download the DVD’s from a local mirror.

  1. Download a DVD or CD image from a nearby mirror (i’ll be using the DVD).
  2. Loopback mount the DVD image:
    # mount -o loop Fedora-10-x86_64-DVD.iso /media
  3. Import the DVD into cobbler –
    # cobbler import --name F-10-GOLD --path /media
  4. Unmount the volume:
    # umount /media
  5. Rinse & repeat the process for other version of Fedora, Red Hat Enterprise Linux, or other.
  6. When finished, cobbler should show all the distributions you imported:
    # cobbler distro list
    F-10-GOLD-x86_64
    F-8-GOLD-x86_64
    F-8-GOLD-xen-x86_64
    F-9-GOLD-x86_64
    F-9-GOLD-xen-x86_64

NOTE

There are many different ways to import a distribution into cobbler. I typically choose not to mirror the entire distribution locally since it is often mirrored already on a nearby system. Instead, I provide a locally mounted nfs path to the distribution as well as the URL cobbler should use to install this distro –available-as. For example:

# cobbler import --name F-10-GOLD --path /mnt/path/to/F-10/GOLD/Fedora/i386/os \
--available-as http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/x86_64/os

For information on other ways to use cobbler import see UsingCobblerImport.

Making Room For Our Guests


I prefer using LVM logical volumes for my virtual guests. This allows me to re-install my host operating system while leaving the guests intact (useful when upgrading to a new Fedora release). We’ll use the free-space we left available when we installed the system.

  1. Let’s see how much free-space we have in our Volume group. Running vgs shows …
    # vgs
    VG         #PV #LV #SN Attr   VSize   VFree  
    VolGroup00   1   2   0 wz--n- 232.62G 182.81G

    As noted above, we have roughly 182G of disk space to play with. Let’s start by creating 5 15G logical volumes to act as virtual disk space for 5 virtual guests (I’ll create those next).

  2. Let’s create some logical volumes:
    # for NUM in 1 2 3 4 5; do lvcreate -L 15G -n vguest$NUM VolGroup00 ; done
    Logical volume "vguest1" created
    Logical volume "vguest2" created
    Logical volume "vguest3" created
    Logical volume "vguest4" created
    Logical volume "vguest5" created
  3. Finally, we’ll adjust the SELinux security contexts for the LVM logical devices by typing (dwalsh, thanks for the tip!):
    # chcon -t virt_image_t /dev/mapper/VolGroup00-vguest* /dev/VolGroup00/vguest*

What’s a Party Without Networking? (optional)


I prefer bridging rather than NAT since the bridged guests appear on the same subnet as my host. This makes network PXE booting easier (more on that later).

The commands to disable NetworkManager and create the bridge are very well detailed over at libvirt.org.

Thanks to poelcat for providing the link!

What’s a Party Without Guests?


Now that we’ve imported a few distributions, and made room for our guests to live … let’s invite the guests.

  1. Define your system in cobbler:
    # cobbler system add --name vguest1 --profile F-10-GOLD-x86_64  \
    --virt-type qemu --virt-bridge virbr0  \
    --virt-path /dev/VolGroup00/vguest1 \
    --virt-ram 1024
  2. Repeat this command for our 4 other guests. Adjust the –name, –virt-path, and –virt-ram each time to meet your needs.
  3. When finished, you should have 5 virtual systems defined in cobbler. To list the systems we just created:
    # cobbler system list
    vguest1
    vguest2
    vguest3
    vguest4
    vguest5

Let’s Get This Party Started!


Wow, that was a lot of prep work, but it will pay off I promise 🙂 Before we go any further, lets run a quick test to ensure everything works.

  1. Let’s kick off a quick install using vguest1:
    # koan --server `hostname` --virt --system vguest1
    - reading URL: http://your.hostname.here/cblr/svc/op/ks/system/vguest1
    install_tree: http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/x86_64/os/
    libvirtd (pid  3182) is running...
    - using qemu hypervisor, type=kvm
    - adding disk: /dev/VolGroup00/vguest1 of size 5
    libvir: QEMU error : Domain not found
    libvir: QEMU error : Domain not found
    use virt-manager and connect to qemu to manage guest: vguest1
  2. Launch the viewer:
    # virt-viewer vguest1

    Network timeout?

    You may encounter an error message indicating that a network connection could not be made, just click Retry for now (see bug#471382 for details). This will be addressed also in the next version of koan.

Congrats! You now have 5 virtual guests configured and available for provisioning through cobbler. You’ll notice that your first install was an automated text-mode installation.

My next post will spend more time on configuring the installs using kickstart and integrating it with SNAKE. Stay tuned …

Advertisements

12 responses to “Creating a virtual test lab – part#2

  1. imports

    Your import line is incorrect a bit unneeded as in your case you have the local files and then you are installing from the public mirror.

    If you had the files local you would instead want:

    cobbler import –name=F10 –path=/media –available-as http://jlaska.example.com/where/is/my/media/tree/starting ?

    Though most people will be doing this and copying the data

    cobbler import –name=F10 –path=/dvd/is/mounted/here

    With no further arguments. You can also save a step and import the rsync tree instead (see the cobbler manpage for details)

    — Michael

    • Re: imports

      Good tips Michael, thanks!

      I’m lucky to have all the distributions accessible (http, ftp and nfs) through another nearby server. Because of that, I chose not to mirror/rsync the distributions on my cobbler server.

      But as Michael suggests, if you don’t have a Fedora10 or similar distributions accessible on a fast local mirror … you may wish to import with copy as directed above.

    • Re: imports

      Thanks Michael, I’ve updated the text in the original post to take into account the corrected syntax.

  2. Autocreate LVs

    Koan will automatically create logical volumes provided that the virt-path is simply the name of a volume group.

    • Re: Autocreate LVs

      Yup, yup.

      As I also told James, all of those –virt-foo options can be set on the profile also, to avoid having to set them on each individual system object.

      — mpd

      • Re: Autocreate LVs

        I’ve chosen to set all the attributes at the system level not in the profile for now. I’ll explain more in the next post(s) when reviewing SNAKE kickstart integration instead of using python-cheetah.

        Although to be honest, I didn’t know I could move the –virt-* options up to the profile level. Same for having koan creating the volume groups for me. I’ll look into that for simplifying things. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s