# lvresize /dev/mapper/centos-root]]>
# xfs_growfs / #マウント先を指定
良く紹介されているqemu-imgでは変換に失敗していまい、同じく良く紹介されているStarWind ConverterはDLにーザー登録が必要な所が個人的に気に食わず
なんとか他に方法は無いものかと思って調べていたところこのNHCに出会いました。
HDDの各種ディスクイメージの類を変換可能なソフトで、vmdkからddのイメージへの変換にも対応しています。
まず変換元ファイルに変換したいvmdkを指定します。
変換先形式に「Bochs べた(RAW)」を選択
変換可能なら先に進める
変換先のファイル名を指定
変換が開始される
変換完了
これでddでV2Pしたりできます。
]]>kvmの母艦にする予定でweb上のUIから管理したかったのですがOpenstackは流石に冗長すぎるので別の方法を探していました。
そこでWebVirtMgrというものを見つけたので導入した次第です。
このWebVirtMgrはnoVNCでインスタンスのディスプレイを表示する機能を持っているため非常に便利です。
ですがそのnoVNC周りでちょっとトラブルがあったのでメモしておきます。
インストール時は公式のインストール方法をそのまま使ってます。
公式の手順どおりインストールすると一見正常に動いているように見えます。
ですが、しばらく利用しているとnoVNCが開けなくなってしまいます。
libvirtdの再起動を行うと復旧するようなので、noVNCとlibvirtdの間のセッション周りに問題がありそう。
そこで/etc/libvirt/libvirtd.conf に以下設定を追加したところ直りました。
#残りっぱなしのゴミセッションを処分させる設定。
keepalive_interval = 5keepalive_count = 0]]>先日リリースされたubuntu最新版の13.10では最初から正常なドライバが入るようになってました。
（実は13.04の頃にはすでに解決済みだったようです）
]]>sudo apt-get install lxc
wget http://lxc-webpanel.github.io/tools/install.sh -O - | bash
sudo mv /etc/default/lxc /etc/default/lxc.bk
sudo cp /etc/default/lxc-net /etc/default/lxc
sudo service lwp restart
htttp://サーバーIP:5000へブラウザでアクセス
とりあえずこれで動くはず
でもLXC Web Panelはネットワーク周りに深刻なバグ（仕様？）があるっぽい
インスタンスのネットワークをOFFにしてもネットワークつながったままだったり
DHCPが指定したIPとは別にランダムなIPを配布しちゃったり
なんか微妙なのでDHCP使わないようにして静的アドレスを割り当ててます。
]]>カーネルモジュールとして利用するよりもパフォーマンスがちょっと上昇したりしてないかなと思いUnix Benchmarksを取り直してみたところ、
以前Ubuntuで実施した時と比べて638.2→844.2の大幅な上昇で、特にファイルコピーの速度とパイプのスループット2倍弱に上昇しており、
ストレージ関連のドライバをカーネルへ組み込むのはかなり効果が大きいことが分かりました。
]]>======================================================================== BYTE UNIX Benchmarks (Version 5.1.3) System: localhost.localdomain: GNU/Linux OS: GNU/Linux -- 3.16.2 -- #1 SMP Sat Sep 20 21:50:15 JST 2014 Machine: x86_64 (x86_64) Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8") CPU 0: Intel(R) Celeron(R) CPU N2806 @ 1.60GHz (3196.8 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization CPU 1: Intel(R) Celeron(R) CPU N2806 @ 1.60GHz (3196.8 bogomips) Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization 13:22:20 up 8:36, 1 user, load average: 0.23, 0.22, 0.13; runlevel 3 ------------------------------------------------------------------------ Benchmark Run: 日 9月 21 2014 13:22:20 - 13:50:17 2 CPUs in system; running 1 parallel copy of tests Dhrystone 2 using register variables 9847127.3 lps (10.0 s, 7 samples) Double-Precision Whetstone 1644.8 MWIPS (10.1 s, 7 samples) Execl Throughput 1406.5 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 314179.0 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 89449.4 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 712974.1 KBps (30.0 s, 2 samples) Pipe Throughput 514748.3 lps (10.0 s, 7 samples) Pipe-based Context Switching 16936.3 lps (10.0 s, 7 samples) Process Creation 3903.9 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 2112.5 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 444.0 lpm (60.1 s, 2 samples) System Call Overhead 898242.2 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 9847127.3 843.8 Double-Precision Whetstone 55.0 1644.8 299.1 Execl Throughput 43.0 1406.5 327.1 File Copy 1024 bufsize 2000 maxblocks 3960.0 314179.0 793.4 File Copy 256 bufsize 500 maxblocks 1655.0 89449.4 540.5 File Copy 4096 bufsize 8000 maxblocks 5800.0 712974.1 1229.3 Pipe Throughput 12440.0 514748.3 413.8 Pipe-based Context Switching 4000.0 16936.3 42.3 Process Creation 126.0 3903.9 309.8 Shell Scripts (1 concurrent) 42.4 2112.5 498.2 Shell Scripts (8 concurrent) 6.0 444.0 739.9 System Call Overhead 15000.0 898242.2 598.8 ======== System Benchmarks Index Score 439.6 ------------------------------------------------------------------------ Benchmark Run: 日 9月 21 2014 13:50:17 - 14:18:16 2 CPUs in system; running 2 parallel copies of tests Dhrystone 2 using register variables 19450016.5 lps (10.0 s, 7 samples) Double-Precision Whetstone 3251.8 MWIPS (10.1 s, 7 samples) Execl Throughput 2862.8 lps (30.0 s, 2 samples) File Copy 1024 bufsize 2000 maxblocks 506379.9 KBps (30.0 s, 2 samples) File Copy 256 bufsize 500 maxblocks 152404.5 KBps (30.0 s, 2 samples) File Copy 4096 bufsize 8000 maxblocks 1049099.5 KBps (30.0 s, 2 samples) Pipe Throughput 1024932.7 lps (10.0 s, 7 samples) Pipe-based Context Switching 124047.7 lps (10.0 s, 7 samples) Process Creation 8042.0 lps (30.0 s, 2 samples) Shell Scripts (1 concurrent) 3139.1 lpm (60.0 s, 2 samples) Shell Scripts (8 concurrent) 465.6 lpm (60.2 s, 2 samples) System Call Overhead 1501137.5 lps (10.0 s, 7 samples) System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 19450016.5 1666.7 Double-Precision Whetstone 55.0 3251.8 591.2 Execl Throughput 43.0 2862.8 665.8 File Copy 1024 bufsize 2000 maxblocks 3960.0 506379.9 1278.7 File Copy 256 bufsize 500 maxblocks 1655.0 152404.5 920.9 File Copy 4096 bufsize 8000 maxblocks 5800.0 1049099.5 1808.8 Pipe Throughput 12440.0 1024932.7 823.9 Pipe-based Context Switching 4000.0 124047.7 310.1 Process Creation 126.0 8042.0 638.3 Shell Scripts (1 concurrent) 42.4 3139.1 740.4 Shell Scripts (8 concurrent) 6.0 465.6 776.0 System Call Overhead 15000.0 1501137.5 1000.8 ======== System Benchmarks Index Score 844.2
前回インストールできなかった理由を調べたところ、
ubuntu-serverのインストーラ(のinitrd)がカーネルモジュールの不足が原因でeMMCを認識できていない事が分かりました。
そのため別環境にインストールされたubuntuからモジュールをぶっこぬき、
インストーラ開始後に手動でロードさせることでインストーラにeMMCを認識させてインストールを行う方法を考案しました。
また、標準でインストールされるinitrdについてもモジュール不足が原因でそのままでは起動できないため、
initrdに必要モジュールをロードさせるよう設定した上で再構成する事によって、正常に起動するようにしています。
また、なぜかインストール後に/lib/modulesが生成されないため、変わりにぶｊっこぬいたモジュールを/lib/moduleに配置してます。
① 仮想環境にubuntu-server14.04をインストール
② 仮想環境にインストールしたubuntu-serverからeMMCの認識に必要なモジュールをぶっこぬき
③ Rufusでubuntu-serverのUSBインストールディスクを作成
④ LIVAにubuntu-server14.04のインストールを開始
⑤ インストール先ディスクの選択まで行ったらコンソールに移る
⑥ ②でぶっこ抜いたモジュールををinsmodしてeMMCを認識させる
⑦ インストーラに戻って、再度ディスクの認識の手順にもどす
⑧ インストール先ディスクの選択肢にeMMCが追加されるのでubuntu-server14.04をインストール
⑨ インストール完了の画面で終了せずに再度でコンソールに入る
⑩ eMMCのインストール先のルートディレクトリでchroot
⑪ /etc/modules及び/etc/initramfs-tools/modulesにmmc関連のモジュールを追記
⑫ initrdを再構成
⑬ インストーラに戻ってインストールを終了
① 仮想環境にubuntu-server14.04をインストール
② 仮想環境にインストールしたubuntu-serverからeMMCの認識に必要なモジュールをぶっこぬき
必要なモジュールはmmc_block.koとsdhci.koとsdhci-acpi.koです。
面倒ならこれ使ってください。多分大丈夫だけどなんか問題あるなら消します。
③ Rufusでubuntu-serverのUSBインストールディスクを作成
作成したUSBディスクの適当な場所にぶっこぬいたeMMC用のドライバを置いといてください。
④ LIVAにubuntu-server14.04のインストールを開始
⑤ インストール先ディスクの選択まで行ったらコンソールに移る
インストール先ディスクの選択画面
この状態だとeMMCが認識されていません。
ここでCtrl+Alt+F2を押してコンソールを出します。
このタイミング以外のタイミングでコンソールからinsmodを行うと
インストール後に/lib/modulesが空になるという謎現象が発生するので気をつけてください。
⑥ ②でぶっこ抜いたモジュールををinsmodしてeMMCを認識させる
USBディスクは/cdromにマウントされているので、②で保存したモジュールをinsmodしましょう。
insmod /cdrom/mmc/card/mmc_block.ko
insmod /cdrom/mmc/host/sdhci.ko
insmod /cdrom/mmc/host/sdhci-acpi.ko
⑦ インストーラに戻って、再度ディスクの認識の手順にもどす
Ctrl+Alt+F1
⑧ インストール先ディスクの選択肢にeMMCが追加されるのでubuntu-server14.04をインストール
Escキーでインストール先ディスクの検出をやり直してください。
するとeMMCがインストール先に表示されます。
⑨ インストール完了の画面で終了せずに再度でコンソールに入る
「インストールが完了したからディスクをはずせ」的なメッセージが出たら
先へ進まずに再度Ctrl+Alt+F2でコンソールに入ってください。
⑩ eMMCのインストール先のルートディレクトリでchroot
mkdir /liva
mount /dev/mmcblk02 /liva
chroot /liva
⑪ /etc/modules及び/etc/initramfs-tools/modulesにmmc関連のモジュールを追記
echo mmc_block >> /etc/modules
echo sdhci >> /etc/modules
echo sdhci-acpi >> /etc/modules
echo mmc_block >> /etc/initramfs-tools/modules
echo sdhci >> /etc/initramfs-tools/modules
echo sdhci-acpi >> /etc/initramfs-tools/modules
⑫ initrdを再構成
mkinitramfs -o /boot/initrd.img-3.13.0-24-generic
⑬ インストーラに戻ってインストールを終了
Ctrl+Alt+F1
将来的にはぶっこぬきの手順なしでインストールする方法を模索してカスタムisoを公開したい
あとCentOSはカーネルのバージョン的に厳しそうでした(sdhci-acpiが追加されたのはカーネル3.8から)。
多分最新のFedoraならいけます。
]]>sudo apt-get -i purge ubuntu-desktop unity-* gnome-* kde-* desktop-* account-* firefox-* python-* x11-* avahi-* gui-* font-* gedit-* yelp-* baobab brasero gconf-* aisleriot eog libbrasero-* libgoa-* libxml2 remmina rhythmbox seahorse totem vino libfs6 libxau6 libxmcp6 hud libhud2 libmeanwhile1 libufe-xidgetter0
大体消えた
ごり押し伝説
04/28 追記
インストールできました。詳細は関連記事にて。
]]>eMMCの対応が行われたのがカーネル3.8からで、当時最新だったCentOS 6.5のカーネルは2.6系だったため、対応していない事が理由でした。
しかし7月にリリースされたCentOS 7はカーネル3.10を採用していたためインストールができるのではないかと期待されていましたが、やはりインストールできませんでした。
どうやらカーネル3.8ではLIVA含むBay Trail-M + eMMCな環境へは未対応だったらしく、LIVAへインストール可能なのはpinctrl-baytraiモジュールのの実装が完了した3.13以降のカーネルとの事(参照)
もはや正攻法での解決は不可能なので、ヤケクソで最新のstableのカーネル(3.16.2)をビルドして、仮想環境上のCentOS 7のカーネルをそれに差し替えた状態のディスクイメージをLIVAのeMMCへ展開することで解決しました。
手順とか試行錯誤の過程とか書くのもだるいし特に需要も無いと思うので成果物だけ置いておきます。
なんか問題あったら消します。まともに動く保証はできないので使用はお遊びの範疇にとどめておいてください。責任は負いません。
RPM, SRPM （動作確認環境：CentOS 7.0.1406 minimal, LIVA-B3-2G-32G）
eMMCの認識に必要なモジュールはカーネルに取り込んじゃってます。
※取り込んだモジュール
mmc_core
mmc-block
sdhci
sdhci-acpi
acpi_lpss
pinctrl
pinctrl-baytrai
仮想環境のCentOS7に上記RPMをインストールした後、DDでイメージ化したデータをLIVAののeMMCへ展開してくれれば動きます。
インストール後にgrub2-mkconfigした方がいいかも
#grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
仮想環境はUEFIモードで動かす事を忘れないように気をつけてください。(VMwarePlayerならvmxに「firmware = "efi"」を追加)
]]>
それが原因で32GBのディスクのシリンダの終端位置が8GB相当の場所になってしまい、fdiskで新しいパーティションが作成できない。
こういうときはpartedを使えば、バックアップGPTテーブルの終端位置がおかしいことを検知して修正していいか聞いてくれる。
]]>