CentOS代替のVzLinux(VirtuozzoLinux)をインストールしてみた


2021/07/13追記

急にアクセスが増えてきたのでVzLinux 8.4の簡単な評価を先に書いておくと、Alma Linux, Rocky Linux, Oracle Linux の3つに対する優位点が、2021/07/13時点のVzLinuxには無いので、特に採用するべきではないと思います。

個人的にはOracle Cloudも使っているので、Oracle Linux 8を使っています。

仮想コンテナであるOpenVZに対応したvzlinux kernelが提供されているのであればVzLinuxを選択する理由にもなるのですが、インストールしてみた限りでは使えない
そして、VzLinux 8.4を「日本語」でインストールするとロケール関連の動作が怪しくなる、という明確な問題があるので、現時点ではプラスポイント0、むしろマイナス、という感じです。


以下本文です


このblogのOracle Linux関連記事にこんな広告が表示された。

画像

VzLinux」なんてものがあるのかと別途ググってアクセスしてみた。(直接リンク飛ぶと規約上微妙なので)

画像

VzLinuxは、Linuxベースの仮想コンテナのVirtuozzo とそのオープンソース版OpenVZ の作っているLinux ディストリビューションで、この仮想コンテナを動かすにはRHEL/CentOSやUbuntuのデフォルトカーネル設定ではダメなので、稼働できる形でコンパイルしたものを提供していたものをディストリビューションとしても提供し始めたような感じである。

これに関連してか「Virtuozzo Linux 8 Quick Start Guide」の「3.3. Updating the Kernel」には、カーネルのアップデートのために「yum update vzkernel vzkernel-devel」を実行する、とあるが、実際のVzLinux 8上しても、vzkernelというパッケージは存在せず実行できない。

おそらくは、仮想コンテナVirtuozzo/OpenVZ用に提供されているバージョンであればvzkernelを使う、という話なんだろう、と思われる。

それはさておき、仮想環境にインストールしてみた。

VzLinux 8.3の時点ではセキュアブート非対応であるため、仮想マシンもそのように設定して起動。(VzLinux 8.4でもセキュアブート非対応であった)

画像

言語の選択で「日本語」を選ぶことができるが、インストール完了後、X-Windowアプリの一部でアプリ起動に失敗するので、基本的には「English」で進めた方が良いようだ。

(画像は日本語で進めた時のもの)

画像

基本的にはRHEL8/CentOS8そのままの表示である

画像

選択が終わったらインストール開始

Server with GUIでインストールした場合は下記の様になる。

画像

「日本語」を選択した場合、「端末」を選択すると、こんな感じでぐるぐる表示がされるものの端末は開かない。

/var/log/messagesを開くと「failback ‘C’ locale」という表示が出ているので「localectl list-locales」で確認すると、日本語に関するlocaleがインストールされていない。

というわけで、日本語に設定している場合は「dnf install glibc-langpack-ja」で日本語localeを追加するか、「localectl set-locale en_US.utf8」を実行して英語設定にする必要がある。

英語環境であれば下記の様に端末が正常に開く。

日本語localeを追加した場合も正常に端末が開くようになる。

画面を比較してみると、日本語locale追加以前は時刻表記が英語のまま、などの動作していましたね・・・


さて、kernel 4.18.0-305.vl8.x86_64 で起動してきている。

また、2021/06/16時点ではISOは8.3であったものの、updateすると8.4になった。

VzLinux 8のデフォルトレポジトリはこんな感じで、理由がよく分からないが「BaseOS」や「AppStream」などが無効化されており、「VirtuozzoLinux Base」と「VirtuozzoLinux Updates」のみが有効となっている。

ちなみにbaseos,appstream,plus,powertoolsを有効にしてみたが、vzkernelというパッケージは存在しませんでした。

とりあえずは、セキュアブート不要であれば使えるCentOS8代替としては使えそうです。


vzkernelはやはりOpenVZ対応カーネルな模様で https://src.openvz.org/projects/OVZ/repos/vzkernel/browse で開発されていました。(ブランチの選択肢に branch-rh8-4.18.0-240.1.1.vz8.6.x-ovz なんてものが見える。

また、 https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/ で openvz-iso-7.0.16-552.iso という形でOpenVZ用カーネルで起動するRHEL7互換のものが配布されている。

proxmox/openvzでCentOS7のコンテナを作ったけど通信ができない



Debianベースの仮想化環境Proxmox VEは、KVM/qemuベースのハードウェア仮想と、OpenVZのコンテナ仮想の2種類が使用できる。

このうち、OpenVZのコンテナの方で、CentOS7を作ったところ、通信が行えないという現象が発生した。

元となるCentOS7のOpenVZテンプレートは、「OpenVZ公式 Download/template/precreated」から入手した。

で、普通に導入して起動してみると、IPアドレスが割り当てられていない。

root@proxmox:~# vzctl start 777
Starting container ...
Container is mounted
Adding IP address(es): 192.168.35.20
vSetting CPU units: 1000
Setting CPUs: 2
zContainer start in progress...
root@proxmox:~# vzctl enter 777
entered into CT 777
[root@centos7 /]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.1/32 scope host venet0
[root@centos7 /]#

検索してみると、すぐに情報が出てきた。
NO IP ADDRESS IN PROXMOX OPENVZ CENTOS 7 CONTAINER

RHEL/CentOS 7.1におけるバグで、「Bug 1207975 – ifup-aliases does not proper catch arping failure」にて修正されているとのこと。

起動時にネットワークを有効化している /etc/sysconfig/network-scripts/ifup-aliases 内の

if ! /sbin/arping -q -c 2 -w ${ARPING_WAIT:-3} -D -I ${parent_device} ${IPADDR} ; then

という条件式の書き方に問題があるようで

/sbin/arping -q -c 2 -w ${ARPING_WAIT:-3} -D -I ${parent_device} ${IPADDR}
if [ $? = 1 ] ; then

と2行に分けることで回避できるとのこと。

なので、起動しているコンテナ内の/etc/sysconfig/network-scripts/ifup-aliasesを書き換えることで対処できました。

[root@centos7 ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/void
    inet 127.0.0.1/32 scope host venet0
    inet 192.168.35.20/32 brd 192.168.35.20 scope global venet0:0
[root@centos7 ~]#

Debian/proxmoxでのmpt-statusdによるRAIDステータスの監視



リモートでやるのが怖くて、実施できていなかったProxmoxのメジャーバージョンアップを実施した。

Debianのメジャーバージョンアップ、ということになるのだが、案の定、失敗。
(アップデートに必要なファイル群が404エラーで取得できなかった)
調査が面倒だったので、さくっと消去して新バージョンで再インストールした。

で、使用しているサーバはLSI Logic系のRAID/SCSIカードを使っているので、mpt-statusdによるRAIDステータス監視が行える。

古いバージョンのときは、以下のような/etc/default/mpt-statusdを書いていた。

# cat /etc/default/mpt-statusd
modprobe mptctl
ID="3 -n"
#

(「modprobe mptctl」を書かないと/dev/mptctlが作られず、mpt-statusがエラーになる)

通常は「ID=”3″」にするのだと思うが、これだと、syncのパーセンテージとかが表示されないという欠点がある。

root@ns5:/etc/init.d# mpt-status -i 3
ioc0 vol_id 3 type IM, 2 phy, 231 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 9 ATA      WDC WD2502ABYS-1 3B04, 232 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 4 ATA      WDC WD5000AAJS-5 3B01, 465 GB, state ONLINE, flags NONE
#

このため、syncのステータスが表示される「-n」オプション付にすることにしていた。

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: OPTIMAL flags: ENABLED
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 100%
scsi_id:1 100%
#

同期中のサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED RESYNC_IN_PROGRESS
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 1 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: OUT_OF_SYNC sync_state: 1 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 1%
scsi_id:1 1%
#

壊れているときのサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED
ioc:0 phys_id:1 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:0 scsi_id:4 vendor: product_id: revision: size(GB):232 state: MISSING flags: OUT_OF_SYNC sync_state: 100 ASC/ASCQ:0x00/0x00 SMART ASC/ASCQ:0x00/0x00
scsi_id:1 100%
scsi_id:0 100%
#

これで問題ないだろうと思っていたのですが、ステータス変化が無くても2時間おきにメールが・・・

mpt-statusdってどういう仕組みなのか/etc/init.d/mpt-statusdの中身を確認・・・
単純に一定時間間隔でmpt-statusコマンドを実行し、その結果を比較しているだけ、と判明。

        if (mpt-status -i $ID) |grep -q 'state OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

今回、問題となっているのは上記の部分だった。
-nのときは「state: OPTIMAL」と、コロン入りのステータス表示になっているためだった。

なので、下記のように「state: OPTIMAL」を見るように変更することで解決した。

        if (mpt-status -i $ID) |grep -q 'state: OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

Proxmox VE 3.1のリリースおよびソフトウェア更新に変更あり



うちの環境で使用しているProxmox Virtual Environment(Proxmox VE)に、最新版のProxmox VE 3.1が出た。
Proxmox Virtual Environment 3.1 Released

大きな変更点がある。

5月リリースのProxmox VE 3.0で、ベースOSがDebian 7.0 (Wheezy)に切り替わり、それに伴いいろんな変更があった。

今回のProxmox VE 3.1では、Release Historyでは記載されていないが、リリース告知では記載されている重大な変更点がある。

それは「Enterprise Repository」の開始である。

New Enterprise Repository
Proxmox Server Solutions – maintainer of the Proxmox VE repositories – introduces two new package repositories named “pve-enterprise” and “pve-no-subscription”. Beginning with Proxmox VE 3.1, the default repository is the Proxmox VE Enterprise repository. It allows secure access to stable updates, security patches and bug-fixes and is available to subscription users only. Proxmox VE users who do not want to use the subscription service can access the packages via the “pve-no-subscription” repository. These packages are not heavily tested, therefore the No-subscription repository is not recommended for production servers.

いままでは、サポートを買わなくても、ソフトウェア更新は普通にあるし、特に問題を感じなかったのですが、さすがにアレだったようで、「無償ユーザ向けソフトウェア更新(Proxmox VE No-Subscription Repository)」と「有償ユーザ向けソフトウェア更新(Proxmox VE Enterprise Repository)」に分割されました。

Proxmox Wiki「Package repositories」から実際のpve-no-subscriptionで配布されているソフトウェア一覧を見てみると、無償ユーザであっても基本的な機能は提供される模様。
有償ユーザ向けには、どのようなソフトウェアが配信されるのかは、特に記載が見当たらないというのが謎です・・・

有償ユーザには、どれくらいの金額からなれるのか確認してみると、「Subscription Plans」によれば、最低ラインは「Community Edition」で月額「1CPUあたり4.16ユーロ」とのこと。
この価格は、Proxmox VE 3.1リリースに合わせて半額以下になっています。(いままでは、月額「1CPUあたり9.90ユーロ」)

とりあえずは無償ユーザでProxmox VE 3.1へのアップデート実施かな・・・と


2013/09/05追記

Details about the new pve-no-subscripton repository

Proxmox上のOpenVZ仮想マシンをCLIでlive motion



Proxmox 2.xでは、共有ディスク無しでのホストサーバ移行(Live Motion/vMotion)みたいなことができる。
Web GUIでの方法はわかったが、CLIでのやり方についてのドキュメントが見つけにくく難航した。

使用するコマンド「pvectl」

ただし、このコマンドは、自サーバ上のみのコントロールを担当する。

「pvectl list」で、サーバ上にある仮想マシンリストを表示

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       102 server2.osakana.net  running    1280       30.00
#

他にもサーバがある場合は以下の様な形で他サーバに対してssh経由でコマンドを発行して状態を取得する。

root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

移動させる時は「pvectl migrate VMID サーバ名 -online」

root@ns5:~# pvectl migrate 101 pve2 -online
Jan 31 15:56:51 starting migration of CT 101 to node 'pve2' (192.168.1.102)
Jan 31 15:56:51 container is running - using online migration
Jan 31 15:56:51 starting rsync phase 1
Jan 31 15:56:51 # /usr/bin/rsync -aHAX --delete --numeric-ids --sparse /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:31 start live migration - suspending container
Jan 31 15:57:31 dump container state
Jan 31 15:57:32 copy dump file to target node
Jan 31 15:57:32 starting rsync (2nd pass)
Jan 31 15:57:32 # /usr/bin/rsync -aHAX --delete --numeric-ids /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:35 dump 2nd level quota
Jan 31 15:57:35 copy 2nd level quota to target node
Jan 31 15:57:36 initialize container on remote node 'pve2'
Jan 31 15:57:36 initializing remote quota
Jan 31 15:57:37 turn on remote quota
Jan 31 15:57:38 load 2nd level quota
Jan 31 15:57:38 starting container on remote node 'pve2'
Jan 31 15:57:38 restore container state
Jan 31 15:57:39 removing container files on local node
Jan 31 15:57:40 start final cleanup
Jan 31 15:57:40 migration finished successfuly (duration 00:00:49)
root@pve1:~ #

で、うちの環境だと、CPUがpve1はIntel, pve2がAMDなので、移行後の起動に失敗する。
なので、別途、起動させる必要がある。

root@pve1:~# ssh root@pve2 pvectl start 101
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.201
Setting CPU units: 1000
Setting CPUs: 1
Container start in progress...
root@pve1:~#

これで、以下のような感じで移行が完了する。

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       102 server2.osakana.net  running    1280       30.00
root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

さて、この処理を自動化すると・・・

#!/usr/bin/bash

SERVER=pve2
for vid in `pvectl list 2>&1 |grep running | awk '{ print $1 }'`
do
  echo === $vid ===
  echo pvectl migrate $vid $SERVER -online
  pvectl migrate $vid $SERVER -online
  ssh root@$SERVER pvectl list 2>&1 |grep  stop | grep $vid
  echo ssh root@$SERVER pvectl start $vid
  ssh root@$SERVER pvectl start $vid
done

ほんとは、移行後に起動しているか確認した上で、pvectl startを実行させるべきなんだろうけど、起動状態でpvectl startを実行しても影響がないので、無視している。