Category: VMware

『ヴイエムウェア、米国の「Fusion」「Workstation」開発チーム全員を解雇か』ですか・・

  儲かるエンタープライズ領域に経営資源を集中ということなんでしょうが、 時代の流れを感じさせますなあ。     “ヴイエムウェア、米国の「Fusion」「Workstation」開発チーム全員を解雇か” http://japan.zdnet.com/article/35076954/ VMware Workstationとか、無償版のVMware Serverには本当にお世話になった思い出があって、 ローカルPC上で「壊してもすぐに戻せる」WindowsやLinuxの環境を実現できるのは、 インフラ屋としては夢のような「おもちゃ」であったわけです。 おもちゃとはいえ、容易に仮想環境を構築できることで、 大変色々な技術的な勉強もさせて頂きました。 その部門が開発チーム全員解雇というのは、非常に寂しい話です。 Workstationも、現行の12のサポート期限の2017年2月25日までは安心して利用できるでしょうが、 その後はちと微妙ですね。 とはいっても、最近のVMware Workstationの利用は、 VM Importを使ってVMwareからAWSに仮想イメージを移行する検証ばっかりだったりするのですが・・   エンタープライズ領域ではまだまだ数年はニーズはあるかと思いますので、 VMwareさんにはがんばってほしいと、元VCPとしては切に願うものであります。 (数年経った後は微妙) VMware徹底入門 第4版 VMware vSphere 6.0対応 posted with amazlet at 16.01.28 ヴイエムウェア株式会社 翔泳社 売り上げランキング: 12,865 Amazon.co.jpで詳細を見る

VMwareの仮想マシンから、EMOBILE GL01Pを経由してインターネットに接続する

  VMware Workstationの場合。(VMware Serverでも基本同じ) VMware Workstationの画面から、編集→仮想ネットワークの設定を実行。 「ブリッジ先」として、ホストOSの無線LANのアダプタを指定する。 仮想マシン設定にて、ネットワークアダプタの接続方式を「ブリッジ」にしておく。   EMOBILE GL01Pでデフォルト設定されているDHCPのスコープは、192.168.1.0/24。 仮想マシンのIPアドレスが192.168.1.0/24内に設定されており、デフォルトゲートウェイとして192.168.1.1が設定されていれば、仮想マシンからインターネットに接続できる。 仮想マシンのIPアドレスとして192.168.1.0/24以外を利用している場合、GL01PのDHCP設定を変えてしまいましょう。 1、無線LANにつながった状態で、ブラウザから192.168.1.1にアクセス。 2、EMOBILE GL01P設定ツールにログイン。 3、画面左側のメニューにて、設定をクリック。ファイアウォール設定→DHCP設定にて、ホストOSに付与されるIPアドレスのレンジを仮想マシンに合わせてしまえばよし。   その他GL01Pの設定変更は、以下を参照。 emobile LTE(GL01P)の設定を変更する https://www.cyberarchitect.net/blog/archives/446 [amazon_enhanced asin=”4798124052″ /]

VMWareで、NAT設定

  VMware Serverでのお話。 VMWareでNAT設定する時、いつも「あれ?」ってなるので残しておく。こういう感じにしたいとき。 192.168.100.100 仮想マシンのIPアドレス | 192.168.100.1 仮想環境のデフォルトゲートウェイ | 192.168.100.200 ホストマシンのNAT用VMWare Network Adaptor(VMnet8) | 192.168.10.100 ホストマシンのIPアドレス | 192.168.10.1 ホストマシンのデフォルトゲートウェイ   1、VMWare Server Consoleで、Host→Virtual Network Settings実行。 2、VMnet8のVMWare Network Adaptorが有効化されていることを確認。 3、VMnet8のVMWare Network Adaptor右側の「>」をクリック。Subnetをクリックし、仮想マシン側のサブネット(上記なら192.168.100.0)を設定。次にNatをクリックし、Gateway IP addressで、仮想マシンが使うデフォルトゲートウェイのアドレス(上記なら192.168.100.1)を設定する。   4、仮想マシンのVirtual Machine Settingsで、EthernetのNetwork Connection設定が、「NAT: Used to share the host’s IP address」になっていることを確認。 5、仮想マシンのIPを設定。上記なら、デフォルトゲートウェイは192.168.100.1。DNSは環境に応じて、デフォルトゲートウェイと同じにするか、DNSのIPを設定する。 [amazon_enhanced asin=”4798122459″ /] あとは、ホストマシン側で、VMnet8のVMWare Network Adaptorにインターネット接続共有の設定をしておく。DNSとかデフォルトだと許可されてないので、プロパティでチェック入れておく。 インターネット接続共有をオンにすると、元々設定していたIPが変わったりするので、注意。設定したらipconfigでチェック。

VMWare上のホストOSで、ネットワークアダプタのドライバがインストールされない

  Windows 2008インストールしたら、ネットワークアダプタのドライバがインストールされなかった。 ホストOSのNIC用のドライバって、何を選択したらいいのかしら。 [amazon_enhanced asin=”4798122459″ /] と、思ったら、単にVMWare Toolsをインストールし忘れているだけだった。 参考: http://www.virtuatopia.com/index.php/Windows_Server_2008_does_not_recognize_VMware_Server_Network_Adaptor

「<ファイルパス>.vmdk」ファイルを開くことができません:ファイルへアクセスするために十分な権限がありません。

  Windows 7上のVMware Workstationにて、外付けHDD上に保存したVMイメージをパワーオンしようとすると、 「.vmdk」ファイルを開くことができません:ファイルへアクセスするために十分な権限がありません。 とメッセージが表示され、仮想ホストをパワーオンできない。 犯人は、WindowsのUAC(User Account Control)である。UACを無効化するか、VMware Workstationを起動する際、VMwareのアイコンを右クリック→「管理者として実行」を選択すること。  

Windows Vista上のVMware Serverで、仮想マシンが起動しない

  VMwareの仮想マシンを起動すると、物理ホスト(Vista)のI/Oランプが点滅じゃなくて光りっぱなしになり、ハングする。Ctrl+Alt+Deleteも効かない。電源長押しするしかなくなる。 そういえば以前もハマったことがあり、その時は仮想化製品にこだわりなかったもんで、Virtual PCで代替してスルーしていた。 今回はVMwareの環境が手元に必要になったため、もう少し調べてみることにした。 なんでハングするんだろう? 前回は気づかなかったが、タスクマネージャを起動させた状態で事象再現させると、メモリ使用量が99%状態でハングしていることがわかった。どうやら、仮想マシン用のメモリ領域が確保できなくて、激しくswapし、物理ホストがハングしている、または「しているように見える」らしい。 というわけで、仮想マシン用になるべくメモリ領域を確保できるようにするため、諸々設定変更した。 設定変更したこと 1. VMware側のReserved Memoryを減らす 先ず、VMwareが仮想マシン用に確保しようとする領域があまりにも大きかったため、少し自重して頂いた。 VMware Server Console(1.x系)にて、Host -> SettingsからMemoryタブを選択。 Reserved memoryが2.4GBを超えていたので、半分に減らした。   2. 物理ホスト側のSuperFetchを無効化 悪名高い、VistaのSuperfetchサービスを無効化した。 普通に、Vistaの管理ツール->サービスから、Superfetchを停止して無効化。 これで、「キャッシュ済み」にキャッシュされるメモリ領域が減り、「空きメモリ」が増える。   以上を試した結果、少しマシになった気がするが、物理ホストを起動して、最初に仮想マシンを起動する時はやっぱりOSがハングし、20分ぐらい待たされる。 ハングしている間に何が起こっているかはわからないが、おそらく「キャッシュ済み」の領域を開放し、「空きメモリ」の領域に足していっているのではないだろうか。 20分待つのはちょっと厳しいなあ・・・。まあ、普段PCの再起動はセキュリティパッチ当てた後ぐらいしかしないからいいんだけど。

VMware ESXホスト間でscpが実行できない

  2台のVMware ESX 4.1ホスト(仮想ホストではなく、Hypervisor同士)間で、scpを使ってvmdkファイルをコピーしたいのだが、connection refusedが発生し、ファイルコピーできなかった。 ちなみに、ややこしいのだが、ESXi 4.1ホストからESX 4.1ホストへのscpコピーはできる。逆はダメ。不可思議。 原因は、ESXが持つファイアウォールで通信がブロックされていたため。 一時的に解除するには、 esxcfg-firewall –allowIncoming –allowOutgoing を実行。再度ファイアウォールを有効にするためには、 esxcfg-firewall –blockIncoming –blockOutgoing を実行すること。

VMXNET3のNICアダプタがない

  vSphere 4.1上に、ゲストOSとしてWindows Server 2008 R2をインストール。 仮想NICとしてVMXNET3を選択したところ、OSインストール後、NICが認識されていない。 これは、VMware Toolsがインストールされていないため。VMware Toolsインストール後、OSを再起動すると仮想NICが認識された。 なお、ゲストOSインストール時、デフォルトでは仮想NICとしてE1000が選択されるが、VMwareの推奨としては最新のVMXNET3のようだ。機能的にエンハンスがあるだけでなく、パフォーマンスも向上しているらしい。 参考:Which NIC for Windows 2008? E1000 or VMXNET 3? http://communities.vmware.com/thread/212090

Virtual PCのイメージをVMwareに変換

    前回インストールしたVMware vCenter Converterを使用し、Virtual PCのイメージをVMware(ESXi用のバージョン7イメージ)に変換する。 vCenter Converterを起動。 「マシンの変換」をクリック。     今回は変換元がVirtual PCであるため、ソースのタイプは「バックアップイメージまたはサードパーティ仮想マシン」を選択。 仮想マシンファイルとして、Virtual PCの.vmcファイルを選択。次へ。   変換後のイメージをESXi上に保存するため、ターゲットは「VMware Infrastructure仮想マシン」を選択。 vCenterのホスト名、ログインユーザ等を入力し、次へ。   インベントリを選択し、次へ。   ターゲットとして保存先のESXiを選択し、次へ。   Converterの機能で変換時にディスクのサイズ等を変更することもできるが、今回は何も変更せず、次へ。   終了。   変換が行われるので、変換終了後にVMwareの仮想イメージを起動し、動作確認。   特に問題なし。    

VMware vCenter Converter Standaloneをインストール

  Windows Virtual PC上に構築したLinux上でちょこちょこ開発していたPHPのソースを参照しようとしたところ、そもそも手元にVirtual PCの環境がなくなっていることに気付いた。せっかくだからConverterの検証もかねて、Virtual PCからVMwareへの仮想イメージの変換を行った。 先ずはvCenter Converterのインストールから。 ダウンロードページは以下。 http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vcenter_converter_standalone/4_0 ユーザ登録が必要になる。ユーザ登録時に入力したメールアドレスにメールが送られてくるので、そのメール中の「Activate Now」をクリック。遷移先のページでvCenter Converterのモジュールをダウンロードできる。 ダウンロード後、インストーラを実行。 次へ。   次へ。   使用許諾契約に同意し、次へ。   次へ。   今回はvCenter Serverのローカルにインストールするため、「ローカルインストール」を選択し、次へ。   インストールをクリック。   終了。 次は、実際に変換を行う。変換作業の手順はこちら。