nakato’s memo

個人的メモを蓄える場所

VMware Esxi7 仮想マシンが起動中でもコピーする方法

掲題のメモ

 

環境

  • VMware Hypervisor (ESXi) 7.0 u1

ESXi へ SSH ログインを実施しますので、事前に SSH と ESXi Shell のサービスを起動しておきましょう。

 

作成の流れ

ESXi へ SSH 接続

Teratermを起動し対象のesxiのIPアドレスを入力し、SSHでOKを選択します。

TCP port 22, SSH version SSH2, IP version AUTO 

ユーザー名(今回はroot)を入力後、”キーボードインタラクティブ認証を使う”のラジオボタンを選択し”OK”を押します。パスワードを入力してログインします。

認証方式:プレインパスワードを使う

ログイン後に対象の仮想マシンがある階層まで移動します。(datastore1内のcenos7を今回は対象にしています)

cd /vmfs/volumes/<データストア名>/<仮想マシン名>

 

[root@localhost :¯] cd /vmfs//volumes/datastore1/centos7/

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7]

 

スナップショットを取得(ロックを外す)

仮想マシンのスナップショットを取得するために、仮想マシンのID、vmidを以下のコマンドで取得します。(今回はgrepcentosのみを表示させています)

vim-cmd vmsvc/getallvms

 

[root@localhost :/vmfs/volumes/f7654b0e-41d92a65] vim-cmd vmsvc/getallvms |grep cent Skipping invalid VM '14'

16  centos7  [datastore1] centos7/centos7.vmx

 

[root@localhost :/vmfs/volumes/f7654b0e-41d92a65]

 

確認したvmidを指定して、スナップショットを作成します。スナップショット名は任意です。(スナップショット名をtest123としています)

vim-cmd vmsvc/snapshot.create <仮想マシン ID (vmid)> <スナップショット名>

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] vim-cmd vmsvc/snapshot.create 16 test123 ]Create Snapshot:

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7]  ] 

 

スナップショットの管理: centos7

centos7

L test123

   L 現在点

スナップショット作成後、”centos7-000001.vmdk”と”centos7-000001-sesparse.vmdk”が作成されます。仮想マシンはこのディスクで稼働していることになるため、”centos7.vmdk”のロックが外れるためコピーできる状態となります。

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] ls -l

で確認

仮想ディスク (vmdk)のコピー

以下のコマンドで仮想ディスク (vmdk) をバックアップします。-d thin でシンプロビジョニングままコピーします。

vmkfstools -i コピー元.vmdk -d thin コピー先.vmdk

 

実際に使用したコマンド

vmkfstools -i /vmfs/volumes/datastore1/centos7/centos7.vmdk -d thin /v
mfs/volumes/USB-Datastore/copy/centos7.vmdk

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] vmkfstools -i /vmfs/volumes/datastore1/centos7/centos7.vmdk -d thin /vmfs/volumes/USB-Datastore/copy/centos7.vmdk

Destination disk format: VMFS thin-provisioned

Cloning disk '/vmfs/volumes/datastore1/centos7/centos7.vmdk' ...

Clone: 25% done.

Clone: 100% done.

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] 

 

スナップショットを削除

バックアップが完了したらスナップショットは不要になるので、スナップショットを削除し、仮想ディスクを統合します。(スナップショットを削除せずvmxファイルをコピーして起動しようとするとcentos7-000001.vmdkがありませんとエラーが発生します)

スナップショットを削除するためにスナップショット ID を確認します。

vim-cmd vmsvc/snapshot.get <仮想マシン ID (vmid)>

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7]   vim-cmd vmsvc/snapshot.get 16

Get Snapshot:

|-Root

--Snapshot None         : test123

--Snapshot Id        :  1

--Snapshot Descrption    : 

--Snapshot Created On   :  6/10/2021 15:42:25

--Snapshot State             :  powered off

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7]   

確認したスナップショット ID を指定し、スナップショットを削除します。

vim-cmd vmsvc/snapshot.remove <仮想マシン ID (vmid)> <スナップショット ID>

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] vid-cmd vmsvc/snapshot.remove 16 1

Remove Snapshot:

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] 

仮想ディスク(vmdk)以外のファイルのバックアップ

find コピー元ディレクトリ -not -name “*.vmdk” -exec cp {} コピー先ディレクトリ \;

今回使用したコマンド
centos7以下のvmdkファイル以外のものをcopy以下にコピーしています。(スワップファイル (vswp) やロックファイル (vmx.lck) などがコピーされませんが問題ありません)

find /vmfs/volumes/datastore1/centos7/* -not -name “*.vmdk” -exec cp {
} /vmfs/volumes/USB-Datastore/copy/  \;

 

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7]  find /vmfs/volumes/datastore1/centos7/* -not -name "*vmdk" -exec cp {} /vmfs/volumes/USB-Datastore/copy/  \:

cp: can't open '/vmfs/volumes/datastore1/centos7/centos7.vmdk.lck' : Device or resourve busy

[root@localhost :/vmfs/volumes/60952c01-ca0484f2-1176-90b11c807be2/centos7] 

最後に

copy以下にコピーされたvmxファイルを登録後に起動すれば問題なく立ち上がると思います。(以下出てきてもコピーしましたで大丈夫です)

 

質問への回答: centos7

コピーしました

 

 

otomosa.com

VMware vSphere仮想マシン スナップショットの統合

掲題のメモ

 

スナップショットの統合は、スナップショットの [元に戻す]、[削除]、または [すべて削除] の操作を実行したあと、スナップショット ディスクを圧縮できない場合に利用できます。この問題は、たとえば、スナップショットを削除しても、関連するディスクがベース ディスクに戻らない場合ことが原因で起こります。

前提条件

必要な権限: 仮想マシン.スナップショット管理.スナップショットの削除

手順

  1. vSphere Clientインベントリ内の仮想マシンに移動し、[スナップショット] タブをクリックします。
  2. 必要なスナップショット操作を実行します。
    仮想マシンのスナップショット ファイルを統合する必要がある場合は、 [統合が必要です] というメッセージが表示されます。
  3. [統合] ボタンをクリックします。
    [統合] ダイアログ ボックスが表示されます。
  4. [OK] をクリックします。
  5. 統合が正常に完了したことを確認するには、[統合が必要] 列をチェックします。
    1. vCenter Serverインスタンス、ホスト、クラスタなど、仮想マシンのリストが含まれているインベントリ オブジェクトに移動します。
    2. [仮想マシン] タブ > [仮想マシン] の順にクリックします。
    3. 列を表示アイコン をクリックします。
      [列を表示] ウィンドウが表示されます。

      [スナップショット統合] 列の表示

    4. [統合が必要] を選択します。
      「 はい」のステータスは、仮想マシンのスナップショット ファイルを統合する必要があることを示します。「 必須ではない」のステータスは、ファイルが統合されていることを示します。

docs.vmware.com

ESX/ESXi ホストのスワップファイル データストアに保存されている仮想マシン スワップ (.vswp) ファイルを別のデータストアに移行

掲題のメモ

 

Purpose

この記事には、仮想マシンをパワーオフせずに .vswp ファイルを移行する手順が記載されています。

 
Resolution

.vswp ファイルを仮想マシンと同じ場所に移行するには:

  1. 新しいデータストアがクラスタのすべての ESX/ESXi で使用できることを確認します。

  2. 仮想マシンの .vswp ファイルの格納にターゲット データストアを使用するように ESX/ESXi ホストを構成します。スワップファイルの場所をクラスタ内のすべてのホストに追加するには、クラスタ を右クリックして、設定の編集 を選択し、スワップファイルの場所 を選択し、ホストで指定されているデータストア内のスワップ ファイルを保存する を選択します。そして、ホスト レベルで構成を選択し、仮想マシンスワップファイルの場所のリンクを選択します。

    詳細については、『vSphere Resource Management Guide』の「Enable Host-Local Swap for a DRS Cluster」を参照してください。

  3. vMotion を使用して仮想マシンクラスタの別の ESX/ESXi ホストに移行します。これにより、ターゲット データストアに .vswp ファイルが再作成されます。

  4. オプションで、vMotion を使用して仮想マシンを元の ESX/ESXi ホストに戻します。
 
Related Information
.vswp ファイルをすべての .vswp ファイルを含んだデータストアから各仮想マシンのそれぞれの作業ディレクトリに移行するには、次の手順を実行します。

 

  1. クラスタ設定を 仮想マシンと同じディレクトリにスワップファイルを保存する に変更します。
  2. 各ホストの 構成 -> 仮想マシン スワップファイルの場所 が 仮想マシン ディレクトリに設定されていることを確認します。
  3. 仮想マシン -> 電源 -> ゲスト シャットダウン を右クリックして(ゲスト OS 内からの再起動またはゲストの再起動をしないでください)、再度パワーオンします。
  4. 現在は、 .vswp ファイルは元の vswp データストアから削除され、仮想マシンの作業ディレクトリで再度作成します。

 

 

Migrating virtual machine swap (.vswp) files from one datastore to another (2003956)

kb.vmware.com

 

 

日本語ページ

kb.vmware.com

Windows Serverのパスワードを初期化

以下のページを転記しています。

Windows Server 2012のパスワードを初期化しよう。

2012年10月15日 Jun Kudo

level69.net

 

以下の環境で、仮想サーバのパスワードが不明だったので、

作業前に手順を整理

vCenter Server

VMware ESXi

Windows Server2016

*結局、仮想環境から再構築したから、手順の検証はできていません。

 でも、役に立ちそうなので、そのまま記録

 

1,DVDから起動し「コンピュータを修復する」へ進みます。

2,「オプションの選択」→「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト

3,Utilman.exeをcmd.exeと置き換えます。

X:Souerces>d:
D:cd Windows system32
D:WindowsSystem32>rename Utilman.exe Utilman.exe.bk
D:WindowsSystem32>copy cmd.exe Utilman.exe

 

4,[X]で閉じた後、「オプションの選択」で「続行」して起動します。

5,「コンピュータの簡単操作」のボタンを押します。するとあら不思議、コマンドプロンプトが管理者権限で立ち上がってきます。

6,ここまでできたら何でもできます。たぶん。
サーバーマネージャ→servermanager.exe
ユーザーアカウント→netplwiz.exe
Active Directoryユーザーとコンピューター→dsa.msc

 

 

ChatGPTなどで使える文例集

以前は人工知能という単語が主流で、それを理解するために、Pythonを学習するというのがステップでした。

 

ところが、最近ではChatGPTやSORAなど、AIに関する宣伝が氾濫してきていて、Pythonなんか知らなくても使いこなせる環境に移行してきています。

 

実際は、使いこなせる人とそうでない人の差が大きくなる黎明期だと思えるので、ちょと触れてみたいとおもう方向けの、文例集のサイトを案内します。

prompt.quel.jp

【WordPress】Reverse-Proxy先にしたときに気を付けること

掲題の情報は、
EN-PC Service の 社員ブログ  saito氏の 2023/02/21 の情報です。
サイトがなくなった時の為に、メモ化します。

 

Reverse-ProxyとWordPress、それぞれの関係性

ウェブブラウザーからアクセスするURLが「 https://sample.site/blog/ 」(A)

Reverse-Proxy がアクセスするURLが「 https://origin.site/samplesite_blog/ 」(B)

(A)にReverse-Proxy が搭載されています。

(B)にWordPressが存在します。

このような関係性です。

(B)のWordPress側では以下に記載の通り設定を行います

他には、(B)の出力、特にリンクを変えるために、以下の設定を wp-config.php 先頭部分に追記します。

define('WP_SITEURL'    , 'https://sample.site/blog/');
define('WP_HOME'       , 'https://sample.site/blog/');
define('WP_CONTENT_URL', 'https://sample.site/blog/wp-content');

というところまでは、あちこちで紹介されているのですが。

 

WordPress側で行う具体的な設定はこちら

(B)のURLを、「 https://origin.site/blog/ 」(B')
としてください。パスの部分「/blog/」を(A)と(B)で同じにする、という事です。

理由は私も明確に説明できませんが。
WordPressは、REQUEST_URIに含まれるパスとローカル上のパス(この場合は /blog と /samplesite_blog )が異なる時に、パスが違うと判断するようです。

これはパーマリンク設定を ?p=xxx 以外にしたときに発生します。
どのページを開いても 404 Not Found となってしまうのです。

でも、Reverse-Proxy側で変えてもらうのは大変‥

(B)を(B')にすること自体は、WordPress側で簡単にできます。
でも、Reverse-Proxyを設定している(A)側にも、(B)が(B')に変わったよ、と言わないといけない。

そう言ってすぐ対応してくれるのなら何の問題もないのですが、いかんせんお相手は某国際機関(ってどこ??)。
手続きが大変で、変更に時間がかかると申すのです。

だから何とかしてWordPress側だけでパスを変える必要があったのです。

WordPress側のパスを、このような方法で変えました

結論、こうしました。

wp-config.php(先頭部分) に以下の設定を追記しました。

$_SERVER["SCRIPT_NAME"] = str_replace("/samplesite_blog","/blog",$_SERVER["SCRIPT_NAME"]);
$_SERVER["REQUEST_URI"] = str_replace("/samplesite_blog","/blog",$_SERVER["REQUEST_URI"]);

WordPress側でURLを置換して、(A)のパスと同じにしました。

でもまだ足りません。
サーバー内のパスは、相変わらず /samplesite_blog のままです。

そこで、このようにしました。
2案ありますが、どちらか採用しやすい方法でOKです。

案1

WordPressインストールディレクトリを、/samplesite_blog から /blog に変更(リネーム)する。

・ルートディレクトリ上の.htaccess で、 RewriteRule を使い、 /samplesite_blog を /blog に向くよう設定する。

RewriteRule ^samplesite_blog(.*)$  /blog$1

案2

WordPressインストールディレクトリを、/samplesite_blog から /blog に変更(リネーム)する。

シンボリックリンクを張る。

$ ln -s blog samplesite_blog

こんなかんじです。

これで無事期待通りの動きとなりました。
めでたしめでたし。

SEO対策として必要な事

基本これでOKですが、SEOの観点で考えると、(A)でも(B)でもアクセス出来てしまう事はよろしくありません。重複コンテンツとなるからです。

なので、(B)からのアクセスは一切許可しないようにしました。

やり方は色々ありますが、今回は wp-config.php に以下の記述をすることで対応しました。

if ( @$_SERVER['REMOTE_ADDR'] != 'xxx.xxx.xxx.xxx' ) {
	header("HTTP/1.1 401 Unauthorized");
	exit;
}

xxx.xxx.xxx.xxxは(A)のIPアドレスです。
ここからのアクセス以外をすべて拒否する設定です。

もっとシンプルに、.htaccessなどウェブサーバー側で行っても良いです。
今回 wp-config.php に記述したのは、デザイン会社さんなど別のところが.htaccessを触る可能性があるので、万が一設定を消されても良いようにした、というのがその理由です。

これで、一通り動くようになりました。

改めて、めでたしめでたし。

多段Reverse-Proxyで起きた問題への対応(2023.02.27追記)

設定を行ってから数日後、動作確認をしていたところ特定のURLでリダイレクトが発生し、しかもその時のホスト名が(B)のorigin.siteになってしまい、焦った事がありました。そのための対策は以下の通りしていたはずなのに・・。

リバースプロキシを使用している場合には WordPress をどうやって使えばよいですか ?

具体的にはこういう設定をしていたのですが、うまく行っていない。

$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];

ここで説明ですが。

WordPressは、HTTP_HOST を使ってリダイレクト先URLなどを自動で生成しています。
しかしながら、HTTP_HOSTはWordPressが動いているホスト名(B)です。リダイレクト先URLを作るのであれば、クライアント(ウェブブラウザー)上で指定されたURL(A)のホスト名を使わないといけません。

URL(A)のホスト名は、下の引用先を見てもらうと分かる通り、HTTP_X_FORWARDED_HOST ヘッダーを使えばおおよそ分かりますから、上のコードを書いてください、という話はごもっとなのです。

X-Forwarded-Host (XFH) ヘッダーは、 HTTP の Host リクエストヘッダー内でクライアントから要求された元のホストを特定するための事実上の標準となっているヘッダーです。

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-Host

 

さて、そんな前提を知っていただいたうえで。
改めて (B)にリダイレクトされた原因を探ったところ、HTTP_X_FORWARDED_HOST に入っている値がそもそも正しくなかった、という事がわかりました。

じゃあ誰がこの値を設定したの?という話ですが、おそらくWordPressを搭載したサーバーである、Xserver側ではないかと推測しています。というのは、Xserver側では既にReverse-Proxyを立てていて、アプリケーションサーバー(例えばphp-fpm)に処理を引き継いでいるように見えるからです。その時に正しくHTTP_X_FORWARDED_HOST を指定しなかったのではないか、とという推測です。

‥いやまてよ、ここまで書いてふと思ったのですが。某国際機関のReverse-Proxyを設定した人のミスかもしれませんね‥、可能性ゼロではない‥まあいいや、それ話すとまた別の話になるので。

要は、HTTP_X_FORWARDED_HOST の値が期待値ではない場合は使えないし。それを設定する相手に責任を押し付けてもしょうがない話だし。じゃあ別の方法で HTTP_HOST を変えてしまえば良いよね、という結論に達し、このように直しました。

$_SERVER['HTTP_HOST']   = 'sample.site';  // (A)のホスト名

 

これで無事、リダイレクト時に(B)のホスト名に行く事が無くなりました

ちなみに、どういうときにリダイレクトが発生するかというと、例えばこれです。

https://sample.site/news

https://sample.site/news/

最後に「/」があるかどうか、です。
具体的にこのリダイレクトが走った処理を追っかけて行ったら、 wp-includes/canonical.php でした。

canonical といえば 正規のURLにするってもの。
そう、 /new は NGで /news/ が正規のURLなのです。

ということで、そもそもHTMLコーディング時に指定したURLがいけないので、コーダーさんに依頼して直してもらいました。

WordPress側で 正規のURLに変えてくれるならいいじゃない、と思うでしょうが。
URLを変える、という事はブラウザー側でもう一度正規のURLにアクセスしなおす、という処理が発生するという事でもあります。もう一度アクセスする、という事はその間表示に時間がかかるという事です。

 

 

 

 

 

www.en-pc.jp