仮想マシン技術とその展開
慶應義塾大学 理工学部
河野 健二
アウトライン
仮想マシン技術の概要
計算機を “仮想化” するには何が必要か？
計算機の “仮想化” はどうやって実現されたか？
ブレイクスルーとしての VMware Workstation
– 血と汗と涙の実装技術
誰でも (?) 作れるようになった VMM としての KVM
仮想マシン技術とクラウド
クラウドのための要素技術の紹介
Live migration
Remus
Kaleidoscope
仮想マシン技術とは？
一台の計算機を複数台の計算機として使う技術
複数の OS を “同時” に動かすことができる技術
仮想マシン：
仮想的に作り出された計算機ハードウェアのこと
仮想マシンが動く実計算機のコピーのようなもの
仮想マシン上で OS が（多くの場合）無修正で動作する
ホスト計算機
のコピー
仮想マシン
仮想マシン
仮想マシン
仮想マシン技術によって
ホスト計算機のコピーである
複数の仮想マシンを生み出す
ホスト計算機
（仮想マシンが動く実計算機）
仮想マシンモニタとは？
仮想マシンを作り出すソフトウェアのこと
仮想マシン ≠ 仮想マシンモニタ
仮想マシンのことを virtual machine や VM ともいう
仮想マシンモニタのことを virtual machine monitor や VMM ともいう
VM 上で動くソフトウェアをゲスト (guest) という
特に，VVM 上で動く OS をゲスト OS という
ホスト計算機
のコピー
仮想マシン
仮想マシン
仮想マシン
仮想マシンモニタ
ホスト計算機
（仮想マシンが動く実計算機）
仮想マシンモニタという
ソフトウェアが仮想マシン
というコピーを作り出す
Type I VMM と Type II VMM
VMM が動作するレイヤの違いによる分類
VM
ゲストアプリ
VM
VM
ゲストアプリ
ゲスト OS
ゲストアプリ
ゲスト OS
ゲスト OS
ホストアプリ
VMM
VMM
ホスト OS
ホスト計算機
ホスト計算機
Type I VMM:
VMM が裸の計算機 (ホスト計
算機) 上で直接動作する方式
Type II VMM:
VMM がホスト計算機の OS の
上で動作する方式
仮想化の方式の分類
完全仮想化 (full virtualization)
準仮想化 (para-virtualization)
仮想化のための修正を加えたゲスト OS を対象とする
ソフトウェア仮想化 (software virtualization)
無修正のゲスト OS が動作するように仮想化すること
ソフトウェアのみで仮想化を行うこと
ハードウェアによる仮想化支援機構を前提としない
ハードウェア仮想化 (hardware virtualization)
ハードウェアによる仮想化支援を用いて仮想化すること
資源の仮想化 ー CPU
安全にゲストの命令列を実行できるようにすること
「安全に」 とは VMM や他の VM を阻害しないこと
ゲストの命令列には特権命令も含むことに注意
CPU 時間をそのまま VM に与えてしまうと・・・
ゲスト OS が特権命令を実行してしまう
ゲスト OS はホスト計算機を占有していると思い込んでいるため
他の VM や VMM の状態を壊してしまう
De-Privileging
ゲスト OS を非特権モードで実行すること
ゲスト OS の特権命令により，VMS の整合性が破壊され
るのを防ぐため
特権命令を実行しようとすると保護例外が発生する
VMM では特権命令をエミュレートする
VMM に制御が移る （VMM は特権レベルで動作している）
ゲスト OS は特権命令が期待通りに実行できたと勘違いする
特権命令のエミュレート例：
ある VM が cli (割込禁止命令) を実行
保護例外が発生し，VMM に制御が移る
割込禁止の VM 宛ての割り込みは配信待ちにする
実 CPU の割り込みが禁止されるわけではない
なぜなら，他の VM では割り込みを待っているかもしれないから
センシティブな命令
特権命令の実行だけを防止すればいいのではない
正確にはセンシティブ命令の実行を防止しなければならない
センシティブ (sensitive) 命令：
ゲスト OS が直接実行してはまずい命令のこと
直接実行すると VMM やホスト OS と干渉する恐れがある
例： I/O 命令
センシティブではない普通の命令を innocuous 命令という
センシティブ命令と特権命令の関係
特権命令
センシティブ命令
すべての命令
センシティブ命令の例
システムの状態を参照する命令
例： プロセッサの動作モードを参照する命令
ゲスト OS に次のようなコードが含まれるとまずい
m ← プロセッサの動作モード;
if (m != priviledged) {
/* 何かおかしい */
panic();
}
例：プロセッサの動作モードにより処理内容が異なる命令
Intel x86 の POPF
スタック上の値をフラグレジスタに読み込む命令
» フラグのひとつは割込許可フラグ
POPF を使って割込許可フラグを変更しようとすると・・・
– 特権モードでは，割込許可フラグが変更できる
– 非特権モードでは，割込許可フラグの変更は無視される
» 無視されるだけで保護例外は発生しない
（古典的な意味での）仮想化可能な
CPU
CPU が仮想化可能 (virtualizable) であるとは，
センシティブ命令が特権命令の部分集合であること
すべての命令
特権命令
センシティブ命令
上記の包含関係が成立していれば・・・
ゲスト OS は非特権モードで動作しているため，
ゲスト OS はセンシティブ命令を直接実行できない
センシティブ命令を実行すると保護例外が発生する
資源の仮想化 ー メモリ
各 VM は物理メモリを独占していると思っている
物理メモリは 0 番地から始まる
物理メモリは連続している
実際には？
ホスト計算機の物理メモリを分け合って使っている
物理メモリは 0 番地から始まるとは限らない
物理メモリは連続しているとは限らない
にもかかわらず・・・
各 VM には 0 番地から始まる連続したメモリがあると思わ
せたい
2 段階のアドレス変換？？？
メモリを仮想化するには 2 段階のアドレス変換が必要
一段階目のアドレス変換：
二段目のアドレス変換：
ゲスト物理アドレス → ホスト物理アドレス
– VMM が両者の対応を管理している
用語：
仮想アドレス (guest virtual addr; gVA)：
VM 上の仮想アドレス
ゲスト物理アドレス (guest physical addr; gPA)：
VM 上の物理アドレス
ホスト物理アドレス (host physical addr; hPA)：
仮想アドレス → ゲスト物理アドレス
– ゲスト OS が両者の対応を管理している
ホスト計算機上の物理アドレス
通常の MMU では 2 段階のアドレス変換はできない
通常の MMU を使って 2 段階変換を実現する方法は？
資源の仮想化 ー I/O
ゲストOSは I/O デバイスを独占していると思っている
I/O デバイスを多重化してゲスト OS に見せる必要がある
ゲストOSの見ているデバイスを仮想デバイスという
Virtual
Device
Virtual
Device
・ ・ ・ ・
I/O Virtualization
Device
Driver
Device
Virtual
Device
ソフトウェアによる完全仮想化:
VMware Workstation を題材に
Commodity PC の仮想化
VMware WS の成し遂げたこと
広く普及した PC プラットフォームの仮想化
古典的な仮想化技術をそのまま使うのは難しい
– trap & emulate, VMM による全デバイスの管理・・・
仮想化への障壁
仮想化できないプロセッサ：
PC ハードウェアの多様性：
Intel x86 には sensitive but unprivileged 命令がある
膨大な種類の PC 用デバイスが存在する
VMM がすべてのデバイスドライバを持つことは不可能
プレインストールされたソフトウェア資産：
PC には OS やアプリケーションがインストール済み
インストール済みのソフトウェアを使い続けられる方式が必要
VMware's Hosted Architecture
ホスト OS と共存できる構成
Type I と Type II のハイブリッド型
ホスト上の OS とアプリはそ
のまま
I/O デバイスへのアクセスは
ホスト OS 任せ
VM Monitor
CPU とメモリの仮想化
VM Driver
Host OS と VMM
の通信
VM App
I/O 処理をホストに
丸投げ
VMware WS における CPU 仮想化
BT (Binary Translation)
Innocuous 命令は直接実行する
Sensitive (either privileged or unprivileged) 命令はエミュレート
エミュレータ呼び出しに置き換える
多くの場合，インライン展開してしまう
mov
mov
popf
cmp
・
・
%ecx, %edi
%esi, $2
%esi, %ecx
・
・
実行したいゲストのコード
Binary
Translation
・
・
mov
%ecx, %edi
mov
%esi, $2
《call emulator》
cmp
%esi, %ecx
・
・
実際に実行するコード
BT で除去できない Sensitive 命令
ページテーブル，割り込みベクタ等へのアクセス
通常の mov 命令でアクセスされるため，
BT で削除するのは難しい
どうやってページテーブル等へのアクセスだと知るの
か？
VMM のほうでメモリ保護しておく
trap が頻発するならエミュレータ呼び出しに切り替える
trap の頻度によって，
エミュレータ呼び出しを使う場合と mov 命令を使う場合とを
適応的に切り替える
メモリの仮想化
ゲストの仮想ページ
仮想 CR3
(virtual)
page table
gVA → gPA
ゲストの物理ページ
CR3
ホストの物理ページ
page table
二段階のマッピングをどうやって実現するの？
gPA (?) → hPA
Shadow Page Table
ハードウェアによるアドレス変換に使われるページテーブル
Shadow Page Table に gVA → hPA の対応を格納する
ゲストの仮想ページ
仮想 CR3
(virtual)
page table
gVA → gPA
ゲストの物理ページ
CR3
ホストの物理ページ
shadow
page table
gVA → hPA
HW はこちらを使う
I/O の仮想化
I/O の仮想化は鬼門
性能への影響が大きい
多種・多様なデバイスに対応するため，
開発コストがかさむ危険がある
VMware Workstation のアプローチ
VMM 自身はデバイスドライバを持たない
VMware hosted architecture の採用
I/O デバイスへのアクセスはすべてホスト OS に丸投げ
仮想化するデバイスを絞り込む
標準的な PC デバイスのみを仮想化する
– PS/2 キーボード，PS/2 マウス，フロッピー，IDE/ATA
– ATAPI CD-ROM, AMD PCNet Ethernet などなど
VMware WS における I/O 処理
ポートを通じて I/O 操作を行う
IN 命令： 指定した I/O ポートからデータを読み込む
OUT 命令： 指定した I/O ポートにデータを書き込む
いずれも特権命令
IN/OUT 命令を VMM で trap & emulate する
基本的に VMApp に処理を丸投げする
VMApp はホスト OS の機能を使って I/O 処理を行う
例： ディスクブロックの読み出しであれば，
仮想ディスクを読み出す read() を行う
仮想化対象のデバイスを絞り込むことで・・・
仮想化する必要のある I/O ポートが少なくてすむ
デバイスに対応するための VMApp 上のコードが少なくて済む
パケットの受信
VMApp
3. ask packet
transfer
2. select()
returns
VMNet Driver
Guest OS
5. copy packet &
raise virtual IRQ
Virtual NIC
VMDriver
4. World
Switch
Host Ethernet Driver
Host OS
6. IN/OUT to I/O port
7. VMApp の呼び出し
VMM
1.Device Interrupt
Ethernet H/W
VMM World で割込を受け取ると，
Host World にスイッチしてから，
Host OS でパケットを受信する
オーバーヘッドの削減
理想的な仮想デバイス・インターフェスを用意する
例： 単一の OUT 命令でパケット送信可能な NIC
IN/OUT 命令のエミュレートに必要な World Switch が減る
ゲスト OS には理想デバイス用のドライバを入れる
仮想化のオーバーヘッドを軽減するため，
ゲスト OS 側で少し仮想化に対応してもらう
準仮想化 (paravirtualization) の考え方
仮想化のためのハードウェア支援と
KVM
ハードウェアによる仮想化支援
ソフトウェア仮想化は大変
特に x86 は仮想化との相性が悪い
Sensitive but unprivileged 命令
Hardware-walk のページテーブル
– ソフトウェア TLB であればまだ楽
完全仮想化は地獄．VMware はたいしたもの
ハードウェアで仮想化を支援しましょう
仮想化を実現するソフトウェアがシンプルにできる
必ずしも性能が向上するわけではない
当然の流れ
Intel VT, AMD-V, などなど他にもたくさん
Intel VT とは？
Intel Virtualization Technology の略称
仮想化支援のための一連の新機能
CPU の仮想化のための
I/O の仮想化ための VT-d
IA-32 用の VT-x
IA-64 用の VT-i
Virtualization Technology for Directed I/O
今回の対象は，VT-x と VT-d
AMD の仮想化支援はだいたい同じ
細かいところが違うが，概念的には（近似的には）同じ
VMX モード
リング保護とは直交した新たな保護モード
VMX root モード： VMM が動作するためのモード
VMX non-root モード： ゲストが動作するためのモード
アプリケーション
VM Exit
ゲストOS
VMM
VM Entry
VMX non-root
VMX root
VMX root/non-root モード
VMX root モード
従来のプロセッサとほぼ同じ動きをするモード
相違点
VMX 命令が使えること
VMX non-root モード
仮想化を容易にするための支援がなされているモード
仮想化に影響する命令やイベントはVM Exitを引き起こす
例： センシティブな命令を実行
1. VM exit が発生する
2. VMX root モードで動作する VMM に制御が移る
3. VMM では VM exit の理由を調べ，適切な処理を行う
4. VMX non-root モードに復帰する
モードの遷移
VMX root モード
(VMM)
通常モード
VMX non-root モード
(VM)
VMXON
VM Entry
VM Exit
VM Entry
VM Exit
VMXOFF
Event Injection
ゲスト OS にイベントを送り込む仕組み
VM entry 時に，指定したイベントを配信することができる
ゲスト OS から見ると
イベント = interrupt or exception
VM entry 直後に指定されたイベントが起きたように見える
したがって，ゲスト OS の IDT を使ってハンドラが起動される
VMM で補足したイベントの再送に便利
イベントの再送メカニズムをエミュレートする必要がない
EPT: メモリの仮想化支援
Extended Page Table (EPT)
guest virtual addr → host physical addr への変換を行う
ハードウェアで勝手に
guest physical addr → host physical addr
の変換を行う
ゲストOSから見ると・・・
0 番地から始まる連続した物理メモリという幻想を抱いている
CR3 はゲストOSのページテーブルを指す
– Shadow page table は不要
にもかかわらず，ゲストOSのページテーブルでは，
guest virtual addr → guest physical addr
の変換を行う
Extended Page Table の仕組み
Extended Page Table という別のテーブルを持つ
guest physical addr → host physical addr の対応表
EPT Ptr
Extended Page Table の注意点
TLB にエントリがあればオーバーヘッドはなし
通常のアドレス変換と全く同じように動作する
TLB には，
guest virtual address → host physical address
が入っている
TLB ミスのオーバーヘッドが数倍のコストになる
ページテーブルが使用するアドレスは gPA である点に注意
ページテーブルを参照するために gPA → hPA への変換が必要
TLB fill のために EPT を頻繁に参照する
CR3 → PD, PD → PT, PT → hPA の 3 回
64 bit アーキテクチャでは 4 段階のページテーブル
– 全部で 5 回 EPT を参照する
KVM の基本アーキテクチャ
KVM における仮想マシン
ホストカーネル上のひとつのプロセスと
して動作
KVM モジュール
ホストカーネル内で動作
kvm プロセスは/dev/kvm を通じて
KVM モジュールとやりとりする
QUEM プロセス
仮想マシンごとに kvm プロセスが作ら
れる
仮想マシンに割り当てられた仮想 CPU
の個数に応じてスレッドが作られる
仮想デバイスのエミュレーションを行う
動作モード
ゲストカーネル：
ゲスト上のプロセス：
VMX non-root/RING3
ホストカーネル：
VMX non-root/RING0
sensitive な処理を行うと，
VM exit が発生する
VMX root/RING0
ホスト上のプロセス：
VMX root/RING3
デバイスへのアクセスとメモリ管理
デバイスの仮想化
QUEM によるデバイスエミュレーションを利用する
ゲスト OS がデバイスにアクセスすると・・・
– VM exit が発生し KVM モジュールに処理が移る
KVM モジュールは必要に応じて QEMU を呼び出す
メモリ管理
Extended Page Table を使う
Extended Page Table が
サポートされていなければ，
Shadow Page Table を
使う
Intel VT-d: I/O の仮想化支援
I/O デバイスを多重化するためのハードウェア支援
DMA Remapping (IOMMU)
Interrupt Remapping
デバイスの Direct Assignment を目指す
ゲスト OS が直接デバイスを制御する
各 VM 専用の I/O デバイスが存在するイメージ
– マルチキュー NIC などの利用を想定
I/O エミュレーションのオーバーヘッドがない
ゲスト OS のデバイスドライバがそのまま利用できる
– VMM を小さくすることができ VMM の信頼性が向上する
– デバイス特有の機能を最大限に活用できる
DMA Remapping
ゲストOSが占有するデバイスのDMAを安全に行う
解決したいこと：
DMAではデータの転送先アドレスを物理アドレスで指定する
VMMでチェックすればいいのでは？
ゲストOSが物理アドレスの設定を間違えると致命的
– 他のゲストOSやVMM自身のメモリが破壊される可能性がある
ゲストOSからのDMA要求を横取りし，VMMでチェックする
– 安全性は保証できる
VMMでデバイスドライバを持つ必要が出てくる
Direct Assignment の考え方に反する
VMMでチェックせずに安全性を保証したい！
IOMMU
デバイスアドレスから物理アドレスの変換機構
デバイスアドレス：
I/O デバイスが見ている仮想アドレスのこと
Main Memory
Physical Address
IOMMU
Device Address
Device
MMU
Virtual Address
CPU
IOMMU の拡張による DMA Remap
デバイスごとに別々のデバイスアドレス空間を持つ
デバイスごとに別々のアドレス変換表を持つ
プロセスごとに別々のページテーブルを持つのと同じ
ゲストOSが指定した gPA に書き込まれることを強制できる
デバイスアドレス変換表では，
guest physical addr → host physical addr
の変換を行う
Address Translation Table
PCI requester ID
Device
mapping
structure
仮想マシン技術とクラウド
仮想マシン技術のもたらすもの
計算機そのもののカプセル化
計算機を物理的なハードウェアから分離できる
計算機を 「電子的に」 移動・複製が可能になる
カプセル化の手順
VM のスナップショット機能により，計算機を “カプセル化”
“カプセル化” した計算機を複製・移動する
計算機をいつでもどこでも好きなところで好きな数だけ実行できる
スナップショットはただのデータ．複製も移動も容易
スナップショットを編集することも容易
カプセル化の仕方を少し変えると・・・
VM cloning: 計算機のコピーを on demand に素早く作る技術
Live migration: 計算機を止めずに移動する技術
Remus: 待機系の計算機をうまく作る技術
仮想化とクラウド
クラウドコンピューティングが広く利用されている
特長の一つとして，リソースの伸縮性（Elasticity）がある
メモリや CPU など，リソースの増減を自在に行える性質の
ことで，負荷状況に合ったリソース量を維持できる
負荷増加時には，新たに VM を生成してリソースを追加する
現行のクラウドサービス（例：Amazon EC2）
VM 1
負荷が大きく，
処理仕切れない
VM 2
インターネット
VM 3
ロードバランサ
新たな VM を生成
（= インスタンスの追加）
VM Cloning
稼働中の VM のコピーを作る技術
1.
リソース追加に時間がかかり，突発的な負荷増加
に素早く対処できない
VM の起動は，時間を要する処理であるため
2.
メモリの無駄遣いが生じる
3.
Amazon EC2 では VM の起動に約 2 分かかる
一時的に少しだけリソースを増やしたい場合でも，
フルサイズのメモリを割り当ててしまうため
VM 起動直後のパフォーマンスが低い
起動直後はキャッシュが存在しないため
Previous Work
Live VM Cloning with SnowFlock [Lagar-Cavilla et.al. ’09]
負荷増加時に，VM のクローンを迅速に作成する手法
親 VM の最低限の情報からクローンを作成し，稼働させる
子 VM のメモリ内容は，オンデマンドにコピーしていく
クローンを作成
へアクセスしたい
へアクセスしたい
親 VM
子 VM 1
子 VM 2
メモリ
メモリ
メモリ
オンデマンドにコピーする
子 VM 生成直後のパフォーマンスが著しく低下する
負荷が長期間にわたって増加する場合は大きな問題に
ならないが，短期的な負荷増加の場合は問題となる
提案：Kaleidoscope
クローン VM 作成に要する時間を短く抑えつつ，VM
起動直後のパフォーマンスを保つクローニング手法
提案手法の特長
負荷増加時，クローン VM を迅速に生成できる
クローン VM 起動直後のパフォーマンス低下が小さい
ユーザのニーズに応じたメモリ割り当てにより，無駄がない
負荷増加時の挙動
Amazon EC2
SnowFlock
新 VM 作成時間
新 VM 稼働
クローン VM 稼働（パフォーマンス低下）
time
time
クローン VM 作成時間
Kaleidoscope
クローン VM 稼働
time
アプローチ
二つのメカニズムを用いて，クローン VM 起動後の
パフォーマンス低下を防ぎ，無駄なくメモリを使用する
VM state coloring
クローン VM が起動後に必要としそうなデータを
起動前にプリフェッチする or VM 間で共有する
クローン VM 起動後のパフォーマンス低下を防ぐことができる
Fractional allocation
VM state coloring によってプリフェッチされたメモリ領域以外
にはメモリを割り当てない
プリフェッチされた領域以外にアクセスされた場合は，メモリを割り当
てて親 VM からオンデマンドにメモリ内容をコピーする
クローン VM に対するメモリの無駄遣いをなくすことができる
実環境でのパフォーマンス評価
CPU 使用率の制限を変化させながら，要求を満たせなかった
時間の累計を測定した
Kaleidoscope は従来の Elastic Cloud よりも，要求を満たせ
なかった時間が短く，高いパフォーマンスを出すことができた
Kaleidoscope はスレッショルドが 90 % の場合でも，Elastic Cloud
の
スレッショルド 50 % 時よりも高いパフォーマンスを出せた
低パフォーマンス
VM Creation Threshold = 90 (%) とは，
システム全体としての CPU 使用率が 70 ~
90 %
になるように，リソースの増減を行うことを表す．
VM Creation Threshold = 60 (%) ならば，40 ~
60 %
マシンに無理強いする環境
Live Migration
VMを稼働させたまま別の物理マシンに移送する技術
移送時のシステムのダウンタイムを最小化し、システムの
移送による影響を隠す
HWのメンテナンスやアップグレードを容易にする
サーバを落とすことは大きい損害に繋がる
ディスクの移送は行わない
データセンタ環境を想定し、各VMはネットワークストレージに接
続していることを仮定
Live Migration
VM１
VM２
VM２
仮想マシン１
稼働
中
VM３
仮想マシン２
反復的ダーティページ転送
Push Phase
最初は全てのページを転送
ダーティページが一定以下に
なるまで反復的に繰り返す
最初のメモリコピー：
全てのメモリページを転送
ダーティページの反復的転送
ダーティページが一定以下に下がるまで反復
Stop-and-copy Phase
VMを停止させ、残っているダ
ーティページ、CPUレジスタを
転送し、制御を移す
システムがダウンしているた
め、ダーティページが発生しな
い
VMを停止させ、残りダーティページ
と仮想CPUの情報を転送
移送先のVMでコントロール再開
VM稼働
VM停止
実験 ウェブサーバ移送時のスループット
テスト環境
Dell PE-2650 サーバー(2Ghz Dual Processor with 2GBメモリ)
一つの512KBファイルを100クライアントに続けてHTTPで転送
２回のダーティページコピーの後、Stop-and-copy段階に入る
サーバーのダウンタイムは165ms
スループット（Mbit/sec)
時間の流れ（sec）
Remus
サービス提供マシンとバックアップマシン(待機系)を利用
Live Migration のメモリコピー手法を利用しHW故障から
、サービスを保護する
同期の負担を軽くし、サービスへの影響を小さくする
クライアントに気付かれることなく制御を切り替える
サーバの状態（例：コネクション）を保持する
サーバ
ハードウェア
故障発生
同
期
待機系
同
期
同
期
最新の同期点から実行再開
Remusの動作
メモリのコピーに live migration のメモリコピー手法使用
ハードウェア故障が発生した場合チェックポイントまで戻る
送信パケットをバッファに入れ，チェックポイント取得後解放する
(A)のStop-and-copy Phaseが終わった時点をチェックポイントとして保存
バッファリングせず送信すると、チェックポイントに戻った時に同じメッセージを送信してしまう
待機系のディスク書き込み作業を非同期に処理する
ディスクアクセスの遅延を隠蔽
チェックポイント後待機系のディスクに書き込み作業を実行
移送元
移送先
Buffer
まとめ
仮想マシン技術
どのようにして計算機を仮想しているのか？
VMware Workstation と KVM を題材に
仮想マシン技術とクラウド
仮想マシン技術はクラウドと相性がよい
動的に計算機を
作り (cloning)
移動 (migration) し
待機 (standby) させることができる
© Copyright 2024 ExpyDoc
