長い事 SUSE Linux をやっていると、 YaST GUI にあまりにも慣れすぎてしまって、すっかりキーボードをたたく事に億劫になってしまいます。Linux やってるエンジニアがキーボードにこだわるのはわかりますが、私は SUSE Linux 使う上ではマウスにこだわるヒトになってしまいました。
良くテレビドラマやニュースの資料映像なんかで、ブラインドタッチがやたらと早くて、マウスなんて全然つかってないじゃないか、という資料映像みたいなシーンを見ますが、私にはわかる。
「嘘だ、演技だ」
特に「ハケンの品格２」の篠原涼子のキーボード叩く演技は下手だったなぁ。ブラインドタッチになってない。ただ指がキーボードの上を撫ぜてるだけで「スーパー派遣」の品格がなかった。下手なビデオのオフィスシーンの方が演技している場合があるンですよ。
逆にマウスを使いこなしているシーンを見ると「演技っぽくなくリアル」に思えてくるものです。
それくらいいまの時代、マウスは重要です。
まぁ与太はそこまでにして
ー virt-manager GUI で KVM ゲストのライブマイグレーション
というのが今回のテーマです。
随分と昔に XEN 環境＋ iSCSI NAS を使ったライブマイグレーションをやた事を思い出します。
iSCSI 上に仮想イメージを導入し、ついでに Live Migration してみる
時は移り変わり、まず XEN は見なくなったし SUSE でも XEN から KVM への移行ガイドを用意するくらい、仮想化と言えばすっかり KVM の時代になってしまいました。
かわいそうな Citrix ....
今回は SUSE Linux Enterprise 15.0 と openSUSE Leap 15.2(gnome) 上で KVM が稼働しているので、それぞれライブマイグレーションしてみました。virsh migrate --live .... コマンドではなく、 virt-manager、 GUI を使います。
※ SLE 側は gnome Desktop のみです。openSUSE Leap 側も gnome Desktop を使っています。
ー リモート virt-manager に接続
openSUSE Leap 15.2 側の X 端末から Virtual Machine Manager GUI. を起動して、別なハイパーバイザー(SLES15 KVM)側に接続します。
# virt-manager &
openSUSE より File > Add Connection から、SLES の KVM ハイパーバイザーにログインします。そうするとエラー。
openssh-askpass パッケージが要求されます。
yast を見ると ssh-askpass は既にインストールされていますが、ssh-askpass-gnome はインストールされていないため、追加インストールします。
openSUSE Leap 16.2 では標準リポジトリに openssh-askpass, openssh-askpass-gnome が標準で含まれているため、zypper か YaST でインストールするだけです。
接続先のパスワードが要求されました。
リモートハイパーバイザーに接続できました。
稼働中のVMをポイントして右ボタンから Migrate をします。
今回はネットワーク上の共有ストレージ（iSCSI や NFS）を使っていない（単にイメージをSCP コピーしただけの手抜き）ので、エラーとなりました。Advanced Option の中に Allow unsafe のチェックボックスがあるのでこれをチェックして、強引にマイグレートしてみます。(敗因)
無事、SLE のインスタンスを openSUSE Leap 側に移行出来ました。
ー よくあるトラブル
よくあるトラブルとして、移行元、移行先のディレクトリ構造が違ったり、移行先に、仮想イメージがマウントしているインストールDVDメディアがないなどが原因で移行出来ないトラブルがあります。使わないハードウェアは外しておきます。VM のコールドブートが必要ですけど...
ー 頻繁に認証を求められる
リモートハイパーバイザーにアクセスすると、頻繁に root パスワードを求めてきました。原因／意味不明です。ちょっと実用的ではないですね。(敗因)
ー SLE の場合
SUSE Linux enterprise (SLES) 15 の場合、openssh-askpass, openssh-askpass-gnome は標準リポジトリに含まれないため、software.opensuse.org より１クリックインストールするか、expert Download にある指示に従って、リポジトリの追加、インストール
します。
openssh-askpass-gnome
openssh-askpass
zypper addrepo https://download.opensuse.org/repositories/openSUSE:Leap:15.2:Update/standard/openSUSE:Leap:15.2:Update.repozypper refreshzypper install openssh-askpass-gnome
zypper addrepo https://download.opensuse.org/repositories/openSUSE:Backports:SLE-15-SP3/standard/openSUSE:Backports:SLE-15-SP3.repozypper refreshzypper install openssh-askpass
zypper でインストールできない場合は YaST のソフトウェア管理 (YaST Software Management) でインストールできました。
opensuse152:~ # rpm -qa openssh*openssh-askpass-1.2.4.1-bp153.1.3.x86_64openssh-askpass-gnome-7.6p1-7.13.x86_64openssh-helpers-7.6p1-7.8.x86_64openssh-7.6p1-7.8.x86_64opensuse152:~ #
今度は openSUSE Leap に移動した、VM インスタンスを SLE 側に戻しました。
よくあるトラブル
ー 移行先のメモリが足りない
メモリアロケーションエラーになります。メインで使っているハイパーバイザーの稼働率が高く、８割程度でパツンパツンのところに、無理してマイグレートしないことです。不要不急のVMインスタンスをシャットダウンして、移行させるとうまく移行できます。
そもそもライブマイグレートは負荷の高い、ミッションクリティカルなサービスを移動させるのが本質的な目標なので、インスタンスを止めるのは本末転倒かもです。
ー 必ずネットワークの共有ディスクを使うこと、バックアップは重要
今回は手抜きして、 QEMU のイメージと XML ファイルを SCP コピーして、マイグレートしましたが、できたできたと喜んでマイグレートしてたら、遂にブートローダーが壊れて起動できなくなりました。まぁ今回はテスト環境で、スレーブ用DNSサーバーだったので笑って済ませますが、本番環境がこの様な事では済まされません。
必ずバックアップを取って、共有ディスクからマイグレートします。
ー 異なる環境ではマイグレートできない
インスタンスのイメージがあるディレクトリなど環境は必ず揃えること。特に、インスタンスを作ったときのインストールDVDメディアは、仮想ハードウェアから削除しておくことです。
ー ２つのハードウェアの違いはあるか
ライブマイグレーションの大きな課題としては、双方のハードウェアアキテクチャに大きな違いがあってはいけないことです。一度 XEN 時代にテストしたのですが、AMD アキテクチャから Intel マシンの移行は、コールド移行もできませんでした。同じ Intel 系でも、CPU世代が大きく違ったりする場合のライブマイグレーションがどの程度成功するかは未知数です。どれだけ環境が異なると移行できないかは経験を積むしかないでしょう。
また移行先のハイパバイザーが古かったりOSベンダーが異なると、成功の可能性は低そうです。
例えば、最新の XEON プロセッサ搭載サーバーから、数年前の古い Core i3 の古いデスクトップ応用PCへの移行がうまく行くとは思えません。コールドマイグレーションでさえ失敗しそうです。逆のケースではうまくいきそうなきがします。（ ...そう思っているだけですが… ）
いずれにせよ、いざと言う時にライブマイグレーションがおこなえるかどうか、システムを止められる機会に、計画的にテストしておく事が重要です。
ー まとめ
ライブマイグレーションは万能の機能ではありません。想定していなかった設定ミスで失敗したり、
起動できなくなるというトラブルもありました。個人的にはサービス停止が、１０分許されるなら、イメージの別 HV へのコピー、サービス 再起動でいい。仮想化マイグレーションは、運用技術としては自己満足に陥りやすい危険性があります。
ただし、せっかくハイパーバイザー運用するつもりなら、キチンと iSCSI などの共有ストレージを作って２つ以上の HV 運用を検討すべきでしょう。いざという時に提供される手段だし、緊急時のオペレーションテスト、訓練も重要です。
また、「小＞大」、「古＞新」のマイグレーションは成功の可能性が高いのでしょうが、新しいサーバーから古いハイパーバイザーハードウェアへの移行はかなり不安があります。いずれにせよ行き当たりばったりのチャレンジは避けた方がよさそうです。
今回は、SUSE Linux15(SLE/openSUSE Leap) で GUI からライブマイグレーションをテストしてみました。実用性、可用性はギリギリ合格点。 実運用には Open stack などを検討すべきでしょう。
また、SLE ではなく openSUSE Leap 15.2 をつかってみた初めての KVM ですが、使用感は SLES とそれほど変わらないので、ミッションクリティカルではないシーンでは openSUSE Leap でも充分かなと感じました。
▲
by islandcenter
| 2021-01-01 20:56
| SUSE
|
Comments(0)
2020年 12月 09日
openSUSE15.2 x86-64 環境でARMのクロスコンパイル
Apple M1 シリコン mac で脚光を浴びてしまった ARM アキテクチャ。「これからは ARM の時代かも」なんちゃってです。
という事で openSUSE 15.2 x86-64 環境でどこまで ARM の開発環境、エミュレーション、仮想化などができるか調べてみました。
はじめは
「Linux の x86-64 環境で ARM の仮想環境作れないかなぁ」
という不純な動機だったのですが、どうも KVM なんかで動く ARM のイメージなんてないわけですね。で色々調べてみたら、クロス開発環境や、バイナリのエミュレーションはできるらしい。ほとんどの情報は Ubuntu 上でのクロス開発環境なんですが、これ openSUSE でできないかという課題です。
昔、マイコン機器を開発してた頃は、クロス開発で、x86 のC言語を Sparc でクロス開発していました。実に快適でした。実機だと１時間かかる「コンパイルとリンク」がわずか一分で終わってしまう。コーヒーとトイレに行こうと立ち上がった時には終わっている。感動というかのんびりした時代も終わったナ、と呆れたというかでした。
ARM の実機上で開発するとなると、いろいろな実機の制限や非力な実機スペックでは中々開発も難しい。となると一般的な x86-64 PC 上でクロス開発する方が色々と都合がよろしいンでしょう。少なくとも、コードとドキュメントを書いて、コンパイルとリンクまではパワーのある Intel PC ワークステーション上で行い、実機なり ICE なりにバイナリを転送してデバックする。という事です。
当たり前かな、と思ったのですが意外と情報が少なかったので苦労しました。皆さんどうやって ARM の開発環境つくっているんでしょうか。まぁ参考までに openSUSE 15.2 でどこまでできるか、あまり開発系には詳しくない素人なので入門です。他のディストリビューションを使っている方にも参考になれば幸いです。
ー クロスコンパイラのインストール
software.opensuse.org へ行って cross-arm-linux-gnueabi-gcc パッケージを検索します。ここにありました。
cross-arm-linux-gnueabi-gcc
Expert Download のリンクを開きます。
Add repository and install manually にあるコマンドを実行します。
そのままだと余計な SLE のリポジトリも追加しようとしてエラーが出ましたが、無視してリポジトリをインストールします。
ー cross-arm-linux-gnueabi-gcc をインストール
zypper addrepo https://download.opensuse.org/repositories/home:duwe:crosstools2/openSUSE_Leap_15.2/home:duwe:crosstools2.repozypper refresh
Zypper かYast でインストールできます。
# zypper install cross-arm-linux-gnueabi-gcc
YaST の場合
# yast2 & もしくは# yast
から Software Management で ”cross” などをキーワードサーチしてインストールします。
SUSE では /opt/cross にインストールされます。
opensuse152:~/test # ls /opt/cross/arm-linux-gnueabi -altotal 0drwxr-xr-x 1 root root 64 Dec 8 13:26 .drwxr-xr-x 1 root root 136 Nov 6 03:45 ..drwxr-xr-x 1 root root 92 Dec 6 20:20 bindrwxr-xr-x 1 root root 6 Dec 6 20:20 includedrwxr-xr-x 1 root root 532 Dec 6 20:20 lib
ー stdio.h: No such file or directory となる
まずは「はじめてのC」を書きます。
opensuse152:~/test # cat test.c#include <stdio.h>int main(){printf("Hello World\n");return(0);}
コンパイルしてみます。
opensuse152:~/test # /opt/cross/bin/arm-linux-gnueabi-gcc -o armhello test.ctest.c:1:10: fatal error: stdio.h: No such file or directory1 | #include <stdio.h>| ^~~~~~~~~compilation terminated.opensuse152:~/test #
いきなり致命的な faital error です。
-v オプションを付けてコンパイルして「コンパイル中」の内容の詳細(verpose)をチェックします。stdio.h を探すと、ありました。どうもうまく見つけられない様です。
/opt/cross/arm-linux-gnueabi/include/c++/9.3.0/tr1/*
を
/opt/cross/arm-linux-gnueabi/include/c++/9.3.0/
に強引にコピー(cp)しました。
ー cannot find crt1.0: No such file or Directory ライブラリがない
インクルードヘッダファイルはコピーして一応通りましたが、リンクができません。 「crt1.o が見つからない」となります。どうも glibc が必要らしい、という事で arm 用の glibc ライブラリをインストールしました。ブラウザで software.opensuse.org へ行き、１クリックインストールします。
cross-arm-linux-gnueabi-glibc
１クリックインストールできなかったので YaST > Software Management から "glibc" を探して arm 用の glibc をインストールします。
opensuse152:~/test # find /opt/cross/ -name "crt1.o"/opt/cross/arm-linux-gnueabi/sys-root/lib/crt1.oopensuse152:~/test #
インストールされた様です。
opensuse152:~/test # /opt/cross/bin/arm-linux-gnueabi-c++ test.c -o testtest.c: In function ‘int main()’:test.c:4:2: error: ‘printf’ was not declared in this scope4 | printf("Hello World\n");| ^~~~~~test.c:2:1: note: ‘printf’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’?1 | #include <stdio.h>+++ |+#include <cstdio>2 | int main()opensuse152:~/test # ls -al test-rwxr-xr-x 1 root root 7976 Dec 8 13:33 testopensuse152:~/test #
相変わらず、ヘッダファイルの警告は出ますが、リンクまで通った様です。
バイナリの中身を確認します。
opensuse152:~/test # file testtest: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.2.0, not strippedopensuse152:~/test #
ARMのバイナリができました。
ー qemu-arm を openSUSE にインストール
結論から言うと挫折しました。
しかし、一応 openSUSE のリポジトリに qemu-arm があるのでインストールはできます。
openSUSE:Leap:15.2:Update プロジェクト提供の qemu-arm
opensuse152:~/test # qemu-system-arm --versionQEMU emulator version 4.2.1 (openSUSE Leap 15.2)Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developersopensuse152:~/test #opensuse152:~/test # qemu-system-arm -M ?Supported machines are:akita Sharp SL-C1000 (Akita) PDA (PXA270)ast2500-evb Aspeed AST2500 EVB (ARM1176)ast2600-evb Aspeed AST2600 EVB (Cortex A7)borzoi Sharp SL-C3100 (Borzoi) PDA (PXA270)canon-a1100 Canon PowerShot A1100 IS:: 以下略:opensuse152:~/test #
29.2 General qemu-system-ARCH Options
qemu-system-arm • helpQEMU emulator version 2https://helpmanual.io/help/qemu-system-arm/
どうも、エミュレーションに必要な、大量のパラメータが必要な様です。詰まった！
ここで挫折。
ー まとめ
x86-64 環境で。ARM のバイナリを動かせないか？という切り口から、なぜか「クロス開発なら openSUSE でもできる！」というオチになり、目標のバイナリエミュレーションまでには至らずでした。
しかし、ARM 以外にもクロス開発環境は豊富にありました。流石に z80 は有りませんが、PowePC から m68k まで揃っています。なるほどオープンソースって面白いなと改めて感じさせられました。
クロス開発環境は Debian/ubuntu 系が強いようですが openSUSE もできる訳ですね。ただし情報が少ないのが難点です。
▲
by islandcenter
| 2020-12-09 10:01
| SUSE
|
Comments(0)
2020年 11月 20日
ARMに失敗した Windows RT、 ARM ベースから無事ラウンチした Apple M1
ARM で失敗した Microsoft Windows RT, ARM で成功しそうな Apple macOS big Sur.
ー無事に出産されたApple M1ー
2020年秋、出荷された Apple M1 Mac + macOS big Sur に関しては、悪い評価を出しているメディアは、驚くべきことにほとんどないようです。実際にベンチマークを取ってみたら、結構早かったとか、Rosseta 2 によるバイナリ変換が始まる初回起動を除けば、インテルベースのバイナリでも、十分なパフォーマンスをだしているとか、そんな話に巷は溢れているのですね。
また、多くのメディア上のテスターが評価機として使っているのが、ベーシックモデルの Mac book Air なのです。
8Gb ユニファイドメモリ256 Gb ストレージ 104,800円（税別）という価格は、ほぼWindows PC より2〜3割は割高な Apple Mac にしては、お手頃感がすごい。私が初めて買った 1998 年発売の iMac ボンダイブルー iMac G3 178,000 円と同じくらい衝動買いしたくなる価格です。従来 Mac Book Air とデザインはほとんど変わらない代わり映えのない羊の狼とは言え、私なら消耗備品費で買える十万円切っていたら間違えなく Apple Store を開いていたでしょう。
このスペックで不満を言っているテスターが見当たらないのがまずすごい。
また、所詮モバイルプラットフォームと考えられていた ARM プラットフォームの意外な性能の高さを証明してくれた事です。所詮は「携帯電話向けSoC」と考えられていた ARM アキテクチャでも、きちんと正しくデスクトップワークに向く使い方ができることを macOS Big Sur で実現できるわけです。
しかし一番すごいのは、ARM ベースで無事ラウンチできたことなんですね。
ー飛べなかった鳥、ARM 版 SurfaceRT と Windows Mobileー
とりあえず安産となった Apple M1 に対して ARM と言えば遂に成層圏にも達せなかった Windows 系 ARM アキテクチャがあります。Surface RT (Windows RT) と Windows Mobile は見事に飛べない鳥でした。
飛べない鳥でも地を這うダチョウならまだしも、決め手となるべき Windows Store のっズッコケぶりが足を引っ張り、RT とWindows Mobile で使えるハズの UWP (ユニバーサルウィンドウズプラットフォーム)の立ち上げに失敗したのは頭が痛かった訳ですね。
共に ARM ハードウェアプラットフォームで動くわけですが、x86-64 バイナリが使えないのは痛かった。膨大なバイナリ資産を使えないハードウェアにはユーザは見向きもしないし、使えない Windows Mobile より Android や iPhone の方が、手軽で「使える」訳です。
ARM 版 Windows 10 もあるにはある（らしいことを初めて知った）が、これも x86-64 は動作せず、32ビット API しか動かないらしい。
「所詮モバイルプラットフォームの ARM で x86 のエミュレーションなんて無理」多くの Windows ユーザはそう考えるでしょうね。私もそう思っていました。でも Apple M1 はやっちゃった。そして一応のスタートアップ評価は○だった。ARM の評価が高いなんて、一般コンシューマには評価する手段が無かったンです。
ARM 版 Windows 10
ってか、そんなのがあることさえ知られていないわけだから、よほど誰も寄り付かないでしょうね。
ー魅力的だが食指が動かないんだ Apple M1 は（仮想化の問題）ー
もし、私の手元に自由に使える１０万円があり、あなたにオススメするPCは何かと聞かれれば、間違えなく「今なら Apple M1 Mac Book Air」と答えるでしょう。それほど魅力があるんです。
でも、インフラ系エンジニア（一応）のワタシ個人としては、やっぱり躊躇してしまうんです。
その理由は「仮想化」の問題なのですね。やっぱり仮想化と言えば XEN か KVM という事になり、x86系プラットフォームで作ったマシンイメージを移植する都合で、Apple によって非弱なイメージを持つに至った Intel プラットフォーム同士のマイグレーションができない。
もっとも、今のデータセンターで使われているインテルプラットフォームが大挙して ARM に移行すれば、それは自分のPC環境を ARM ベースに移行する理由になるのですが、どうもその気配がない。やっぱり 「Windows が動いてナンボ」の PC 業界ですから ARM ベースの自作PCやベアボーンが存在しないのはマイナス面が大きいわけなんです。探してもラズパイ位しかない。
しかし、インフラ系技術者が、顧客のシステムメンテナンスや必要なドキュメント作成に使えるコンピュータを選べ、となれば、やっぱり Apple M1 は一つの選択肢になるでしょうね。あえて Windows を選ばなければならない理由がなくなってしまったのです。
もし、アプリケーションベースの仮想化(VMware や Parallels)でもいいけど、Windows Hyper-V 並に XEN か KVM もどきの OS ネイティブの強力なハイパーバイザーが macOS Big Sur に実装されたらもうそれでいいわけですよ。
ARMへの移行で変わるMacの「仮想化」
もっとも、プロプライエタリな Apple が「GPL汚染」を避けることは明らかなので、当分は XEN, KVM とは互換性はあっても独自にハイパーバイザー開発するんでしょうね。
ーー
結局のところ、Windows が動いてナンボの PC 業界ですから、ARM 版に見事に失敗している Microsoft を見ていると、Wintel 連合はまだ巨大だ、と言うことだし、ARM 版 PC を期待する自分はやっぱりオカシイのかな、と思うわけです。でもねぇ、 Apple M1 の成功を見ていると、ARM ベースのPCとか期待しちゃうンですね。
でも、Apple M1 のラウンチぶりを見ていると、自作 PC やベアボーンキットが ARM で構成されて、その上で Linux やインストール可能な Chrome OS や Android なんかが出てくるようになれば、今の PC 業界もガラッと変わりそうなそんな気がします。何しろ ARM Apple M1 は意外なパフォーマンスの高さを mac と言う身近な世界で実力を示したンですね。
Apple M1+ macOS BIg Sur は PC業界、PCサーバー業界に ARM アキテクチャの可能性を実現してしまったのですね。
多分一番 ARM に食指を動かしているのは、電力消費に悩むデータセンター業界じゃないのかな？ と思います。
▲
by islandcenter
| 2020-11-20 20:23
| 雑文
|
Comments(0)
SLE15 p2 で私にとっては初めての"Docker" です。
- はじめに -
- 参考文書 -
- Forward を有効に -
- ユーザを Docker グループに
- 自動起動を Enable に
- hellow-world を run -
- YaST2-Docker -
- YaST2 docker -
- nginx HTTP を動かす -
- 起動時にコンテナを自動起動させる -
- 停止中のコンテナを削除
- 常時起動状態で起動
- その他 -
- まとめ -
- はじめに -
Docker は「コンテナ型の仮想化」言われればそれまでなのですが、 SUSE ではドキュメントも少なく、いまいち手が出なかった。だけど不思議なもので、どこかできっかけを掴むと、やってしまえるものですね。XEN から始めて KVM そして Docker です。切り口が分かれば、意外と簡単に入り込むことができました。
という事で SUSE Linux Enterprise 15 sp2(SLES15 sp2) に Docker を組み込んで nginx HTTP サーバーを動かしいてみよう、にチャレンジします。
SLE15 Linux Enterprise sp2 (SLES15sp2) のインストールとファーストルックhttps://islandcnt.exblog.jp/240410042/
- 参考文書 -
まずは、次の文書を読んでおきます。
openSUSE and SUSE Linux Enterprise
http://docs.docker.jp/engine/installation/SUSE.html
Docker Open Source Engine Guide SUSE Linux Enterprise Server 15 SP1
https://documentation.suse.com/sles/15-SP1/pdf/book-sles-docker_color_en.pdf
- /var/lib/docker を BtrFS の別パーティションに -
1 Docker Open Source Engine Overview REPORT DOCUMENTATION BUG#
このドキュメントに
"Important: Mounting /var/lib/dockerIt is recommended to have /var/lib/docker mounted on a separate partition or volume to not affect the Docker Open Source Engine host operating system in case of a file system corruption.In case you choose the Btrfs file system for /var/lib/docker, it is strongly recommended to create a subvolume for it. This ensures that the directory is excluded from file system snapshots. If not excluding /var/lib/docker from snapshots, the file system will likely run out of disk space soon after you start deploying containers. What's more, a rollback to a previous snapshot will also reset the Docker Open Source Engine database and images. Refer to Creating and Mounting New Subvolumes in Section 7.1, “Default Setup” for details."
とあり、/va/lib/docker は別パーティションで BtrFS 強く推奨とあります。事前に Docker を導入する以前にパーティションを YaST > System > Partitioner で別パーティション、別ボリュームを準備しておきます。
インストールの際の注意事項です。
sles15doker:~ # snapper -c dockersnap(<--任意のファイル名) create-config /var/lib/dockersles15docker:~ # ls /etc/snapper/configs/dockersnap -l-rw-r----- 1 root root 1183 Jun 28 17:08 /etc/snapper/configs/dockersnapsles15docker:~ #sles15docker:~ # ls /var/lib/docker/ -ltotal 0drwxr-x--- 1 root root 0 Jun 28 17:08 .snapshotsdrwx------ 1 root root 20 Jun 28 11:49 btrfsdrwx------ 1 root root 20 Jun 28 11:47 builderdrwx--x--x 1 root root 92 Jun 28 11:47 buildkitdrwx------ 1 root root 12 Jun 28 11:47 containerddrwx------ 1 root root 256 Jun 28 13:53 containersdrwx------ 1 root root 10 Jun 28 11:47 imagedrwxr-x--- 1 root root 10 Jun 28 11:47 networkdrwx------ 1 root root 20 Jun 28 11:47 pluginsdrwx------ 1 root root 0 Jun 28 05:39 runtimesdrwx------ 1 root root 0 Jun 28 11:47 swarmdrwx------ 1 root root 0 Jun 28 14:39 tmpdrwx------ 1 root root 0 Jun 28 11:47 trustdrwx------ 1 root root 22 Jun 28 11:47 volumessles15docker:~ #
SLES12 の Snapper のチューニング
SLES12 ext3 から BTrFS への変換
- Forward を有効に -
Docker は Windows の Windows Subsystem for Linux に似ています。と言うか WSL 自体が Docker の Windows 版なんですね。たぶん。Dockerをインストールすると仮想ブリッジが作られ、コンテナのインターフェースが物理インターフェースと通信できるよう、フォワードを有効にしておく必要があります。一応 KVM と Docker を同居させている猛者はいるようですが、設定が複雑になるので止めとけ、という事です。
因みに、ここでは SUSE on SUSE の KVM 環境なので、仮想サーバー上で Docker を動かすことは問題ないようです。
Forward を有効にするには、 YaST > System > Network Settings の Routing のチェックを入れるだけです。
全体の流れを動画にしました。盛大に音出ます。
openSUSE Leap 15x と SLES15 SPx では若干インストール方法が違います。本当は openSUSE Leap を使いたかったのですが、機嫌が悪かったので、「あって良かった安心強護の SUSE Linux Enterprise」(SLES15 sp2) を使いました。
openSUSE Leap ではリポジトリの追加は不要です。SLE15 の場合、今回はトライアル版なので、ローカルディスクに ISO ファイルをコピーして、YaST > Software > Software repositories より ADD で、Local iso イメージを指定しました。
追加プロダクトとして Containers Module をチェックします。
後は、Software Management より "Docker" をサーチしてチェック、インストールします。
- ユーザを Docker グループに
YaST > Security and Users > User and Group Management より、Docker 使いたいヒトビトを Docker グループに追加します。
- 自動起動を Enable に
YaST > System > Service Manager より Docker を Enable, Active をセットして Docker を起動します。
- hellow-world を run -
sles15sp2:~ # docker run hello-worldUnable to find image 'hello-world:latest' locallylatest: Pulling from library/hello-world0e03bdcc26d7: Pull completeDigest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9Status: Downloaded newer image for hello-world:latestHello from Docker!This message shows that your installation appears to be working correctly.To generate this message, Docker took the following steps:1. The Docker client contacted the Docker daemon.2. The Docker daemon pulled the "hello-world" image from the Docker Hub.(amd64)3. The Docker daemon created a new container from that image which runs theexecutable that produces the output you are currently reading.4. The Docker daemon streamed that output to the Docker client, which sent itto your terminal.To try something more ambitious, you can run an Ubuntu container with:$ docker run -it ubuntu bashShare images, automate workflows, and more with a free Docker ID:https://hub.docker.com/For more examples and ideas, visit:https://docs.docker.com/get-started/sles15sp2:~ #
- YaST2-Docker -
YaST2-Docker アプリケーションは、openSUSE では問題ない様ですが、SLE ではちょっと問題があり、インストールはひと工夫必要です。必ず必要なものではないので読み飛ばしてもらって結構です。
まず yast2-metapackage-handler の rom をダウンロードして
YaST2 - Easy Installation of Add-on RPMs using Metapackages
yast2-metapackage-handler を rpm でインストールします。
# rpm -ivh yast2-metapackage-handler-4.1.0-lp151.1.1.noarch.rpm
これで、YaST2-Docker を 1 Click インストールできるので、software.opensuse.com から1クリックインストールしました。 この辺りはトラブルの元です。SLE15 BACKPORT リポジトリだけ有効にすると良い様です。
yast2-dockerYaST2 - GUI for docker management
- YaST2 docker -
YaST2-Docker はこんな感じです。コンテナの停止、削除には使えます。が、docker run は使い方がよく分かりません。マニュアルも見当たらなかった。
- nginx HTTP を動かす -
nginx のコンテナパッケージはこちらにあります。docker pull して run させるだけです。
Docker Official Images Official build of Nginx.
sles15sp2:~ # docker pull nginxUsing default tag: latestlatest: Pulling from library/nginx8559a31e96f4: Pull complete8d69e59170f7: Pull complete3f9f1ec1d262: Pull completed1f5ff4f210d: Pull complete1e22bfa8652e: Pull completeDigest: sha256:21f32f6c08406306d822a0e6e8b7dc81f53f336570e852e25fbe1e3e3d0d0133Status: Downloaded newer image for nginx:latestdocker.io/library/nginx:latestsles15sp2:~ #
Docker run リファレンスhttp://docs.docker.jp/engine/reference/run.html
- コンテナ起動
sles15docker:~ # docker run -d -p 80:80 nginx
nginx が動きました。
- 起動時にコンテナを自動起動させる -
これでは Docker の親が起動した時、コンテナが起動できないので、--restart=always スイッチを付けて、コンテナを起動させると、 Docker サービスが起動する際に、自動起動するようになりました。
sles15docker:~ # docker run --restart=always -d -p 80:80 nginxca5d8b4b8adc55dc352f6022ef70da93ab243449cfc35d2cd2bd0903e7bd4c42- 動作中のコンテナの確認sles15docker:~ # docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES3485ddc43916 nginx /docker-entrypoint.…" 3 minutes ago Exited (0) 2 minutes ago affectionate_clarkead88906a4cf0 hello-world /hello" 2 hours ago Exited (0) 2 hours ago agitated_perlman
<-- 只今停止中、停止しないと削除できない。
- 停止中のコンテナを削除
sles15docker:~ # docker rm 34853485sles15docker:~ # docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESad88906a4cf0 hello-world /hello" 2 hours ago Exited (0) 2 hours ago agitated_perlman
<-- 消してみた
- 常時起動状態で起動
sles15docker:~ # docker run --restart=always -d -p 80:80 nginxcd43c374894d21a357a7835df7af11e1e59f51c11919c395d6a91cfe78da9d78
sles15docker:~ # docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMEScd43c374894d nginx "/docker-entrypoint.…" 8 seconds ago Up 5 seconds 0.0.0.0:80->80/tcp optimistic_chateletad88906a4cf0 hello-world "/hello" 2 hours ago Exited (0) 2 hours ago agitated_perlman
<-- --restart=always を付けて起動(Up)
- 稼働中のコンテナを停止
sles15docker:~ # docker stop cd43cd43sles15docker:~ # docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMEScd43c374894d nginx "/docker-entrypoint.…" 35 seconds ago Exited (0) 3 seconds ago optimistic_chateletad88906a4cf0 hello-world "/hello" 2 hours ago Exited (0) 2 hours ago agitated_perlmansles15docker:~ #
<--- コンテナを止めておく(Exited)
- docker deamon を再起動
sles15docker:~ # systemctl stop docker
sles15docker:~ # docker ps -aCannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
sles15docker:~ # systemctl start docker- docker コンテナがデーモン起動で UP になった。
sles15docker:~ # docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMEScd43c374894d nginx /docker-entrypoint.…" About a minute ago Up 2 seconds 0.0.0.0:80->80/tcp optimistic_chateletad88906a4cf0 hello-world /hello" 2 hours ago Exited (0) 2 hours ago agitated_perlmansles15docker:~ #
<--- 止めたコンテナがサービス起動とともに開始した。
- その他 -
A Visual Way to Play with DockerHands on with Docker, openSUSE Leap 15
 |  |  |
- まとめ -
Docker そのもののインストールや基本操作で理解できました。後は例えば nginx を使う場合の詳細な設定をどうするか、とか、自らコンテナを開発したりカスタマイズするにはどうするか、と言った問題があります。知るほどに置くが深そうですね。
食わず嫌いは良くない。
▲
by islandcenter
| 2020-07-01 10:42
| SUSE
|
Comments(0)
2019年 06月 19日
openSUSE Leap 15.1 で初めての KVM, 仮想化
いきなりですが、私は openSUSE Leapで「サーバールームのハイパーバイザーで本格運用」することはお勧めしません。 本格運用で使うなら、 SUSE Linux Enterprise(SLES) での運用を強くお勧めします。
SUSE Linux 15 (SLES15) でKVM/XEN仮想環境 https://islandcnt.exblog.jp/238685530/ KVM on SUSE(SLES12) で仮想インスタンスの作成 https://islandcnt.exblog.jp/238578664/ Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化 https://islandcnt.exblog.jp/239122369/
しかし、今スグここで「KVMのテスト、開発環境が必要になった」のであれば、openSUSE Leap は Hyper-V と比較しても一つの良い選択です。軽いですし安定しています。何しろ無料でハイパーバイザーが手に入る気軽さ。LibreOffice も付いて GIMP も標準なので、そのまま仕事ができる。 いきなりステーキ！、じゃないな、いきなり SLES 15(SUSE Linux Enterprise Server) では、敷居も高いし、openSUSE と違いインストールが異なりちょっと面倒です。 何しろ SLE(SUSE Linux Enterprise) 譲りで SLES の鉄壁の信頼性を引き継ぐ openSUSE 上であり、openSUSE <---> SLES との相互運用性も高いので - テストと開発は : openSUSE で取り合えず開発し - 本番運用は : SUSE Linux Enterprise にマイグレーション という選択肢は十分に魅力的です。 ここでは無料で作れる openSUSE Leap 15.1 で KVM ハイパーバイザーの導入手順を説明します。 ここでは前提条件として
- openSUSE はインストール済とする。 - /var は仮想ディスクイメージを格納します。別パーティションとします。 - 固定IPでセットアップ済
とします。openSUSE Leap 15.1 のセットアップはこちらの記事を参考にしてください。
openSUSE Leap 15.1 インストール https://islandcnt.exblog.jp/239244204/
※ 画面のキャプチャは英語ですが、優先言語を日本語にすると root 以外のユーザは、全て日本語表記になります。
PR
固定IPを設定するため、ネットワークの設定は openSUSE15.1 標準の Network-Manager ではなく Wicked にします。 YaST > Network Settings より、設定方法を "Wicked", 必要な固定IPを設定します。
仮想ディスクイメージは /var/lib/libvirt/images/ にデフォルトで作成されます。勿論、VM を create する時に、任意のディレクトリを指定できます。ここではデフォルトのルールに則って、 / パーティションは必要最低限、空きスペースの全てを /var を別パーティションに割り当てました。 ライブマイグレーションするなら iSCSI マウントできる NAS 上に作成するのも良いでしょう。 ※ ヒント 32Gb 程度の USB メモリに / パーティションをインストールしてライブUSB起動して、QNAP などの iSCSI NAS 上に仮想イメージを作るのも一案です。既存のPC環境を壊したくないのであれば、一つの手段ですね。 PR 楽天でQNAP の NAS を検索
一旦、システムを再起動すると KVM ハイパーバイザーが起動します。
KVMの必要なパッケージをインストールしたら、YaST > Virtualization > Install Hypervisor and Tools を開き、 Libvirt LXC containers をチェックします。
ネットワークブリッジを設定するかどうかは、 Yes YaST > System > Network Settings から、ブリッジインターフェースが設定されている事を確認します。 # virt-manager & を実行して、KVM仮想インスタンスが作成できる事を確認します。
ここまでの手順を動画でまとめました。（音出ます）
仮想VMインスタンスが立ち上がりました。
PR 最後までお読みいただきありがとうございました。
▲
by islandcenter
| 2019-06-19 12:20
| SUSE
|
Comments(0)
2019年 06月 05日
SUSE linux15 virt-manager が起動できない
SUSE15: virt-manager が起動できない。
- 結論 -
いきなり結論です。virt-manager は二重起動できません。
PR- やっぱり高速回線は欲しいよね -PR
- 現象 -
xterm から virt-manager GUI が起動できない。実行すると[1]+ Done するが、GUI が上がってこない。
- 原因 -
どこかのバカ（つまりオレ、もしくはワタクシ、たまにワシ）が、コンソールの Xターミナルから "# virt-manager &" して virt-manager を起動したまま、トイレに行ったついでに昼飯を食いに行って、お腹がが痛くなったのでそのまま帰ってこなかった。次の日の朝、頭をリセットした別な奴（ワタクシの別人２号）が、movaXterm の様な別なX端末から# virt-manager &したところ[1]+ Done virt-manager
- 対策 -
どこかのバカ（くどいけどワタクシもしくは私）がそれに気が付いて、バカな自分ふるまいを思い出してリモート端末から virt-manager を終了させるか、ワタクシの別人二号が virt-manager のプロセスを kill すれば解決できる。# ps ax |grep virt-managerして”/usr/bin/python3 /usr/share/virt-manager/virt-manager” のプロセス番号を kill したら、問題なく動作した。sles15:~ # ps ax | grep virt-manager2275 ? Ssl 0:00 /usr/bin/python3 /usr/share/virt-manager/virt-manager <-- 残っている2295 pts/10 S+ 0:00 grep --color=auto virt-managersles15:~ #sles15:~ # kill 2275sles15:~ #sles15:~ # ps ax | grep virt-manager2325 pts/10 S+ 0:00 grep --color=auto virt-managersles15:~ #sles15:~ # virt-manager &[1] 2330sles15:~ #[1]+ Done virt-managersles15:~ #
--
これは virt-manager だけではなく FireFox なんかも、コンソールで起動して、別なターミナルから起動しようとすると、"FireFox は既に動いているよぉ～" の様な同じ現象が出ます。
GUIのソフトウェアを、同じユーザ名でログオンした状態で起動すると、拒否られる事があります。コンソールからroot で GUI ログオンしたまま。リモートX端末からアプリケーションをコマンドライン起動すると、ターミナル側で起動せずコンソールでGUI が起動してしまった。という笑い話もありました。gedit & って実行して、おっかしいなぁと思ったら、コンソールで起動していたとか......いや、笑い話ならまだしも、実際、movaXterm でリモートから# startx &なんてやってしまうと、実に面白い結果になります。コンソールでXが起動してしまう。閉じるには、実際コンソールに行かなければならない。つまり、root でのログインはどこか一つの端末で行って、いつでもどこでもログオンしまくるなよ、という事ですね。仕事が終わったら必ず logout する。初心者に限らずワタシの様なズボラな人間が陥りやすい罠です。ひどく当たり前な事でも、判っていなければやっぱりやっちゃう。ダメ人間別人１号です。水曜どうでしょう名セリフステッカー-ダメ人間
root ではいって実行するプロセスは下手に kill すると、システムに致命的な問題を起こすので、無暗に root で入るな、という事なんですが、すぐ sudo したがる人にとっては、あまり変わらないかも知れませんね。
▲
by islandcenter
| 2019-06-05 13:41
| SUSE
|
Comments(0)
Windows 2019 試用版を入手したので、SUSE(SLE15)+KVM 環境下で、仮想マシンドライバパック、VMDP(Virtual Machine Driver Pack, virtio) と一緒に導入してみました。
SUSE Linux Enterprise Virtual Machine Driver PackFAQに"有効なSUSE Linux Enterprise Serverサブスクリプションをお持ちのお客様には、これらの並行仮想化ドライバの保守およびサポートの使用権が自動的に付与されます。ドライバのサポート契約は、お客様が契約しているSUSE Linux Enterprise Serverサブスクリプションから継承されます。"
とあるので SLE のサブスクリプションに含まれている、と考えていいでしょう。
サブスクリプションの購入はこちら
最新の VMDP 2.5 はこちらから無料登録済み SUSE アカウント でダウンロードができます。
SUSE Linux Enterprise Virtual Machine Driver Pack 2.5
Windows では xen 環境からの移行も簡単です。
SUSE Linux で XEN から KVM へ移行、VMDP はこんなに簡単
全体の流れは動画にまとめました（９分、盛大に音出ます）
Windows Server 2019 on SUSE Linux 15 with VMDP + KVM install (仮想化インストール)
今回は iso 版を仮想マシンにマウントしてインストールしました。
- virt-manager からインストール -
SLE15より virt-manager のアイコンが yast2 の GUI から消えてしまったので、XのGUI 環境からテキストターミナルを開いて
# virt-manager &
をコマンドライン実行して仮想マシンマネージャを起動します。起動したら”not connected” のラインから右ボタンで "connect" します。
左上の Create ボタンを押して、新しいVMを作成します。
インストールソース iso イメージを指定するため、 Browse ボタンを押して、メディアパスを探してセットします。
インストールソースをセットすると、自動的にインストールするVMのOSタイプを認識します。 SLE15 より Windows 2019 の方が後に出たため、ここでは Windows 2016 と認識されています。 他のOSの場合"unknown" などと出てきた場合は "Automatically detect ......." のチェックを外して、最も近いシステムを選択することができます。
> Forward
Windows Server 2016 と認識したため、VM イメージは 40 Gb と認識されました。 Windows でこれより大きな C: システムイメージを作りたい場合は、任意の数字をセットします。
デフォルトでは /var/lib/libvirt/images の下に qcow 形式の仮想イメージを作ります。
今回は、SSD をマウントしたディレクトリに、RAW フォーマットのイメージを作りたいので、"Select or create ......" を選び "Manage" ボタンを押して、任意の場所、任意のファイル名で仮想イメージを作ります。
メモリとCPU数を、デフォルト状態から任意の数値にセットします。
仮想イメージを作成するディレクトリをブラウズして決定し、ファイル名を任意にセットします。ここでは SSD ドライブをマウントした下のディレクトリに"仮想VM名.disk0.raw" としました。
※ なお、ディレクトリはこのダイアログでは作成できないため、事前に# mkdir "仮想VM名"しておくと良いでしょう。
仮想ディスクイメージがセットできたら "Forward"
最後のダイアログです。ここでは必ず決め打ちされた仮想VM名: "Name" のボックスに、運用上の命名規則に則った Name をセットします。
次に、必ず "Customize configuration before install" のチェックを入れて、インストールのサマリダイアログを開くようにしてください。
> "Finish"
"Customize configuration before install" のチェックを入れると、インストールのサマリスクリーンに移動します。
IDE Disk を選んで "Advanced options" ドロップダウンを開くと "Storage format" が qcow2 で決め打ちされています。この欄を "raw" 形式に変更します。
※ qcow2 形式は、指定したディスク容量より小さく、容量を節約できますが、一般に書き込み動作が低速で重い、と言われています。また、データの使い方によっては、それほど、効率が良くないようです。例えば一発デフラグすると、あっという間に容量を使い切ってしまうという事が起こりえます。システムドライブイメージでは初めから容量確保されて安定して高速な "raw" フォーマットの方が良いと思います。データドライブ、パーティションは qcow2 形式を選択する場合もありますが、データドライブは別メディア、例えば iSCSI SAN ストレージを使った方がベターです。
VMDP(Virtual Machine Driver Pack) を使う場合、NIC の形式は "Hypervisor Default" から”virtio” に変更します。
ハイパーバイザーデフォルトを後で変更しても構いませんが、手順がややこしいので、インストール時点で "virtio" にしておくのが良いでしょう。
"Apply" を押して、左上にある "Begin installation" を押すとインストールが開始されます。
インストールが始まります。
二度ほど再起動したら、インストール完了です。（この環境では約１０分....）さすが Linux ベースの仮想化は早い！...
- VMDP のインストール -
virtio をNICドライバとして設定したため、NICが見当たらない状態になっています。
仮想コンソールからVMのサマリ編集画面のボタンを押して移動し、 IDE CDROM に認識されているインストールソースを"Disconnect" して、”Connect” ボタンから、 VMDP の ISO ファイルをファイルシステムからブラウズしてマウントします。
仮想コンソールに戻り、VMDP の ISO ファイルがマウントされている事を確認します。
※VMDP はアンインストールしたり再インストールする場合があるので、C: ドライブの任意のフォルダにコピーしておくと良いでしょう。
VMDP の setup.exe を実行します。
EULAに同意
インストールが始まります。（この環境で１分弱）
VMDPのインストールが終わると、再起動が要求されます。でもその前にネットワークが検出されたようです。
再起動後のネットワークのプロパティです。ネットワークが認識されているようです。
イーサネットのプロパティを開くと "SUSE Network Driver for Windows" がインストールされている事が分かります。「構成」ボタンを押してドライバのパラメータを確認します。
「詳細設定」タブにドライバのパラメータが設定されています。VMDP2.5 では、デフォルトで問題ないようですが、一応 "xxxx Offload" 系のパラメータは全て "Disabled" になっている事を確認します。 これらが Disable にセットされて問題になったことはありませんが、Enable で問題になったことは何度もありました。
デバイスマネージャーを開いて、 BUS ドライバや SUSE NIC ドライバがインストールされている事を確認します。
VMのサマリ画面に戻り "Boot Options" にある "Autostart" にチェックを入れ、ハイパーバイザー筐体が起動したときに同時にVMも起動できるようにします。また、Boot Menu が出ないよう、マウントした CDROM のチェックを外しておきます。
How to install samba on SUSE Linux Enterprise 15 (SLES15) インストール
初めての Linux, openSUSE Leap を Hyper-V で動かす
openSUSE Leap 15.1 で始める KVM, 無料のハイパーバイザー
SUSE Linux 15, openSUSE 15, SLES15, KVM, Windows サーバー仮想化、virtio, Linux, 仮想サーバーの最適化, 仮想マシンが重い,
▲
by islandcenter
| 2019-02-24 15:33
| SUSE
|
Comments(0)
2018年 06月 13日
KVM on SUSE(SLES12) で仮想インスタンスの作成
ここでは SUSE Linux Enterprise Server(SLES12) で仮想マシンを作成する手順を説明します。
SLES12 より virt-manager の使い方がウィザード方式になり、簡単になった反面、細かなカスタマイズが出来にくくなりました。ここでは、 カスタマイズしたインスタンスの作成方法を説明します。
-はじまりはじまり-
全体の流れはこちら
SLES VM install on KVM/SLES12
まず仮想インスタンスイメージを作成するディレクトリを作成します。
virt-manager では、仮想イメージを作成するディレクトリを作成する機能がないので、予め、仮想イメージを作るディレクトリを掘っておく必要があります。
/var/lib/libvirt/images
# mkdir /var/lib/libvirt/images/myvm
virt-manager の起動
# virt-manager &
で起動するか yast2 & > Virtualization > Virtual Machine Manager を選びます。ここで左上の Create ボタンを押して、新しい仮想インスタンスを作成します。
Local Install Media(ISO or CDROM) > "Foreword" > Use ISO Image > "Browse" > Browse Local > Other Locations から、ディレクトリをブラウズして ISO ファイルを指定して "Open"
"Automatically Detect ........ " にチェックが入っているので、インストールOSのテンプレートが自動的に選択されます。もし、"Detect" されない場合は、チェックを外して、適切なOSを選ぶ事ができます。若い方には「こんなのシラン」という、年寄りには”懐かしい”と叫びたくなる古いシステムも選択できます。（OS/2 Warp はなかった.....）
Forward で、vcpu 数、メモリを設定します。
イメージを作成するディレクトリを指定するために "Manage" ボタンを押して、作成済みのディレクトリに作成する仮想インスタンスのイメージファイル名を指定します。
Manage > "Brows Local " > "Computer" から、予め作成したディレクトリを指定(Open)します。まだファイルがないので、ファイル名を分かりやすい名前（仮想VM名＋ディスク番号＋フォーマット形式：など）で作成します。
- 仮想マシンのカスタマイズ -
”Finish” ボタンを押す前に「ちょっと待った！」
仮想VM名が決め打ちなので、運用上のインスタンスの命名規則に従って設定、
”Customize Configuration .....” をチェックして選択、仮想VMをカスタマイズします。インストールサマリの詳細画面が出ます。
仮想ディスクイメージの ”Advanced Option” を開くと、デフォルトフォーマットが "qcow2" なので ”raw" に変更
※ 一般的には qcow2 より固定容量の raw フォーマットの方が高速で安定していると言われます。ただし、使い勝手やディスクの予備容量では qcow2 の方が良いそうです。運用上、あまりファイルが増えない小さなシステムでは raw フォーマットが向いているでしょうし、ファイルの増減が大きな場合やスナップショットを使うには、qcow2 の方が使い勝手がよいようです。
- 二台目の仮想ディスクの追加 -
Add Hardware で二台目の仮想ディスクイメージを作成、一台目と同じ要領で、任意のディレクトリパスに仮想ディスクのイメージファイルを指定します。"Advance Options" を開き、適当なパラメータを指定します。
二台目のディスクも raw フォーマットにしましたが、システムディスクは raw フォーマット、二台目のデータディスクや、/var, /home や /data などのファイル増減が多い仮想ディスクは qcow2 にするか、外部の iSCSI デバイスに分けるのが良いでしょう。
スピード重視の開発環境や、フルイメージのバックアップから再起動が高速で会った方がいい、という場合は、SSD上にイメージを作るとか、システムパーティションは SSD 上に作り、大容量の仮想ディスクが必要な場合は HDD のパーティションに作りたい、という選択ができます。
- いよいよ作成開始 -
左上の Begin Installation を押してインストール開始（このボタンの位置がわかりずらいンですね）
インスタンスが実行状態となり、インストーラが起動します。
かなり端折りましたが、全体的なイメージはこんな感じでした。
より詳細な情報はマニュアルをご参考ください。
マニュアルはこちらSUSE Linux Enterprise Server 12 SP3 Virtualization Guide
--
Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化SUSE linux15 virt-manager が起動できないサブスクリプション購入はこちら
PR- 最後まで読んでいただきありがとうございます -PR
SUSE Linux, SLES12, KVM, Create VM virt-manager, KVM 仮想マシンのインストール,
▲
by islandcenter
| 2018-06-13 15:17
| SUSE
|
Comments(0)
2017年 08月 08日
役割を終えた XEN , Citrix と XenServer が過去形となる日
もう１０年以上 XEN ハイパーバイザーと付き合ってきて、つくづく思うのは「あぁ、もうx86_64 のXENは終わったなぁ」ということです。別にLinux + x86_64 なら KVM でもいいんじゃん。
今でも考えられるケースで XEN を使うとしたら、
- XEN の Domain_U のカーネルを弄ってまで、他のハイパーバイザーに移行させたくない(これ結構大きい)
- BSD 系 Uinux や Soralis と言った、非 Linux カーネルの UNIX系 OSをハイパーバイザーやゲストOSでも使っている(トモダチになりたくないな)
- ハードウェアに仮想化支援機能(VT機能) がない機器とか i386 ベースのx86ハードウェアでも仮想環境を使いたい（エラク古いPCだ）
- Intel x86 系の CPUを使っていない(PPCやIA64)とか (見たことないけど、もっとトモダチにもなりたくないな) )
こういった「今更な理由」がない限り Linux に限れば XEN による準仮想化を積極的に選ぶ理由がなくなってしまったのです。
まぁ、もともと１０数年前に XEN 3.0 の登場とともに Intel=VT や AMD-V などの仮想化支援機能がハードウェアに実装されたと同時に XEN に「完全仮想化」というキラーな機能がついて、火が付いたと云えます。
と同時にこれらのVT機能の強化が続く中、普及と共にライバルの完全仮想化、６４ビット版のみの KVM ハイパーバイザーが台頭してきたわけです。何しろ完全仮想化は QEMU にオーバーヘッドを渡すわけで、同じ QEMU を使う KVM ハイパーバイザーとの共通化が進んでいるわけですね。
PR
ただし KVM ハイパーバイザーは当時としては主流だった VT 機能非搭載のPCサーバーや XEN を積極的に導入してきた非Linux 系の ISP やBSD系 Unix が主流の iDC の積極的な導入がなく、実績も少なかったので、まだまだ「開発中」といったイメージしかありませんでした。また、ハードウェアも仮想化を強く意識しないデュアルコアやクアッドコアがせいぜいでした。
しかし、VT機能というハードウェアの援護を受けて、KVM は一挙に広まっていった、という感じがあります。実際、XENで完全仮想化された Domain_U であれば、ほとんど仮想イメージを変更しないで KVM へ移植できてしまいます。何しろハイパーバイザーの補助をする QEMU という共通基盤があるため、XEN の完全仮想化はほとんど KVM との共通ワードとなっているわけですね。だから、 Linux On Linux の仮想化でも Full Virtual には、特に目立った機能の低下、スループットの低下はあまり感じなくなってきました。さらにはオクタコアやへクスコアなんていうハードウェアが、松竹梅の「竹程度」のサーバーに実装されると、ボトルネックはディスクI/O程度の問題になります。
SUSE 11.x の時代は XEN の全盛時代だったのですが、 SUSE では SLES12 以降、Libvirt の共通化により、オペレータは、自分が操作するハイパーバイザーが XEN なのか KVM なのか、強く意識しなくなりました。この原因は OpenStack の影響もあるでしょう。 SUSE は openstack に重点が移っているし、親会社の Microfocus も HPE のソフトウェア部門の買収に伴い、益々マルチベンダークラウドに力が入っていきそうです。
顧客も専用のハイパーバイザーと管理ツールによるベンダーロックインは避けたいところ。オンプレミスなクラウドと、iDC のプライバートクラウドと、AWS のようなパブリッククラウドとの間にあるマイグレーションを試みたい所です。まぁ日本のIT業界ではベンダーロックインというよりSI屋にロックインされているのですけどね。
SLES の仮想化コマンド自体も Libvirt の共用化によって、virsh コマンドにオプションの違いはあるにせよ、ほとんど xm, xl コマンドと同じ操作ができるようになってしまいました。こうなると、自分の操作するハイパーバイザーが XEN なのか KVM なのか、ほとんどオペレーターは意識する必要がなくなってしまいます。こうなると Citrix や VMware 専門のエンジニアのある種の閉鎖性が邪魔になってしまいそうです。
また openstack による統合管理を考えると、事業者におけるハイパーバイザーの一本化というのは避けて通れない（のかな）という事もあり、Linux + x86_64 主体のデータセンターでのハイパーバイザー運用は XEN ではなく KVM の一本化に進んでいくことになりそうです。
伝統的に XEN on BSD Unix などを使っていた iSP や iDC 事業者はさておき、数年後の新興サービスベンダーの若い技術者にとっては「XEN？何それ」化しそうな気がします。
PR これも KVM
--
こうなると "XENserver" を名乗る CItrix の戦略はどうなるのよ、という疑問がふつふつとわいてきます。世の中、完全仮想化に向いている中、Linux や BSD 系の「サーバー」OSを XEN ハイパーバイザーで管理する、という商品イメージはだんだんとネガティブに見えてきます。いまや XEN というブランドが、重しとして Citrix に乗りかかっているのですね。「あぁ Citrix, 昔 XEN でブイブイ言っていたベンダーね」と「聞いたことあるよ」という日がいつか来るでしょう。いや、その頃はもうXEN app というプロプラエタリなアプリケーションの仮想化ベンダーとして特化する中，早まって XENsource を買収したCitrix も XEN というブランド名を捨ててしまうのかも知れません。
もともと、Windows NTx 系のオペレーティングシステムをマルチユーザ化した Windows Remote Desktop も Cytrix が開発に関わった機能であり、Metaframe や XEN App といった、Citrix 得意のシンクライアント機能に特化した企業として存続していくのだろうけれど、サーバー集約化を目指す Xenserver といった製品の他社ベンダーや openstack や docker との差別化できない機能は、よほどのことがない限り、「世界のクラウドの Citrix 」化することはなさそうです。
PR インフラエンジニアが知っておくべき仮想化技術
▲
by islandcenter
| 2017-08-08 15:19
| プライベートクラウド
|
Comments(0)
2017年 07月 15日
Zabbix3.2 のソフトウェアアプライアンスUbuntu 版をSUSE 仮想環境で試してみた。
Zabbix 3.2 のアプライアンス版が出ていましたので、SUSE バカに陥らないためにも、ubuntu と格闘してみました。というか、2.2 のアプライアンスが壊れてしまったので（あぁーバックアップ取ってないし .... ）
zabbix 2.x の導入はこんな感じでした。
SUSE Studio から Zabbix 管理ツールの導入
2019/7 現在最新の openSUSE Leap 15.1 に zabbix 4.2 をインストールする手順です。
How to setup zabbix4.2 on openSUSE Leap 15.1Zabbix4.2 snmp デバイスのグラフを表示させるまで
※ ソフトウェアアプライアンス版は、評価目的のチューニングですが、中小規模の数台のサーバーやルータ、スイッチなどのトラフィック管理など数十台のデバイス管理には、そこそこ使えます。より深く学び、システム管理が複雑で規模や問題が大きくなれば、それなりに Zabbux L.L.C の有償サポートを受けたパッケージの導入とトレーニングを受けてください。私としては、デバイスの異常なトラフィック増大を時系列で見えればよい程度なので、導入の敷居が低いzabbix のソフトウェアアプライアンス版は初めての方にはお勧めです。なお、 3.2 は LTS 版ではないのでそのつもりでトレーニングだと覚悟してください。
- ハイパーバイザーへの実装 -
Zabbix のダウンロードページから、 "KVM, Parallels, QEMU, USB stick, VirtualBox, Xen" 用イメージ (.raw1.6Gb) をダウンロードします。
DownloadZabbix appliance Documets
*****.tar.gz を解凍すると 10Gb の仮想アプライアンスイメージが出来上がります。ubuntu のバージョンは /etc/os-release によると 14.04 でした。
これを virt-manager から Create Virtual Machine で実装します。機材の都合で XEN4.4 on SUSE SLES11sp4 です。
このバージョンは、 Ubuntu 14 は対応していないようですが、 Ubuntu(Other) で実装できました。
- Virtual : Full Virtual
- Name of VM :
- Hardware : 512Mb, 1Vcpu
- MAC : XEN source のヘッダに任意の３桁
これで OK を押すと、Zabbix 3.2 アプライアンスが起動できました。
Ubuntu のいやらしいroot でログインできないログインプロンプトです。
ダウンロードページにあるパスワードでログインします。
login : appliance
Password : zabbix
DHCPで IP をもらうので一応 ifconfig で IP を確認します。
これで SSH テキスト端末からログインできます。
ssh xx.xx.xx.xx -l appliance
sles11:/var/lib/xen/images/zabbix32 # ssh 192.168.1.xx -l appliance
Zabbix server Appliance (mysql)
appliance@192.168.1.55's password: **********
Last login: Fri Jul 14 10:30:35 2017
######## ### ######## ######## #### ## #### ## ## ## ## ## ## ## ## #### ## ## ## ## ## ## ## ## #### ## ## ######## ######## ## ##### ######### ## ## ## ## ## ## #### ## ## ## ## ## ## ## ## ########## ## ## ######## ######## #### ## ##
appliance@zabbix:~$
IPを固定します。 /etc/network/interface を sudo vi で DHCPから Static に編集します。（メンド臭い）
IP を指定して DNS, Default Gateway の設定をします。
appliance@zabbix:/etc$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static <--- 追加
address 192.168.1.220 <--- 追加
netmask 255.255.255.0 <--- 追加
gateway 192.168.1.1 <--- 追加
dns-nameservers 192.168.1.2 <--- 追加
/etc/resolv.conf を書き換えます。（メンド臭い）
appliance@zabbix:/etc$ cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.2 <--- 追加
nameserver 192.168.1.3 <--- 追加
search intra <--- 追加
でネットワークの再起動（メンド臭いしミスタイプしやすい）
appliance@zabbix:/etc$ sudo ifdown eth0 && sudo ifup eth0
[sudo] password for appliance: *********
appliance@zabbix:/etc$ ping www.yahoo.co.jp
PING edge.g.yimg.jp (183.79.248.252) 56(84) bytes of data.
64 bytes from 183.79.248.252: icmp_seq=1 ttl=52 time=90.6 ms
64 bytes from 183.79.248.252: icmp_seq=2 ttl=52 time=97.3 ms
--- edge.g.yimg.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 90.698/94.024/97.350/3.326 ms
appliance@zabbix:/etc$
という事でブラウザから http://ip_or_DNS_address/zabbix へ Admin/zabbix のデフォルトでログインします。
で、色々弄って、date すると UTC 表示でした...... ubuntu の場合、謎のオマジナイがあるのでシステム時刻を JSTに変更します。
appliance@zabbix:/etc$ sudo dpkg-reconfigure tzdata
[sudo] password for appliance: *********
こんな UI が出てくるので Asia > Tokyo を選び OK します。
appliance@zabbix:~$ date
Sat Jul 15 00:29:36 JST 2017
appliance@zabbix:~$
無事、システムの時刻表示は UTC から JST になりました。しかし、Zabbix の UI で表示される、グラフやイベントは UTC のままです。一体どこで変えるんでしょうね。
/etc/php5/apache/php.ini を sudo vi で変更しました。
appliance@zabbix:/etc/php5/apache2$ sudo vi php.ini
appliance@zabbix:/etc/php5/apache2$ ....: 編集中 .....
appliance@zabbix:/etc/php5/apache2$ cat php.ini | grep timezone
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = Asia/Tokyo
appliance@zabbix:/etc/php5/apache2$
zabbix-server と apache2 をリスタートさせましたが
何故か６時間、表示が遅れています（謎）
※謎解決 タイムゾーンを JST に
/etc/apache2/conf-available/zabbix.conf に Timezone の設定があるのでこれを突いたら治りました。
appliance@zabbix:/etc/apache2/conf-available$ ls -al
total 36
drwxr-xr-x 2 root root 4096 Aug 7 17:53 .
drwxr-xr-x 8 root root 4096 Jul 28 06:43 ..
-rw-r--r-- 1 root root 315 Jan 3 2014 charset.conf
-rw-r--r-- 1 root root 3224 Jan 3 2014 localized-error-pages.conf
-rw-r--r-- 1 root root 189 Jan 3 2014 other-vhosts-access-log.conf
-rw-r--r-- 1 root root 2190 Jan 3 2014 security.conf
-rw-r--r-- 1 root root 455 Jan 7 2014 serve-cgi-bin.conf
-rw-r--r-- 1 root root 1582 Aug 7 17:53 zabbix.conf
-rw-r--r-- 1 root root 1583 Aug 7 17:52 zabbix.conf.org
appliance@zabbix:/etc/apache2/conf-available$ cat zabbix.conf | grep timezone
php_value date.timezone Asia/Tokyo
php_value date.timezone Asia/Tokyo
appliance@zabbix:/etc/apache2/conf-available$
マニュアルはちゃんと読めよという事ですね。
- NTP をインストールして設定 -
NTP が入っていないので、インストールします。ハードウェアクロックは仮想環境では時刻狂いを起こします。
sudo apt-get で ntp を Install します。
appliance@zabbix:/etc$ sudo apt-get install ntp
[sudo] password for appliance:
Sorry, try again. あちゃーメンドクサイ
[sudo] password for appliance:
Reading package lists... Done
Building dependency tree
Reading state information... Done
: 中略して誤魔かしの美....
appliance@zabbix:/etc$
/etc/ntp.conf を外部ソースから、LAN内の NTP ソースに変更します。
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
server ntp1.intra <--- 追加
server ntp2.intra <--- 追加
とここまで３時間の作業でした。SUSE なら、yast 一発で２０分で終わるんだけどなぁ。
Install on openSUSE / SLES
あとは Configuration > Hosts から、smnp エージェントを実装したデバイスを登録して行くだけです。
- 対象ホストが snmp を返すか調べる snmpwalk -
監視対象ホストが SNMP に反応するかどうかは snmpwalk を使いますが、このアプライアンスにはデフォルトでは入っていないので、SUSE なら YaST で一発の所、Ubuntu 版では、テキストコンソールからキーボードと闘いオマジナイを唱える必要があります。くれぐれも綴りを間違えないように..... アチャーなトラップが待っています。
appliance@zabbix:~$ sudo apt-get install snmpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
snmpd is already the newest version.
snmpd set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.
appliance@zabbix:~$ snmpwalk <---- snmpd だけじゃダメポ.......
-bash: snmpwalk: command not found
appliance@zabbix:~$ sudo apt-get install snmp <--- このパッケージが必要なようです。
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
snmp
0 upgraded, 1 newly installed, 0 to remove and 19 not upgraded.
Need to get 146 kB of archives.
After this operation, 554 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main snmp amd64 5.7.2~dfsg-8.1ubuntu3.2 [146 kB]
Fetched 146 kB in 3s (41.1 kB/s)
Selecting previously unselected package snmp.
(Reading database ... 52441 files and directories currently installed.)
Preparing to unpack .../snmp_5.7.2~dfsg-8.1ubuntu3.2_amd64.deb ...
Unpacking snmp (5.7.2~dfsg-8.1ubuntu3.2) ...
Setting up snmp (5.7.2~dfsg-8.1ubuntu3.2) ...
appliance@zabbix:~$
appliance@zabbix:~$
appliance@zabbix:~$ snmpwalk -v2c -c public 192.168.1.239 .1.3.6.1.2.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Linux abianca 3.0.101-63-xen #1 SMP Tue Jun 23 16:02:31 UTC 2015 (4b89d0c) x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (44081742) 5 days, 2:26:57.42
iso.3.6.1.2.1.1.5.0 = STRING: "abianca"
iso.3.6.1.2.1.1.6.0 = STRING: "Right here, right now."
iso.3.6.1.2.1.1.7.0 = INTEGER: 76
iso.3.6.1.2.1.1.8.0 = Timeticks: (47) 0:00:00.47
iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
iso.3.6.1.2.1.1.9.1.2.3 = OID: iso.3.6.1.6.3.15.2.1.1
iso.3.6.1.2.1.1.9.1.2.4 = OID: iso.3.6.1.6.3.1
iso.3.6.1.2.1.1.9.1.2.5 = OID: iso.3.6.1.2.1.49
iso.3.6.1.2.1.1.9.1.2.6 = OID: iso.3.6.1.2.1.4
iso.3.6.1.2.1.1.9.1.2.7 = OID: iso.3.6.1.2.1.50
iso.3.6.1.2.1.1.9.1.2.8 = OID: iso.3.6.1.6.3.16.2.2.1
iso.3.6.1.2.1.1.9.1.3.1 = STRING: "The SNMP Management Architecture MIB."
: 中略
iso.3.6.1.2.1.1.9.1.4.8 = Timeticks: (47) 0:00:00.47
appliance@zabbix:~$ <----- うまく帰ってきたようです。
こんなに使いづらい Ubuntu 大好きって人はよっぽどマゾなんだろうなぁ。
-Key Word-
Zabbbix 3.2 仮想アプライアンス XEN KVM 評価 導入 練習台 無償で始めるネットワーク管理
▲
by islandcenter
| 2017-07-15 14:45
| プライベートクラウド
|
Comments(0)
