仮想化 – ページ 21 – OSAKANA TAROのメモ帳

2016年12月9日2016年12月9日

ConohaでUbuntu16.04 64bitを構築すると高確率で設定したパスワードが利用できない

2016/12/07 19:23～2016/12/08 18:00頃の出来事です。

先日Amazon LightsailでやろうとしていたことはRAM 512MBでは実現できないということが判明し、RAM1GBを安く使えるところを探したら、「ConoHa」で45日間810円で使える、というのをやっていることを発見。

じゃぁ、使ってみるかと早速デプロイ
すると、デプロイ時に指定したはずのパスワードでログインできないわけです。

デプロイ時、パスワード指定が１つしかなく、しかもマスクをされるので、入力を間違ってもわからないわけなんですが
その後、５０回以上試したところ、Ubuntu 16.04 64bit環境では５回ぐらいしかログインに成功しませんでした。
これがCentOS7.2 64bit環境だと３回中３回成功です。

途中、入力間違いが無いようにコピー＆ペーストを使ってみても状況は変わらなかったので、非常に謎。

サポートに問い合わせるも２日経過後も原因不明とのこと。

果たしてConoHaを利用することはできるのでしょうか・・・

以下、メモ書き

1. 「Ubuntu 16.04 64bit」を選択し、rootパスワードとしてとある文字列指定して、仮想インスタンスをデプロイ
2. コンソール画面開いてログインを使用とするも、パスワード違っている、としてログインできない・・・

始めてConohaでUbuntu 16.04をデプロイしたら、１枚目の画面で３分ぐらいとまって、ログイン画面が出たんだけど、指定したパスワードでデプロイされていないようでログインができない・・・再作成する羽目になったよ・・・ pic.twitter.com/qLAkUTguRN

— OSAKANA TARO (@osakanataro2) 2016年12月7日

3. パスワード入力間違ったかなぁ、と、rootパスワードが分からない場合の対処を調べる
4. Conohaの場合、対処はない、らしいので、新しくもう１つの仮想インスタンスをデプロイ
5. うっかり間違えて「Cent OS 7.2 64bit」でデプロイしてしまっていたが、ログインできることを確認
6. もう１つ新しい仮想インスタンスを、「Ubuntu 16.04 64bit」を選択し、デプロイ
7. 今度はログインに成功
8. 最初のは入力し間違いだったのだろう、と納得して、セットアップ開始
9. 途中うっかり操作を誤って、まともに動作しないようにしてしまう
10. 仮想インスタンスを新しく作らなくても「再構築」で作り直せる、というのを知る
11. というわけで、操作を誤った仮想インスタンスに対して「Ubuntu 16.04 64bit」で再構築
12. ログインできない
13. おっかしいなぁ・・・と、再度「再構築」
14. ログインできない
15. エディッタに書いたパスワード文字列をコピー＆ペーストして「再構築」
16. ログインできない
17. コンソールでのパスワード文字列入力もコピー＆ペーストできるのを知って再ログインを試みるも失敗

ログインするときも、ここにコピペして「送信」してからエンターキー入力をしているので入力間違いは無いはず pic.twitter.com/FFz7vQiUCN

— OSAKANA TARO (@osakanataro2) 2016年12月7日

最終的に、最低でも４０回は再構築したはずで、もしかすると５０回を超えてるかも？
それだけの回数を行って、ログインに成功したのは3回程度でした。

とりあえず、今日のConohadでのUbuntu 16.04セットアップチャレンジはコレで最後・・・コピペでP@ssword01を入れて再構築、起動、コンソール開いて、root(エンター)、「テキスト送信」開いてコピペでP@ssword01貼り付け「送信」、(エンター)→失敗 pic.twitter.com/sgWrA0Qfxa

— OSAKANA TARO (@osakanataro2) 2016年12月7日

で・・・問い合わせを行っているのですが、サポートに連絡をして、受け付けましたという連絡があったのが12/08 10:20

連絡がないのでとりあえずもう１回チャレンジしてみる

午前中のconohaでのUbuntu 16.04デプロイチェック…連続で２回設定したはずのパスワードでログインに成功したが、そのあと３連続で失敗。やっぱりクソ pic.twitter.com/61j6bO4SH0

— OSAKANA TARO (@osakanataro2) 2016年12月8日

それでも連絡がないので、15:55にチャットで連絡をとってみる(下記のツイート画像は9時台ですが、その後も実験しています)

いまだにconohaのサポートから連絡がないので、チャットで問い合わせ開始

— OSAKANA TARO (@osakanataro2) 2016年12月8日

原因不明、解決見込みも不明、とのこと

で・・・そこから丸一日経ちましたが、原因不明、解決見込みも不明、だそうな

ちなみに、パスワード文字列は「ILoveCOnoha1!」というやつでも現象が発生しています。
アンチウイルスソフトやネットワーク環境固有の問題も疑い、３箇所でそれぞれアンチウイルスソフトも違う場所から操作を行っても現象は発生。

いったいなんなのか・・・・

というわけで、無駄に時間を使わせてるワリに、いまだに利用できないConoHaはクソ！

なお、この試行錯誤に使った29円、支払う必要あるの？と聞いたところ、クーポンによる値引きが適用されましたとさ。
(確認しなかったら適用しないつもりだったんだろうか？）

2016年12月8日2016年12月7日

Amazon Lightsailのインスタンスを消す際の手順キャプチャ

Amazon LightsailのRAM 512MBのインスタンスが、１ヶ月目無料、ということなので、いま構築しようとしているメールサーバの検証用に使ってみるかな、と試してみた。

が・・・やってみるとRAM 512MBだとメモリが足らず、必要なソフトウェアが全然起動しなかった。
SSDを使っていることだし、ローカルディスクのswapfile作ってみたらどうなるかな？と試してみたところ、ソフトウェアは起動したものの、今度は負荷でインスタンス全体がまともに動かなくなった・・・

というわけで、RAM512MBでは使い物にならない、ということで、作成したLightsailのインスタンスを消すことにしたので、その手順キャプチャを一挙公開。

ちなみに、構築手順もキャプチャを撮ってはいたものの、どうせ、こんなんは、よくある記事なので省略です。

1. 仮想マシンインスタンスの「Delete」タブを開きます

2. 「Delete」ボタンを押し、表示される確認に「Yes」とこたえます

3. 削除中…

4. 削除完了…なんだけどエラー。これは問題ないエラー表示
いままで「ubuntu-webserver」インスタンスのページを開いていたが、該当インスタンスが削除されたので、そのページが表示出来ない、というエラー。

5. 続いて固定IPの削除をするため「Resouces」の「Networking」にある該当IPアドレスをクリック

6. 「この固定IPが割り当てられていないこと」と「割り当てていない場合、コストがかかること」が警告されているのを確認
割り当てられていない固定IPを保持していると、１時間あたり$0.005の料金が発生しますので、不要ならちゃんと消しましょう。(参考までRAM512MBの仮想インスタンスは１時間当たり$0.007です)

7. 「Delete」タブにて「Delete Static IP」を実行

8. 最終確認を「Yes」

9. 削除が完了しました

で・・・
今回のテストで約４時間インスタンスを立ち上げていたわけなのですが、費用は・・・

・・・いまのところ0ドルですが、２４時間経過後あたりで変わったりするんでしょうかね？
う～ん・・・

2016年12月7日2016年12月10日

AWSのVPSサービスAmazon Lightsailの注意点を確認した

2016/12/01よりAWSの新サービス「Amazon Lightsail」が開始された。

早速公式blogでも「Amazon Lightsail – AWSの力、VPSの簡単さ」と紹介されている。

月5ドルからという価格設定はGMOが運営しているVPSサービス「Conoha」の価格体系とほぼ同じである。

2016/12/06時点のAmazon Lightsailは、データセンタを「Virginia/us-east」のみしか選択できないので、ネットワーク的には日本から遠いという欠点があります。

それ以外で目に付く問題点はないか、「マニュアル」を読んで確認しました。

・プランのアップグレードは可能だが、現状はWebコンソールから実行できない(改善予定あり)
大きなサイズのインスタンスへアップグレードはAPIを使って実行することはできる。
しかし、現時点ではLightsail console(Webコンソール)から実行することができない。

・ディスクの増量は不可能

・プランのダウングレードは不可能

・20個のインスタンスまで作成できる

・外部からアクセスするためのIPアドレスは固定されないが、設定で固定IPアドレスも使える
各仮想マシンには、内部用IP(private IP)と、外部用IP(public IP)の２つが割り当てられる。
どちらも固定はされていない。
外部用IPに関しては固定IPアドレスを使うこともできる。

・固定IPはLightsailのユーザアカウント単位で5個まで使える
VPSをいくつたてても、使える固定IPアドレスの最大数は5個。

・使用中の固定IPについてはインスタンスの使用料金に含まれる
インスタンスで使っている固定IPについては、インスタンスの使用料金に含まれる。
インスタンスで使ってない固定IPについては、１時間当たり$0.005を請求する。
このため、インスタンスに割り当ててない固定IPは、即座に解放する必要がある。

hey’re free in Lightsail, as long as you are using them! You don’t pay for a static IP if it is attached to an instance. Public IPs are a scarce resource and Lightsail is committed to helping to use them efficiently, so we charge a small $0.005/hour fee for static IPs not attached to an instance for more than 1 hour.

・ファイヤウォールとしてLightsail firewallというものが提供されている。
転送量制限でカウントする転送量がLightsail firewallの前か後かは不明

2016年10月17日2018年5月25日

指定したデータストアがローカルディスクなのかを判定するPowerCLI

PowerShell/PowerCLIを使ってデータストアの空き容量チェックを行う過程で、ローカルディスクのVMFSは無視したい、というものがある。
ESXiホスト台数が増加することを考えると名前による除外などはやりたくない。
何らかの手法でローカルディスクかどうかを判定できないかを探した。

・Get-Datastoreで取得できる情報の範囲で確定できるものが無い
　　vSphere6であれば「ExtensionData.Summary.MultipleHostAccess」というデータストアが
　　複数のホストからアクセス可能か？というフラグ(true or false)があるが、
　　１台のホストだけ接続しているiSCSi,FCデータストアも対象になるのでは？（未確認）
・Get-ScsiLunには「IsLocal」というローカルディスク判定フラグがある
・Get-ScsiLunはデータストアを指定して実行することができる
・ESXiホストが停止しているデータストアに対するGet-ScsiLunはエラーとなる
・アクセス出来ないデータストアは「Accessible」フラグがfalseとなる

これらを元に作成した判定

$localdatastore=$false # フラグ
$datastore = Get-Datastore "データストア名" 
if($datastore.Type -eq "VMFS"){
  # VMFSだとローカルディスクの可能性があり
  # それ以外の、NFS,vsanは対象外
  if($datastore.ExtensionData.Summary.MultipleHostAccess -eq $true){
    # MultipleHostAccessがTrueなら、ローカルディスクではないことが確定
    $localdatastore=$false
  }elseif($datastore.Accessible -eq $true){
    # アクセスできるならGet-ScsiLunがエラーにならない
    $diskinquire = Get-ScsiLun -Datastore $datastore
    if($diskinquire.IsLocal -eq $true){
      # IsLocalによるローカルディスク確定
      $localdatastore=$true
    }
  }else{
    # アクセスできないデータストア
  }
}

2016年1月19日2016年10月17日

PowerCLIで対象の仮想マシンを選択してvMotionを実行

VMware vSphere環境で、PowerCLIを使って、仮想マシンのvMotionを行うスクリプトを作成した。

ブラウザを起動し、vSphere Web Clientにログインして、vMotionを実行するまでにかかる時間と
PowerShellを起動して、コマンドを実行する時間を比べると
コマンドを実行したほうがずっと早い、ということで作成した。

というか、vSphere Web Clientは重すぎ！

# 普通のPowerShell/PowerShell ISEからvSphere PowerCLIのコマンドを使うために必要な設定
Add-PSSnapin VMware.VimAutomation.Core
# vCenterサーバに接続
$VC=Connect-VIServer -User "administrator@vsphere.local" -Password "パスワード" "vCenterサーバ"  -WarningAction 0
# 仮想マシンの選択
$VM=Get-VM | Out-GridView -Title "Please select VM" -PassThru

# 選択した仮想マシンが所属しているクラスタのESXiホストリストから選択
$ESX=Get-VMHost -Location  ($VM.ResourcePool).Name | Out-GridView -Title "Please select ESXi host" -PassThru

# 選択したものを表示
Write-Host "VirtualMachine:" $VM.Name
Write-Host "Move from:" $VM.VMHost " to:" $ESX.Name

# vMotionを実行
Move-VM -VM $VM -Destination $ESX

なお、「$VM=Get-VM | Out-GridView -Title “Please select VM” -PassThru」を
「$VM=Get-VM | Select Name,VMHost | Out-GridView -Title “Please select VM” -PassThru」
という風に替えると、選択ウィンドウに表示する内容を変えることができる。

＜注意＞
WindowsにインストールされているPowerShellのバージョンが低いと「Out-GridView -PassThru」が利用できないため、動作しません。
たしか、PowerShell ver3以降が必要だったような・・・