1. /
  2. 2016年 12月

2016年 12月 の投稿一覧

Red Hat Enterprise Linuxを仮想化環境で動作させる時の注意点

Red Hat Enterprise Linuxを仮想化環境で動かすことが多くなっています。認定済みの環境一覧や認定外の環境での注意点、サブスクリプション管理用のvirt-whoデーモンについてご紹介します。

 

レッドハットの森若です。Red Hat Enterprise Linuxを仮想化環境で動かすことが多くなっています。物理サーバー単位で仮想マシンを作り放題のサブスクリプション製品がありますので、ご活用いただくシーンも増えています。

RHELで認定済みの仮想化環境や認定外の環境での注意点、サブスクリプション管理用のvirt-whoデーモンについてご紹介します。

無制限ゲストOS製品

レッドハットのサブスクリプション製品の中には、あるサーバー上で仮想マシンをいくつでも作成できる製品があります。主に以下の3種類の製品です(その他の製品とのセットなどもあるのでこの他にも存在します)。これらの製品は物理サーバのソケットペア(1つまたは2つのCPUソケットで、サーバ筐体をまたがない)毎に購入します。

  • Red Hat Enterprise Linux for Virtual Datacenters （仮想化環境はなしで、ゲストOSのみ)
  • Red Hat Enterprise Linux OpenStack Platform (OpenStack環境と無制限ゲストOSのセット)
  • Red Hat Enterprise Linux with Smart Virtualization (RHEV仮想化環境とゲストOSのセット)

サポート対象の仮想化製品

Red Hat Enterprise Linuxの動作が認定されている仮想化製品は以下に一覧が提供されています。

https://access.redhat.com/certified-hypervisors

virt-who

無制限ゲストOS製品を利用する時には、仮想マシンにインストールしたRed Hat Enterprise Linuxを登録するだけでなく、それぞれが動作しているハイパーバイザをサブスクリプション管理に登録することで適切に更新などが可能になります。

サブスクリプション管理の仕組みとして利用可能な仕組みとしては、カスタマーポータル、Red Hat Subscription Asset Manager、Red Hat Satelliteの3種類があります。

これらに対して「どのハイパーバイザでどの仮想マシンが動作しているか」という対応関係を知らせるために利用するのがvirt-whoデーモンです。virt-whoデーモンはRHELがサポートする仮想化環境である以下の4種類の仮想化環境に対応しています。

  • RHEL KVM
  • RHEV
  • VMware ESX, VMware ESXi
  • Microsoft HyperV

古いバージョンでは一部の環境への対応ができていないものがあります。詳しくは https://access.redhat.com/ja/articles/1283963 をごらんください。

 

virt-whoの使い方

それぞれの仮想化ホスト上に1つRHEL仮想マシンを用意のうえvirt-whoを実行し(RHEV-M または vCenterへ接続する場合にはクラスタ全体で1つあれば十分です)て、それぞれのホストを登録します。virt-whoデーモンの設定はファイル /etc/sysconfig/virt-who におこないます。仮想化環境の種類と、サブスクリプション管理の仕組みを指定します。

関連するナレッジベースの記事を以下に記載します。最初の「RHEL サブスクリプション (2013 パッケージ) の使用: シナリオ 5 仮想データセンター」に概要が記載されていますので、まずこの記事を確認してから各環境ごとのナレッジベースを確認するとわかりやすいです。

VMware環境上でのRed Hat Enterprise Linux 7.2以前から7.3へアップデート時の注意点と、その解説

2016年11月3日にリリースされたRHEL 7.3ではアップデートに関連した比較的大きな問題がありました。本記事では問題の概要と背景をご紹介します。

レッドハットの森若です。2016年11月3日にリリースされたRHEL 7.3ではアップデートに関連した比較的大きな問題がありました。概要は以下のようなものです。

——————————————————————————–

問題:
VMware環境上で動作している Red Hat Enterprise Linux 7.2以前の環境を、7.3へアップデートするとインタフェース名が変わり、再起動時にネットワークのセットアップに失敗する場合があります。

解決策1:
RHEL 7.3に更新したあと再起動せずに、systemdパッケージを systemd-219-30.el7_3.6 以降のバージョンへ更新します。「RHEL 7.3に更新したあと再起動して問題が発生した」事後には、systemdパッケージのアップデートは効果がありません。

解決策2:
既に問題が発生した場合、ネットワーク設定を変更する必要があります。詳しい手順はナレッジベース内「RHEL 7.3 にアップデートした後にインターフェイス名が変更になり、ネットワークが起動しない」https://access.redhat.com/ja/solutions/2756581 をご確認ください。

※ ISOイメージによる更新の場合には現在でもこの問題が発生します。

——————————————————————————–

さて今回はこの問題の背景を見ていきます。

systemdによる予測可能なNetwork Interfaceの命名

systemdはハードウェアの接続情報を元に一貫したNetwork Interfaceへの命名を行っています。たとえば「eno1」のような名前がつき、Ethernet(en)のオンボード(o)で1ポート目(1)のような名前がつきます。このような構成情報はファームウェアから提供されており、dmidecodeコマンドでも確認することができます。

Handle 0x001E, DMI type 41, 11 bytes
Onboard Device
        Reference Designation:  Onboard LAN
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:00:19.0

VMware環境でのインスタンス番号

この番号について、VMware環境のファームウェアは異常に大きなインスタンス番号を報告します。1600万番前後の数になります。RHELの7.0から7.2までは、この番号を素直に利用した eno16780032 のようなNetwork Interface名を命名していました。

LinuxでのNetwork Interface名前長制限

ところがこの命名には、単純に長くて入力が面倒という以上の問題があります。Linuxには「Network Interfaceの名前は15文字まで」という制限があります。eno+数字8桁で11文字利用しているので、残りは4文字しか利用できません。たとえばこの時VLAN tag ID として1000を利用するためのインタフェースを作成しようとすると、”eno16780032.1000” のようになってほしいところですが、”eno16780032.100”となってVLAN tag IDとして100や1005を使うインタフェースと名前が衝突してしまいます。

systemdが採用したワークアラウンド

RHEL 7.3のsystemdでは、この問題に対するワークアラウンドとして、オンボードのNICで16384番より大きい番号が与えられた場合はスロット番号またはバス番号を元にした名前を付与するよう変更されました。

udevadmでNetwork Interfaceの情報を見てみると、ID_NET_NAME_ ではじまるエントリが複数あることがわかります。

# udevadm info /sys/class/net/eno16780032
P:/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/eno16780032
E:DEVPATH=/devices/pci0000:00/0000:00:16.0/0000:0b:00.0/net/eno16780032
E:ID_BUS=pci
E:ID_MODEL_FROM_DATABASE=VMXNET3 Ethernet Controller
E:ID_MODEL_ID=0x07b0
E:ID_NET_DRIVER=vmxnet3
E:ID_NET_LABEL_ONBOARD=enEthernet0
E:ID_NET_NAME_MAC=enx005056a570ba
E:ID_NET_NAME_ONBOARD=eno16780032
E:ID_NET_NAME_PATH=enp11s0
E:ID_NET_NAME_SLOT=ens192
E:ID_OUI_FROM_DATABASE=VMware, Inc.
E:ID_PATH=pci-0000:0b:00.0
E:ID_PATH_TAG=pci-0000_0b_00_0
E:ID_PCI_CLASS_FROM_DATABASE=Network controller
E:ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E:ID_VENDOR_FROM_DATABASE=VMware
E:ID_VENDOR_ID=0x15ad
E:IFINDEX=2
E:INTERFACE=eno16780032
E:SUBSYSTEM=net
E:SYSTEMD_ALIAS=/sys/subsystem/net/devices/eno16780032
E:TAGS=:systemd:
E:USEC_INITIALIZED=28864

NetworkManagerのconnection識別方式

NetworkManagerでネットワークを初期化する際には、設定にNetwork Interface名とMACアドレスが含まれていると、MACアドレスにあわせて指定された名前にリネームして初期化を行います。しかしMACアドレスが含まれない場合はNetwork Interface名が一致しなければ初期化がおこなわれません。

このため、NetworkManagerによる設定を利用しており、RHEL 7.0から7.2まででNetwork Interfaceを設定したのち、MACアドレスの設定を含まないよう設定し、7.3へアップグレードして設定を修正せずに再起動すると初期化に失敗します。

systemd-219-30.el7_3.6で導入されたワークアラウンド

この問題は出荷翌日の11月4日に発見され、ワークアラウンドを含んだ systemd-219-30.el7_3.6 が11月9日に出荷されました。この中で利用されているワークアラウンドは、systemdパッケージ更新時に以下のような内容のスクリプトを実行することにより対応しています。

もしこの問題の影響をうける(enoではじまり16378より大きな数で終わる名前の)インタフェースがある場合、udevのルールに「現在のMACアドレスを持つ場合に現在と同じインタフェース名に名前をつけかえる」というエントリを追加します。

これにより、影響をうけるアップデートの場合にのみインタフェースの名前を維持する対策が行われます。注意点として、この状態の仮想マシンをクローンするなどでMACアドレスが変更されるとインタフェース名が新しいポリシーによるものに変わります。