October 2009 – Page 2

IBM SVC: Copy VDisk Host-Mapping from one host to another

October 11, 2009August 8, 2014 Christian 1 Comment

As I wrote a few days ago, I started a new job. One of my first (voluntary) tasks was writing a shell script which would copy a VDisk Host-Mapping from a given host to another. This is useful, if you do have a lot of ESX servers for example and a few roaming ones.

Now, if say, you need to do some ESX-Updates and you would like to add the roaming one to a given farm, you would be in a dark an deary place. You would be required to either click through the GUI a dozen times (in my case, it might have needed ~200 clicks) or type svcinfo lshostvdiskmap <examplehosthere> and svctask mkhostvdiskmap <newhosthere> -force (these are incomplete command references) a few times.

Both methods ain’t optimal nor fast. Since the SVCTools (Perl, jikes) don’t really came into consideration, and the SVC SSH interface really doesn’t provide any other method to do a simple cut -d: -f3 (as a hint: if anyone knows a nice method to emulate cut with bash patterns — yeah, I ain’t kidding — please drop me a note!), I ended up writing a simple shell script which is gonna do all the tasks from any Linux system (in possession of the SSH DSA private keys for the SVC of course).

The script looks like this:

#!/bin/bash

svc_cluster_ip=10.0.0.10
svc_priv_dsa=~/.ssh/id_dsa_svc

if [ -n $2 ] ; then
  echo " copyvdiskhostmap.sh [ host_to | host_from ]"
  echo
  echo "  host_to    - Target host, for which we will create the VDisk map."
  echo "  host_from  - Source host, from which the VDisk map will be copied."
  echo
  exit 1;
fi

if [ ! -f $svc_priv_dsa ] ; then
  echo " copyvdiskhostmap.sh is missing the SSH DSA private key needed"
  echo "                     to access the SAN Volume controller."
  echo " Please specify the correct path!"
fi

host_to=$1
host_from=$2

for mapping in $( ssh -i $svc_priv_dsa admin@$svc_cluster_ip svcinfo 
  lshostvdiskmap -nohdr -delim : $host_from ); do
  vdisk_scsi_id="$( echo $mapping | cut -d: -f3 )"
  vdisk_name="$( echo $mapping | cut -d: -f5 )"
  
  ssh -i $svc_priv_dsa admin@$svc_cluster_ip svcinfo lshost $host_to || 
    echo "Failed, since the target host doesn't existent!" &amp;&amp; break
  ssh -i $svc_priv_dsa admin@$svc_cluster_ip svctask mkvdiskhostmap -force 
    -host $host_to -scsi $vdisk_scsi_id $vdisk_name
done

#!/bin/bash

svc_cluster_ip=10.0.0.10

svc_priv_dsa=~/.ssh/id_dsa_svc

if [ -n $2 ] ; then

echo " copyvdiskhostmap.sh [ host_to | host_from ]"

echo

echo " host_to - Target host, for which we will create the VDisk map."

echo " host_from - Source host, from which the VDisk map will be copied."

echo

exit 1;

if [ ! -f $svc_priv_dsa ] ; then

echo " copyvdiskhostmap.sh is missing the SSH DSA private key needed"

echo " to access the SAN Volume controller."

echo " Please specify the correct path!"

host_to=$1

host_from=$2

for mapping in $( ssh -i $svc_priv_dsa admin@$svc_cluster_ip svcinfo

lshostvdiskmap -nohdr -delim : $host_from ); do

vdisk_scsi_id="$( echo $mapping | cut -d: -f3 )"

vdisk_name="$( echo $mapping | cut -d: -f5 )"

ssh -i $svc_priv_dsa admin@$svc_cluster_ip svcinfo lshost $host_to ||

echo "Failed, since the target host doesn't existent!" && break

ssh -i $svc_priv_dsa admin@$svc_cluster_ip svctask mkvdiskhostmap -force

-host $host_to -scsi $vdisk_scsi_id $vdisk_name

done

SLES11 and AutoYaST

October 11, 2009June 21, 2013 Christian 1 Comment

After the first week passed awfully quick, the last week I worked on refining the way on how we are doing openSuSE / SUSE Linux Enterprise Server installations. Up till now, they were done by hand (without a predefined schema) and were getting ugly to maintain. Working my way through the Novell documentation on AutoYaST was pretty straight forward, but the little details were getting hairy. So I decided to write them down, in case someone was gonna end up in the same situation like me.

1. Understanding the folder layout
This isn’t a debate about how you should organize your file system(s), this is a reminder on how to design the AutoYaST profile … If (and probably when) you’re using rules, the layout of the profile directory mentioned in your autoyast PXE line should look like this:

Keep in mind, that profiles mentioned in your rules.xml, need to be placed in the parent folder, not in the rules folder itself.

2. Rules might not work as you think (ie installed_product)
If you work your way through AutoYaST, you are gonna get to the point where you can’t get around rules. Rules match specific parameters of the target system to a (sub) set of configuration parameters. Now, say you want to create a rule for systems on which you are about to install SUSE Linux Enterprise Server 11. The documentation tells us, to use something along the lines like this:

&lt;rule&gt;
   &lt;install_product&gt;
        &lt;match&gt;SUSE Linux Enterprise Server&lt;/match&gt;
   &lt;/install_product&gt;
   &lt;install_product_version&gt;
        &lt;match&gt;11&lt;/match&gt;
   &lt;/install_product_version&gt;
   &lt;result&gt;
        &lt;profile&gt;sles11.xml&lt;/profile&gt;
   &lt;/result&gt;
&lt;/rule&gt;

<rule>

<install_product>

<match>SUSE Linux Enterprise Server</match>

</install_product>

<install_product_version>

</install_product_version>

</result>

</rule>

You’re quickly gonna notice that you’re installation is gonna fail. Why ? Because Novell decided to drop the defined schema and use something else … The tag install_product, when performing an SLES11 installation doesn’t contain ‘SUSE Linux Enterprise Server‘ as you might think, but rather ‘SUSE Linux Enterprise Server 11‘ … notice the difference ? That and the default, that if no match-tag is given, it matches to the exact phrase. So the correct AutoYaST snippet should look likes this:

    &lt;!-- Installing SLES11 --&gt;
    &lt;rule&gt;
      &lt;installed_product&gt;
        &lt;match&gt;SUSE Linux Enterprise Server 11&lt;/match&gt;
        &lt;match_type&gt;regex&lt;/match_type&gt;
      &lt;/installed_product&gt;
      &lt;result&gt;
        &lt;profile&gt;sles11.xml&lt;/profile&gt;
        &lt;continue config:type=&quot;boolean&quot;&gt;true&lt;/continue&gt;
      &lt;/result&gt;
    &lt;/rule&gt;

<rule>

<installed_product>

<match>SUSE Linux Enterprise Server 11</match>

<match_type>regex</match_type>

</installed_product>

</result>

</rule>

Another hint when trying to match for SUSE Linux Enterprise Server 10 — say you wanna deploy SLES10SP2. Make sure you make a regex match for that, since — as you might have guessed, I didn’t at first — the install_product tag seems to contain SUSE Linux Enterprise Server 10 SP2 ❗

    &lt;!-- Installing SLES10 --&gt;
    &lt;rule&gt;
      &lt;installed_product&gt;
        &lt;match&gt;^SUSE Linux Enterprise Server 10&lt;/match&gt;
        &lt;match_type&gt;regex&lt;/match_type&gt;
      &lt;/installed_product&gt;
      &lt;result&gt;
        &lt;profile&gt;sles10.xml&lt;/profile&gt;
        &lt;continue config:type=&quot;boolean&quot;&gt;true&lt;/continue&gt;
      &lt;/result&gt;
    &lt;/rule&gt;

<rule>

<installed_product>

<match>^SUSE Linux Enterprise Server 10</match>

<match_type>regex</match_type>

</installed_product>

</result>

</rule>

3. Asking questions during the installation
If you’re in need of asking questions (like “Please enter the hostname” or “Please supply the root password”), you’re gonna need a bit of understanding as well as a few tricks:

  &lt;general&gt;
    &lt;ask-list config:type=&quot;list&quot;&gt;
      &lt;listentry&gt;
        &lt;default&gt;xxx.home.barfoo.org&lt;/default&gt;
        &lt;pathlist config:type=&quot;list&quot;&gt;
          &lt;path&gt;networking,dns,hostname&lt;/path&gt;
        &lt;/pathlist&gt;
        &lt;question&gt;Enter Hostname&lt;/question&gt;
      &lt;/listentry&gt;
      &lt;listentry&gt;
        &lt;help&gt;Enter the password for the superuser &quot;root&quot;.&lt;/help&gt;
        &lt;password config:type=&quot;boolean&quot;&gt;true&lt;/password&gt;
        &lt;path&gt;users,0,user_password&lt;/path&gt;
        &lt;question&gt;Enter root password&lt;/question&gt;
        &lt;stage&gt;initial&lt;/stage&gt;
        &lt;title&gt;Password for Root&lt;/title&gt;
      &lt;/listentry&gt;
    &lt;/ask-list&gt;
  &lt;/general&gt;
  ...
  &lt;users config:type=&quot;list&quot;&gt;
    &lt;user&gt;
      &lt;fullname&gt;root&lt;/fullname&gt;
      &lt;gid&gt;0&lt;/gid&gt;
      &lt;home&gt;/root&lt;/home&gt;
      &lt;shell&gt;/bin/bash&lt;/shell&gt;
      &lt;uid&gt;0&lt;/uid&gt;
      &lt;username&gt;root&lt;/username&gt;
    &lt;/user&gt;
  &lt;/users&gt;

<ask-list config:type="list">

<default>xxx.home.barfoo.org</default>

<path>networking,dns,hostname</path>

</pathlist>

<question>Enter Hostname</question>

</listentry>

<help>Enter the password for the superuser "root".</help>

<path>users,0,user_password</path>

<question>Enter root password</question>

<stage>initial</stage>

<title>Password for Root</title>

</listentry>

</ask-list>

</general>

...

<user>

</user>

</users>

4. Working with scripts
Once you get to the point, where you want to embed scripts into the AutoYaST profile, you might up in a situation where YaST literally shoots you in the foot. If you (like me) utilize different profile, and in each profile define a script, YaST is gonna overwrite the tags from the other profile. This sucks, and I ended up placing a dummy script into my master profile.

4. Debugging the rules merging process

Well this is quite troublesome. There is no easy way to do this, no GUI or script telling you what the resulting AutoYaST xml is gonna look like. There are a few helps (like the xsltproc call mentioned in the FAQ — or looking at the output of /var/log/YaST2/y2log concerning your rules.xml) but other than that there really is just fiddling with it.

Right now, I’m stuck working on the determination whether or not the system YaST is about to install happens to be inside a VMware virtual machine or not (simply looking at the MAC address should suffice).

But again, as mentioned in the second point, Novell apparently lacks some consistency. The handbook states the rules tag mac would contain the MAC address … apprently not, the mac-tag is empty … Which leads us to using a custom rules script fiddling with ip, a bit of grep and a simple echo, which works quite well. Just make sure, that you move the output of your script to /dev/null, otherwise you’re gonna sit there and end up trying to figure out why the hell the script works on the command line, but not within an AutoYaST installation …

Loooong time

October 10, 2009June 21, 2013 Christian 1 Comment

It’s been very quiet around here, I’ve been rather busy with my real life. During that busy time, a lot of things happened. I switched jobs starting on October 1st, I’m now working in Karlsruhe (as compared to the 870km northern Greifswald). It may sound far, but it’s actually quite pleasant. You know, I was born down here (well not exactly here — 70 kilometers afar) and I still had the feeling that this is my home.

My tasks haven’t changed that much, I’m still doing

VMware Virtual Infrastructure (as compared to vSphere)
IBM Storage / Brocade SAN (was IBM Storage / Cisco SAN)
Storage Virtualisation Controller (we were just buying that before I left)
SUSE Linux Enterprise Server 10/11 – Deployment and Management (is pretty much the same as before)

What I don’t do any longer is Windows. That is, per se not completely right, since Virtual Center only runs on Windows boxen, but pretty much my whole work focuses on Linux and Storage. It’s as I argumented in the the interview a step ahead, since I’m specializing myself into a certain direction (whether or not that works out — I can’t tell yet. Time is gonna tell me that).

In my first week I spent some time getting to know the co-workers, working my head into the SVC (I already had a somewhat theroretical — and practical — insight, but not deep enough to actually make do with it). Next on my list is the AutoYaST environment for SLES-boxen / Kickstart for ESX(i), which (hopefully) enables us to standardize server installations using common schemas and partitions layout.

Also on the list is building a two-node test environment for the SVC so we don’t break the live environment with some tests we might be doing. Next on the list is some accouting to bring the settlements for the resource utilization based on vCPU/vMem upon a solid, up to date foundation.

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31