pikesaku’s blog

個人的なプログラム勉強メモです。記載内容について一切の責任は持ちません。

KVMメモ

参考

Amazon CAPTCHA
 
 

メモ

CPU仮想化支援機能の有無確認

/proc/cpuinfo
Intel-VTの場合、vmx
AMD-Vの場合、svm
 

KVMバイス

/dev/kvm
KVM実行ユーザーはKVMグループに属する必要あり
 

virt-install対話式実行

virt-install --prompt
 

QCOWの意味

QEMUのイメージフォーマット 
QEMU Copy On Writeの略
 

virshコマンド

コマンド 動作
virsh list --all 仮想マシン一覧出力
virsh dominfo VM 仮想マシン情報出力
viersh start VM 仮想マシン起動
virsh suspend VM 仮想マシン一時停止
virsh resume VM 仮想マシン再開
virsh shutdown VM 仮想マシン停止(シャットダウン)
virsh reboot VM 仮想マシン再起動
virsh destroy VM 仮想マシン停止(パワーオフ)
virsh undefine VM 仮想マシン削除
virsh pool-list ストレージプール一覧出力
virsh vol-list POOL ボリューム一覧出力
virsh vol-delete IMAGE_FILE ボリューム削除
virsh edit VM 仮想マシン設定変更
virsh vcpuinfo VM 仮想マシンCPU詳細
virsh iface-list IF一覧
virsh iface-mac IF MACアドレス確認

※undefineでは仮想マシンディスクイメージファイル(上記のボリューム)は削除されない。
 
実行例

# virsh dominfo  VM
Id:             7
Name:           VM
UUID:           d08824fb-37ad-4ac5-b091-b07df7918a14
OS Type:        hvm
State:          running
CPU(s):         2
CPU time:       7255.5s
Max memory:     6291456 KiB
Used memory:    6291456 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: none
Security DOI:   0

 

# virsh vol-list default
 Name                 Path                                    
------------------------------------------------------------------------------
 CentOS-7-x86_64-Minimal-1611.iso /var/lib/libvirt/images/CentOS-7-x86_64-Minimal-1611.iso
 CentOS-7-x86_64-Minimal-1708.iso /var/lib/libvirt/images/CentOS-7-x86_64-Minimal-1708.iso
 centos7-minimal-tmplt.qcow2 /var/lib/libvirt/images/centos7-minimal-tmplt.qcow2

 

設定ファイル

 

設定ファイル 内容
/etc/livbirt/libvirtd.conf libvirtdへの外部からの接続について等
/etc/livbirt/qemu/networks配下ファイル 仮想ネットワーク
/etc/livbirt/qemu,conf VNC設定
/etc/livbirt/storage配下ファイル 仮想ネットワーク

VCPUはqemu-kvmプロセスのスレッドに対応

ps -Le | egrep qemu-kvm
 2558  2558 ?        00:38:39 qemu-kvm
 2558  2563 ?        00:08:06 qemu-kvm
 2558  2564 ?        00:20:25 qemu-kvm
 2558  2565 ?        00:00:02 qemu-kvm
19114 19114 ?        01:11:24 qemu-kvm
19114 19122 ?        00:13:30 qemu-kvm
19114 19123 ?        00:36:12 qemu-kvm
19114 19124 ?        00:00:01 qemu-kvm

 

VCPU実行は各スレッドが呼び出すioctlシステムコール中で実行され、CPU時間はsystemでカウントされる

 

Hugmeメモリ利用設定

基本ページサイズは4KB。
メモリを多く使うプロセスの場合、ページサイズを大きくした方がメモリページ管理コストが減り性能よくなる。
DBなどで実施される。KVMも利用される。
ただ、スワップアウトできない点に注意
使う場合、ホストでhugeetlbfsマウントし、その領域をqemu-kvmコマンドの-mem-pathオプションで指定する必要あり。(詳細は書籍124P参照)
 

ストレージの考え方

ホストOS側のブロックデバイスやファイルを仮想マシンにストレージデバイスとして見せる。
ゲストOS IO要求→KVMがフック→QEMUエミュレータ処理→ファイルorブロックデバイスへのIO処理
ゲストOSはIDE/SCSI/virtioなどのデバイスとして認識
virtioはゼロコピーIOを実現するIFでもっとも最適化されてもの
 

ストレージバックエンド

バックエンドはおおきく3種類あり
ファイルシステム上のファイル(ext4 or NFS) or ブロックデバイス(Local or FS-SAN or ISCSI) or LVM
ファイルとLVMの場合、libvirtで作成・削除可能。
ファイルの場合、フラグメントをケアする必要あり。
ファイルの場合、形式が多くあり。代表的なものは、RawとQcow2
サポートされる形式は"qemu-img | grep Supported"を実行すればわかる。

形式 説明
raw 変換・メタ情報なし。ディスクイメージをddで書き出したものと同じ
qcow2 ファイル中にメタデータ保有。仮想ディスクをクラスタと呼ぶ固定長ブロックで管理し、各クラスタがqcow2ファイルのどこに格納されているかが、メタ情報に記録されてる。

※QCOW2のファイルサイズは実利用サイズに応じて変わる。
クラスタサイズは大きいほど性能向上する。デフォルト64KB?著者は2MB推奨

# qemu-img info /var/lib/libvirt/images/cnt1.qcow2
image: /var/lib/libvirt/images/cnt1.qcow2
file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 3.8G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true

 

QCOW2スナップショット

QCOW2はスナップショットが可能。作成時の処理フローは以下。
・スナップショットを作成、その時点のクラスタの対応表のコピーを保存
・スナップショットに含まれるクラスタへの参照数を+1し、「copied」フラグを外す
・スナップショット後、スナップショットに含まれるクラスタへの変更は、新たにクラスタを確保して行う。新たに確保するクラスタでは、「copied」フラグを有効にする。
QCOW2スナップショット特性
・スナップショット間に親子・前後関係なし。そのため、削除・作成に制限はなし
・QCOW2は単調にファイルサイズが増加する。最適化は仮想マシンを停止し、以下コマンドを実行されば可能

# qemu-img convert -f qcow2 -O qcow2 old.img new.img

 

Base Image機能

元になるディスクイメージからの差分イメージだけを持ったディスクイメージを作成・利用する機能。
スナップショットとは異なる。別のファイルで差分を持ち、差分イメージを複数作成し、複数仮想マシンで利用が可能。
 
QCOW2だけでなく、rawでも利用可能
QEMUでサポートされるファイル形式であればOK
Base Image設定方法

qemu-img create -F qcow2 -b BASE.img -f qcow2 NEW.img

 
Boot Image設定確認方法

qemu-img info NEW.img
〜出力〜
backing file: ★ベースディスク情報が表示される★

 

JUJUデプロイメモ

環境

MAASサーバ冗長化構成で2台セットアップ済み
MAASサーバでKVM稼働中。このKVMをPODに登録しJUJUコントローラをデプロイする。
 
 

作業の流れ

POD登録

f:id:pikesaku:20180212154621p:plain
 
f:id:pikesaku:20180212154433p:plain
Virsh Addressは以下
qemu+ssh://pike@192.168.0.102/system
※pikeはUbuntu Sudoユーザー
 

JUJUコントローラデプロイ

KVM仮想マシン作成
PXEブートを指定。
BootオプションはMAASでDHCP有効にしているNWに接続するNICPXEブートを有効にする
f:id:pikesaku:20180212154940p:plain
f:id:pikesaku:20180212153806p:plain
※作成時に起動するとMAASからPXEブートするがパワーオフで停止する。
 
 
②MAAS Web画面上でPODリフレッシュ & タグ付け
上記操作でコミッションが行われ、完了後仮想マシンは停止する。
以下画面より仮想マシンにタグ付けする。
f:id:pikesaku:20180212183656p:plain
f:id:pikesaku:20180212183734p:plain
 
 
③MAASサーバにJUJUクライアントインストール

sudo add-apt-repository -u ppa:juju/stable
sudo apt install juju

 

juju add-cloud mymaas

以下を指定
"maas"
"http://MAAS_IPアドレス:5240/MAAS/"
 

juju add-credential mymaas

"MAASエンドポイントキー"
f:id:pikesaku:20180212162112p:plain
 
 
④JUJUコントローラデプロイ

juju bootstrap --constraints --congfig bootstrap-timeout=6000 tags=juju mymaas maas-controller

 
 

補足1 MAASサーバ2台のIF設定(仮想ブリッジ設定例)

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto br1
iface br1 inet static
   bridge_ports ens3
   bridge_stp off
   bridge_fd 0.0
   address 192.168.0.101
   netmask 255.255.255.0
   gateway 192.168.0.1
   dns-nameservers 192.168.0.251
   dns-search example.com


auto br5
iface br5 inet static
   bridge_ports ens10
   bridge_stp off
   bridge_fd 0.0
   address 192.168.4.101
   netmask 255.255.255.0

DRBD片系ノードを再構築する場合

シーン

ノードA,BがありDRBDでディスク同期している状態でノードAが復旧不能になり、再構築する場合
 

手順

  1. ノードBをDRBD Primaryにする
  2. ノードAを再セットアップしDRBDインストールし設定ファイルを復旧する。
  3. 以下コマンドでミラーデバイスセットアップ
drbdadm create-md リソース名

上記コマンド実行するとノードB→Aへの初期同期が始まる。
完了すると同期は正常な状態になる。(結果)

version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205 
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:10630584 nr:7624 dw:170116 dr:10494969 al:34 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Ubuntu復旧作業メモ

起動しなくなった時

リカバリモードを試す 
RecoveryMode - Ubuntu Wiki
 
リカバリモードでもダメな場合
インストールCDからBootしRescueモードに入る
 
f:id:pikesaku:20180211201940p:plain
 
f:id:pikesaku:20180211202119p:plain
 
f:id:pikesaku:20180211202155p:plain
 
f:id:pikesaku:20180211202302p:plain
 
f:id:pikesaku:20180211202332p:plain
 
f:id:pikesaku:20180211202405p:plain
 
f:id:pikesaku:20180211202418p:plain
 
f:id:pikesaku:20180211202443p:plain

MAASバグ

Bug #1701682 “[2.x] selecting “Settings” provides an “Internal s...” : Bugs : MAAS

DRBDクラスタ状態復旧メモ

両方ともクラスタから外しstandalone状態にする

 
※リソースはdataの場合

実行コマンド

drbdadm disconnect data

 
"cat /proc/drbd"出力結果

version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205 
 0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/DUnknown   r-----
    ns:2312 nr:0 dw:0 dr:2952 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

※Primary側実行結果
※Standaloneになっていることを確認
 

最新データ保有ノードをPrimaryにしてクラスタに組み込む

drbdadm primary data
drbdadm connect data

  
"cat /proc/drbd"出力結果

version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205 
 0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r-----
    ns:0 nr:0 dw:2312 dr:640 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

 

古いデータを保有ノードをSecondaryにしデータを破棄させてクラスタに組み込む

drbdadm secondary data 
drbdadm connect data --discard-my-data

 

状態確認(cat /proc/drbd出力結果)

Primary側

version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205 
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:0 nr:0 dw:2312 dr:640 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

 
Standby側

version: 8.4.5 (api:1/proto:86-101)
srcversion: 4B3E2E2CD48CAE5280B5205 
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:0 dw:0 dr:2952 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

 

考え方ポイント

Standaloneはクラスタから外れた状態
connect/disconnectでクラスタ接続・切断をする
discard-my-data実行時はSecondary状態である必要あり

スパニングツリー復習

以下種類があり
・Spaning Tree(ST)
・Rapid Spanning Tree(RST)
上記2つのVLAN毎に動く版
 Per Vlan ST
 Rpid Per Vlan ST
・Multi ST
 VLANをグループ化し、それ毎に動く・リージョン設定も可能。大規模向け
 
STは収束に時間がかかる
RSTで解消
ST/RSTともに完全ブロッキングパスができ、非効率
Per VlanでVlan毎にブロッキングポートを分けることができ効率化
Per Vlahは一つ一つ設定するのが大変
MSTでグループ化でき、Per Vlan問題解消。収束も高速(RST利用のため)
 
 

STまとめ

参考URL

STP(スパニングツリープロトコル)とは
スパニング・ツリー完全理解 - スパニング・ツリー完全理解---目次:ITpro
ネットワーク入門サイト - スパニングツリー
http://www.kenschool.jp/blog/?p=3201
 
ループ構成のL2ネットワークで、フレームがループしないよう制御する。
任意のポートをフレーム送受信しない状態(ブロッキング状態)にしてループを防ぐ。
パス障害発生時は、ブロッキング状態のポートをフレーム送受信可能にすることで経路の冗長化を実現。
ルートブリッジが管理フレームBPDUを定期的にL2マルチキャストに送信し状態を把握。
 
BPDUフォーマットは以下

STP(スパニングツリープロトコル)とは
f:id:pikesaku:20180127190210p:plain

 
基本動作は以下
①ルートブリッジ(BPDU送信ブリッジ)選択
②ルートポート選択
各スイッチがルートブリッジに近いポートを選択
③指定ポート
スイッチとスイッチを接続するリンクで、ルートブリッジに近い方のポートを選択
 
ルートポート・指定ポートどちらにもならなかったポートがブロッキング状態になる。

STP(スパニングツリープロトコル)とは
f:id:pikesaku:20180127155218p:plain

 
 
パス異常発生時に収束まで時間がかかる問題あり。(異常検知20秒+30秒状態再計算)

STP - ポートの状態遷移とコンバージェンス
f:id:pikesaku:20180127182100p:plain

 
 

RSTまとめ

参考URL

RSTPの役割決定手順 - ネットワーク入門サイト
RSTP状態と高速コンバージェンス - ネットワーク入門サイト
http://beginners-network.com/supplement/bpdu_frame_format.html
RSTP - BPDUフォーマット
RSTP - ラピッドスパニングツリープロトコルの設定
RSTP - ラピッドスパニングツリープロトコルとは
 
STPの収束時間問題を解消する技術(数秒で収束)
ルートポートでBDPU受信できなかった場合、代替ポートをルートポートにしフォワーディングする。
※STPブロッキングポートがRSTPでは代替ポート
RSTP利用時でもサーバ接続ポートはPortFast設定した方がよい
 

BPDUについて

・スイッチの指定ポートから送信される
・ルートポートは受信するだけ
 

STP利用時の注意点

 
トラブルに強いネットワークを作る - 安易な変更・増設は禁物,管理情報の共有を徹底しよう:ITpro
ルートブリッジが変わる危険性あり。
 
ただ、それを防ぐ機能もあり。
STPの拡張技術 - ルートガード