Archive for October, 2010

Deploying RHEL as ESX guests – Kickstarting or using ESX templates?

Wednesday, October 20th, 2010

Some time ago I asked my self the question if it is better to kickstart systems or working with ESX templates when deploying RHEL as ESX guests. I also had some discussions with friends working in the same industry. I tried it and came to the following conclusion:

Kickstart the systems is the way to go.

Pros:

  • Kickstarted Systems are already up-to-date after installation.
  • Proper SSH host keys. Using ESX templates ends up in having identical SSH host keys, from the security standpoint not usable, they need to be manually re-created.
  • Kickstarting means lean deployment, much less data needs to be transferred.
  • Very fast, kickstarted systems are deployed in ~3min instead of ~10min (depending on I/O and network performance).
  • Systems are being automatically registered @rhn or on a rhn-satellite with the help of cobbler snippets.
  • Better customization.

Cons:

  • The ESX template to used for kickstarting must have no disks configured, otherwise the whole nominal disk size is being transferred over the net.

When kickstarting virtual systems, only the data needed (the RPMs) is transferred. The best way is to have a “empty” ESX template, just with the network defined, but no disks. The reason for that is: ESX creates a checksum of the disk files, even if the disk is empty, the sparse disk files (in the case of “thin provisioning”) will be transferred over the net at its full nominal size.

When using ESX templates, after deploying, one needs to register the system manually and also manually update the system by invoking “yum -y update”. In contrary, kickstarted systems are always up to date automatically. To circumvent this fact, one needs to keep the templates up to date, it is a manual task which can not be automated easily.

Have fun!

Spacewalk is moving further to PostgreSQL support

Tuesday, October 5th, 2010

The upstream of RHN Satellite – Spacewalk – is moving further to database indepedancy, with the scope of PostgreSQL compatiblity. How I come to this conclusion? Read the git commit logs.

At FUDCon 2010 in Zurich I was attending Miroslav’s talk. He was complaining that nobody gives the PostgreSQL-version a try. He is right, on one hand everybody expects PostgreSQL support ASAP, on the other hand nobody takes care about the PostgreSQL setup, and nobody helps neither with the development nor bug reporting.

Whats the reason for this? As I wrote in Managing CentOS with Spacewalk the roadmap of Spacewalk reads “ready” for PostgreSQL at Version 0.6. At the same time one could read at Milestone Release – 2.0 “??? Not sure – *maybe* PostgreSQL support”. And this statement is still there. At the moment Spacewalk is approaching version 1.2, and the goals for milestone 2.0 are still there.

No wonder that people tend to NOT testing PostgreSQL support. I’m a follower of the git commit logs of Spacewalk. In the past few weeks I have seen a lot of progress to a much better PostgreSQL support.

My personal opinion is: Wait for the release of Spacewalk version 1.2 and lets give it a try. As Miroslav pointed out, Spacewalk needs more commitment from the community. Let us help him and and the other Spacewalk developers with bug reports and possibly some corrections of the database scheme.

Have fun?

At the time when Spacewalk is stable with PostgreSQL support, I’m opening a bottle of champagne, at the time when Red Hat releases the first RHN Satellite release with “official” Support of PostgreSQL I’m opening a box a champagne!

We will have fun! Help debugging…