Monthly Archives: 1月 2013

Proxmox上のOpenVZ仮想マシンをCLIでlive motion


Proxmox 2.xでは、共有ディスク無しでのホストサーバ移行(Live Motion/vMotion)みたいなことができる。
Web GUIでの方法はわかったが、CLIでのやり方についてのドキュメントが見つけにくく難航した。

使用するコマンド「pvectl」

ただし、このコマンドは、自サーバ上のみのコントロールを担当する。

「pvectl list」で、サーバ上にある仮想マシンリストを表示

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       102 server2.osakana.net  running    1280       30.00
#

他にもサーバがある場合は以下の様な形で他サーバに対してssh経由でコマンドを発行して状態を取得する。

root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

移動させる時は「pvectl migrate VMID サーバ名 -online」

root@ns5:~# pvectl migrate 101 pve2 -online
Jan 31 15:56:51 starting migration of CT 101 to node 'pve2' (192.168.1.102)
Jan 31 15:56:51 container is running - using online migration
Jan 31 15:56:51 starting rsync phase 1
Jan 31 15:56:51 # /usr/bin/rsync -aHAX --delete --numeric-ids --sparse /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:31 start live migration - suspending container
Jan 31 15:57:31 dump container state
Jan 31 15:57:32 copy dump file to target node
Jan 31 15:57:32 starting rsync (2nd pass)
Jan 31 15:57:32 # /usr/bin/rsync -aHAX --delete --numeric-ids /var/lib/vz/private/101 root@192.168.1.102:/var/lib/vz/private
Jan 31 15:57:35 dump 2nd level quota
Jan 31 15:57:35 copy 2nd level quota to target node
Jan 31 15:57:36 initialize container on remote node 'pve2'
Jan 31 15:57:36 initializing remote quota
Jan 31 15:57:37 turn on remote quota
Jan 31 15:57:38 load 2nd level quota
Jan 31 15:57:38 starting container on remote node 'pve2'
Jan 31 15:57:38 restore container state
Jan 31 15:57:39 removing container files on local node
Jan 31 15:57:40 start final cleanup
Jan 31 15:57:40 migration finished successfuly (duration 00:00:49)
root@pve1:~ #

で、うちの環境だと、CPUがpve1はIntel, pve2がAMDなので、移行後の起動に失敗する。
なので、別途、起動させる必要がある。

root@pve1:~# ssh root@pve2 pvectl start 101
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.201
Setting CPU units: 1000
Setting CPUs: 1
Container start in progress...
root@pve1:~#

これで、以下のような感じで移行が完了する。

root@pve1:~# pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       102 server2.osakana.net  running    1280       30.00
root@pve1:~# ssh root@pve2 pvectl list
Use of uninitialized value in printf at /usr/bin/pvectl line 46.
      VMID NAME                 STATUS     MEM(MB)    DISK(GB)
       101 server1.osakana.net  running    1024       8.00
       103 server3.osakana.net  stopped    1024       10.00
       104 server4.osakana.net  stopped    1024       8.00
# 

さて、この処理を自動化すると・・・

#!/usr/bin/bash

SERVER=pve2
for vid in `pvectl list 2>&1 |grep running | awk '{ print $1 }'`
do
  echo === $vid ===
  echo pvectl migrate $vid $SERVER -online
  pvectl migrate $vid $SERVER -online
  ssh root@$SERVER pvectl list 2>&1 |grep  stop | grep $vid
  echo ssh root@$SERVER pvectl start $vid
  ssh root@$SERVER pvectl start $vid
done

ほんとは、移行後に起動しているか確認した上で、pvectl startを実行させるべきなんだろうけど、起動状態でpvectl startを実行しても影響がないので、無視している。

ESXi5.1にすると起動しない仮想マシン


ESXi5.1にアップデートした後、NetApp simulatorがなぜか起動しない。

以下のエラーが出力される。

ディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」、またはディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」が依存しているスナップショット ディスクの 1 つを開くことができません。 
システムで指定されたファイルを見つかりません
VMware ESX は仮想ディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」を検出できません。パスが有効であることを確認し、もう一度やり直してください。 

これに対する回答がNetApp comminityにあった。

OnTap Simulator 8.1.1 no longer running on ESXi 5.1 free

原因はESXi5.1以降、標準ではvmkernel multiextent moduleが読み込まれなくなったため。
このモジュールは、巨大な1つのvmdkではなく、そこそこの大きさの複数のファイルでvmdkを構成するときに使うもの。

対処方法はVMware KB:「 Powering on a virtual machine after upgrading to ESXi 5.1 fails with the error: File [VMFS volume] VM-name/VM-name.vmdk was not found」にあるとおりのことをする。

概要: multiextentモジュールを読み込んで、分割形式のvmdkから、単一ファイルのvmdkへ変換する。

1. 状況確認

# ls
DataONTAP-cf-flat.vmdk  DataONTAP-s012.vmdk     DataONTAP.vmdk
DataONTAP-cf.vmdk       DataONTAP-s013.vmdk     DataONTAP.vmsd
DataONTAP-s001.vmdk     DataONTAP-s014.vmdk     DataONTAP.vmx
DataONTAP-s002.vmdk     DataONTAP-s015.vmdk     DataONTAP.vmxf
DataONTAP-s003.vmdk     DataONTAP-s016.vmdk     SimConsType
DataONTAP-s004.vmdk     DataONTAP-s017.vmdk     SimUpdateParameters
DataONTAP-s005.vmdk     DataONTAP-s018.vmdk     cfcard
DataONTAP-s006.vmdk     DataONTAP-s019.vmdk     mtoolsrc
DataONTAP-s007.vmdk     DataONTAP-s020.vmdk     nvram
DataONTAP-s008.vmdk     DataONTAP-s021.vmdk     vmware-1.log
DataONTAP-s009.vmdk     DataONTAP-s022.vmdk     vmware-2.log
DataONTAP-s010.vmdk     DataONTAP-s023.vmdk     vmware.log
DataONTAP-s011.vmdk     DataONTAP-s024.vmdk
#

2. multiextentモジュール読み込み

# vmkload_mod multiextent
Module multiextent loaded successfully
#

3. 分割vmdkのDataONTAP.vmdkを、単一vmdkのDataONTAP-new.vmdkにコピー

# vmkfstools -i DataONTAP.vmdk DataONTAP-new.vmdk -d zeroedthick
Destination disk format: VMFS zeroedthick
Cloning disk 'DataONTAP.vmdk'...
Clone: 100% done.
#

4. DataONTAP.vmdkを削除

# vmkfstools -U DataONTAP.vmdk
#

5. ファイル名の変更

# vmkfstools -E DataONTAP-new.vmdk DataONTAP.vmdk
#

6. multiextentモジュールの読み込み解除

# vmkload_mod  -u multiextent
Module multiextent successfully unloaded
#

7. 状況確認

# ls
DataONTAP-cf-flat.vmdk  DataONTAP.vmxf          vmware-1.log
DataONTAP-cf.vmdk       SimConsType             vmware-2.log
DataONTAP-flat.vmdk     SimUpdateParameters     vmware-3.log
DataONTAP.vmdk          cfcard                  vmware.log
DataONTAP.vmsd          mtoolsrc
DataONTAP.vmx           nvram
# 

変換完了後、普通に起動できました。

ESXi5.1でIntel NICを認識するけど使えないという事象


SupermicroのマザーボードPDSM4+を使ってvSphere環境を構築中、悩んだ点が1つ。

ESXi5.0だと特に問題なく動くのに、ESXi5.1にすると、オンボードNICがvmnicとして認識するけれども通信ができない、という症状。
MACアドレス認識するし、IPアドレスも普通に設定できるのに通信ができない。

いろいろ調べたら解消するための事例を発見。
VMWare ESXi, SuperMicro X7SB4, Intel 82573, Network trouble, сетевая проблема」と、その元ネタ「VMWare community」を発見

曰く

・Intel NICのうち82573E/82573Lで認識されているもので発生する
・ESXi 5.1をインストールした後に、ESXi5.0からnet-e1000とnet-e1000eドライバを適用せよ
・ネットワークがつながらないのでUSBメモリでコピーする必要あり
 ・USBメモリはFAT32フォーマット不可。FAT16でフォーマットする必要あり
 ・ESXiにUSBメモリをさす前に「/etc/init.d/usbarbitrator stop」を実行せよ
・「esxcli software vib install -d /vmfs/volumes/datastore1/ESXi500-201207001.zip -n net-e1000e」というような形でファイルはフルパス指定でコマンド実行

で、実際にためした結果、上記以外に以下の注意点もありました。
・ESXiをUSBメモリにインストールしているんだったらLinuxにマウントして直接コピーしてもよい
・さらに新しいESXi5.0のパッチ「ESXi500-201209001.zip」でもokだった。

また、ESXi5.1に最新のパッチ「ESXi510-201212001.zip」を適用しても通信は不可でした。
パッチ適用後、再度、ESXi5.0のnet-e1000eを適用する必要がありました。


2013/03/08追記

正攻法の突破方法として、対応するドライバをコンパイルして使える様にした、という事例を発見しました。

環境さんぷる「ESXi5.1のドライバを作成してみる(intel 82579LM/82574L編)」と、その更新版の「ESXi5.1のドライバを作成してみる(intel I217/I218/82579LM/82574L編)

Intelで公開されているドライバソースから作成したとのこと。
こちらは、VMwareの署名が無いドライバのため、インストールにはESXiの設定変更が必要です。

ちなみに、ここの人、他にもドライバを公開していました。
ESXi5.1のドライバを作成してみる(VIA VT6130/VT6122編)
ESXi5.0のドライバを作成してみる(Silicon Image 3124/3132/3531編)

MediaTekからGPSチップの最新版MT3332/MT3333登場!なんと5種類サポート!


MediaTekから衛星測位システムチップの最新版MT3332/MT3333が登場。
世界最初の5種類サポートと謳っています。

MediaTekニュースリリース:MediaTek Announces World’s 1st 5-in-1 Multi-GNSS Receiver SoC Solutions Supporting Beidou Satellite Navigation System
製品ページ:MT3332 GNSS SoC supporting GPS/GLONASS/Galileo system for SP, tablet, and PND market

サポートされる衛星測位システムは・・・

・アメリカ:GPS
・EU:Galileo
・ロシア:GLONASS
・日本:QZSS(準天頂衛星システム)
・中国: Beido(北斗)

新しく中国のBeido(北斗)が加わった、ということです。
Beido(北斗)は、現状では中国国内のみが対象範囲ですが、2020年までには世界全域で使える様になる計画とのこと。

また、SBAS(各国で運用している静止衛星型衛星航法補強システム)のサポートは以下の様になっています。
・アメリカ:WAAS(Wide Area Augmentation System)
・EU:EGNOS(European Geostationary Navigation Overlay Service)
・日本:MSAS(Multi-functional Satellite Augmentation System)
・インド:GAGAN(GPS-aided geo-augmented navigation)

ちなみに、このチップ、対象はスマートフォンではありません。
タブレット。GPSナビとかGPSロガーとか向けです。
前世代のMT3336とピン互換とのことなので、置き換えができるようです。(既に発売されているもののチップを単純に入れ替えてもfirmware側を対応させる必要はありますけどね)

MT3332とMT3333の違いはよくわかりませんでした。

なお、スマートフォン向けは、以前紹介したMT6228などになりますが、まだBeidouサポートのものはないようです。

DTI ServersMan SIM 3Gの申し込みには注意が必要なようです


「ServersMan SIM 3G 100をお申し込みいただきありがとうございました」というメールが届いてから20日間。

メールに記載されていた「後日、改めてお申し込み受け付け完了のご案内をメールにてお送りいたします」がこねーなー、と不思議に思っていたのですが、さすがにおかしいだろう、と問い合わせを入れてみた。

——————————————————————–
誠に恐れ入りますが、お申し込みいただいた際にご登録いただきました
クレジットカードが、何らかの理由によりエラーとなりましたため、お申し
込みはお取り消しとなっております。

お手数ではございますが、あらためてお申し込みいただけませんでしょ
うか。

なお、同じクレジットカードでのご登録の場合、再度エラーとなる場合が
ございますので、他の有効なクレジットカードをご用意いただきますよう
お願いいたします。
——————————————————————–

あー、さよですかー
エラーになったら、申込者には無通知で取り消しですかー

へーーーーー

問い合わせない限り、わからない仕様ですかー

へーーーー

たしかに、メールには、準備が完了したらメールをする、とは書いてあるけど
準備できなかったらメールをする、とは書いてないですから
仕様通りの動作ってことですよねーーー

——–
2013/01/29 18:00追記

DTIからは「ServersMan SIM 3G 100の申込不備に関するご連絡」というタイトルでメールを送信したと主張しています。

ただ、こちらでgmailのスパムフォルダを含めて確認した限りでは、そのようなものは見当たらず。
あと、それ以外のDTIからのメールはフルで到着しているようなのに、それだけピンポイントで抜けるってのも・・・ねぇ・・・

まぁ、そんなわけなので、DTIには縁がなかったとゆーことで、不要不急の契約はしないでおくことにしました。

——-
追記

1週間後に「調べたら、メール送ってませんでした」というお詫びが来るという・・・