RHEL7/CentOS7でGPTを使用する際の注意点 - めもめも
RHEL7/CentOS7をBIOSブートのサーバー（UEFI未対応サーバー）にインストールする際に、GPTを用いる場合は、「biosbootパーティション」の作成が必要となります。2TB超えのハードディスクを使用すると、もれなくGPTが必要になるので注意が必要です。KVMの仮想マシンでも同様です。 Kickstartファイルでパーティションを作成する際は、「biosboot」というパーティションを指定します。詳細は、「23.3. キックスタート構文の参考資料」を参考にしてください。 biosbootパーティションが必要な理由 GPTではない標準パーティション構成では、MBRを含む「第0シリンダー」全体がパーティションに含まれない未使用領域になります。GRUBはこの部分に、Stage1（MBR上）、Stage1.5（MBR直後の空き領域）を配置します。 しかしながら、GPTでは、MBRの直
RHEL6 で悩ましい諸々のまとめ - めもめも
Network Manager と仲良くなれないやら modprobe.conf がなくなったやら諸々の悩みを解決するお手伝いをいたします。（この記事は、不定期にアップデートする予定です。） Red Hat 公式ガイドはこちらを参照 RHEL6 移行計画ガイド RHEL6 Migration Planning Guide ※ RHEL5もまだまだ現役という貴兄には、プロのためのLinuxシステム構築・運用技術もよろしくお願いします。 システムコンソールの切り替え Ctrl + Alt + F1 が X Window になってます。コンソールでテキストログインしたい時は、Ctrl + Alt + F2 〜 F6 を使います。 NetworkManager デフォルトで NetworkManager サービスが起動するため /etc/sysconfig/network-scripts/ifcf
RHEL7のNICのネーミングルール - めもめも
参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール（biosdevname）がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name
Dockerのネットワーク管理とnetnsの関係 - めもめも
RHEL7RC+EPEL版Dockerの前提で解説します。RHEL7RCを最小構成で入れて、次の手順でDockerを導入します。 # yum -y install bridge-utils net-tools # yum -y install http://download.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm # yum -y install docker-io # systemctl enable docker.serviceDockerが設定するiptablesの内容を見るために（見やすくするために）、firewalldを停止した上でdockerサービスを起動します。 # systemctl stop firewalld.service # systemctl mask firew
cgroupsによるIO帯域の制限 - めもめも
Kernel 2.6.37で導入された表題の機能が、RHEL6.1にバックポートされています。非常に分かりやすい機能ですので、実験結果を書き残しておきます。（RHEL6.0には入っていませんのでご注意を。） パラメータの説明 ・blkio.throttle.read_bps_device ・blkio.throttle.write_bps_device 特定のデバイスに対するアクセス速度の上限をByte/Sec単位で指定。0を指定すると制限を解除。 指定方法は"Major:Minor 設定値"（例"8:0 1048576"） ・blkio.throttle.read_iops_device ・blkio.throttle.write_iops_device 特定のデバイスに対するアクセス速度の上限をIO/Sec単位で指定。0を指定すると制限を解除。 指定方法は"Major:Minor 設定
RHEL6.0 で LXC (Linux コンテナ） - めもめも
2011/05/29 執筆中。。。 2011/05/31 コンテナの起動まで書きました！ 2011/06/06 cgroups の設定例を追加。これでひとまず完成（？） 2011/06/14 cgroups 設定例に /dev/tty* のアクセス権追加 どうも時代はコンテナらしい・・・ということで、RHEL6.0 + LXC でのコンテナ型の仮想化の方法をまとめていきます。 Linux Study Tokyo #2の発表資料「LXCで始めるケチケチ仮想化生活?!」も参考にしてください。 コンテナとは？ 概念的というか実装的には、chroot jail の延長と考えると理解しやすいと思います。 chroot jail の場合は、ファイルシステムの見える範囲をプロセスごとに制限することでプロセス間の擬似的な独立性を実現します。ただし、ネットワークソケットなど、ファイルシステム以外のリソースは
Control Groups (cgroups) - めもめも
LXC の解説に必要なので、ちょいと cgroups についてまとめておきます。RHEL6.0 前提です。 参考資料: RHEL6 リソース管理ガイド Control Groups(cgroups) の概要 cgroups とは 最近の Linux は、あるプロセスの実行を許可する CPU コアの指定など、プロセスごとにさまざまなリソース制御ができるようになっています。このような制御を複数のプロセスをグループ化したグループ単位でできると便利な場合があります。cgroups は、グループ単位でリソース制御を行うためのユーザ・インターフェースを特殊ファイルシステムの形式で提供します。 cgroups 自体がリソース制御の機能を提供するわけではありません。既存のリソース制御機能（cgroups の用語で『コントローラ』もしくは『サブシステム』と言います）を cgroups のインターフェースを利
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
