How does one get VMWare Horizon to launch in Fedora 29?
I installed it fine - accepted EULA, said "no" to all special options, said "yes" to a system scan for compatibility (which passed). But when I click the icon to launch the program, nothing happens.
Помогите, бьюсь с проблемой третий день.
Имеется ПК со встроенными LAN Realtek 8168 и внешней LAN Realtek 8139.
CPU в версиях после 6,5 не поддерживается.
Установку провожу на голое железо с нуля.
В версии 6,5 эти сетевухи не поддерживаются соответственно встраиваю драйвера в загрузочный ISO скриптом в PowerShell.
Пробовал и ISO скачивать с одновременым встраиванием драйверов и из ZIP + драйвер делать ISO.
И в одном и во втором случаях получаются ISO с которых загрузка идёт. Стадия проверки совместимости проходит но в конце вылазит ошибка о том что требуются:
vmkapi_2_2_0_0, com.vmware.driverAPI-9.2.2.0 и vmkapi_2_0_0_0, com.vmware.driverAPI-9.2.0.0 для данных драйверов, а дальше только перезагрузка, и ничего не работает.
Драйвера качал от сюда https://vibsdepot.v-front.de/wiki/index.php/List_of_currently_available_ESXi_packages
пробовал 6.0.0 6.5.0 6.5.2 везде одно и тоже.
Подскажите что делать.
Hello,
I tried to update an existing SUSE-Linux 9 on vmware Fusion 11 on High Sierra. The vm-machine was running fine with vmware 6 on macOS 10.10.
I logged in as root and ran ./vmware-install. This worked, but at some point I got the following messages, like shown in the screenshot.
I am not a total linux expert, but I need this old Linux mainly because of an perfectly working Lyx.
Thanks for all support!
EDIT: Would it make a difference, to start to install SUSE-Linux from scratch on Fution 11? (I would have do get an external DVD-Player first, that's why I am asking and not trying immediately...)
Hi guys,
I'm currently in my trail period of v14 before I pay for the upgrade from v12.5.
Most important feature is the performance gain of such a disk as by the VMware Workstation 14 Pro Release Notes
My first tests although are quite disappointing!
Preface
My host is Windows 7 x64 on a Dell Precision 7510 with 8 Core Xeon, 64GB RAM, two NVMe m.2 drives (Samsung 960 Pro & SM951).
I've installed the latest Samsung NVMe driver on the host and everything else is up to date as well.
All guests are up to date and all NVMe disks are shown correctly in the device manager (under the VMWare NVMe Controller).
All my test runs are done with a complete idle host and guest and are repeated a couple of times to ensure consistency.
My first test was done wit the VM on the "old" SM951 NVMe.
The VM/guest is a newly installed Windows Server 2016 with full VMWare tools installation.
I created 4 disks/vmdk with 60GB each:
The performance inside the guest isn't the same as on the host - not even close!
But whats more troubling is, that the SCSI-vmdk outperforms the new NVMe!!
I did another test with the VM/guest on the brand new 960Pro.
The VM is a Windows 7 with just one vmdk as a NVMe:
Here the "loss" is even worse!
It even seems there there is a "cap" in the maximum performance on a NVMe-vmdk, doesn't matter how fast the physical NVMe is.
Does anyone have suggestions for reasons to this test results?
Can/Should I approach VMWare directly with this issue?
Thanks heaps!
Soko
Hi VMWare Community,
Would like to know the reason why vSAN and VSA free capacity differ so much.
Below is a picture as an example of my claimed. From what I can see VSA storage shows a free space of appx 5.6Tb worth of free space whereas vSAN capacity has a free space of appx. 17.6Tb.
Wonder if there is any problem with the configuration ?
Appreciate the clarification.
今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。
一連の投稿へのリンクは下記をどうぞ。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-10
11日目は、2ノード vSAN を構成してみました。
vSAN-Cluster-20181211 クラスタ
2ノード vSAN については、VMware の Storage Hub サイトのドキュメントが参考になります。
ESXi が 2ノードの vSAN クラスタです。
2 ノード vSAN を構成した際は、vSAN の健全性テストの「ストレッチ クラスタ」が
すべて緑になっているか確認しておきます。
vSAN Witness アプライアンスをデプロイして、監視（Witness）ホストにしています。
監視ホストは必ず、監視対象にする vSAN クラスタの外部に配置します。
監視ホストも、他の ESXi と同じバージョンで ESXi 6.7 U1 です。
ホストのアイコンは、他の ESXi とは異なり水色です。
vSAN Witness Appliance による監視ホスト「192.168.1.29」の実体となる ESXi VM です。
これまでもネステッド ESXi による vSAN を構成していましたが、
Witness Appliance は、VMware から仮想アプライアンスの ova ファイルとして提供されています。
デプロイ先の互換性を考慮してか、仮想マシンバージョンは少し古めです。
vSAN の設定では、ストレッチ クラスタが有効になっています。
2ノード vSAN の実態は、2フォルト ドメイン ＋ 監視ホストによるストレッチ クラスタです。
フォールト ドメインは 2つ作成しされ、それぞれ ESXi が 1ホストだけ含まれます。
「1件のフォールト ドメイン障害」が許容される、というのは
1ノードの ESXi ホスト障害に耐えられるということです。
2ノード vSAN での VM のデータ配置は、オブジェクトを構成する「監視」コンポーネントが
監視ホストに配置されます。
2 ノード vSAN は、vSAN としては応用的な構成だと思うので、
ラボ環境の構築としては、やりがいがあるかなと感じます。
つづく。
今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。
一連の投稿へのリンクは下記をどうぞ。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-11
12日目は、昨日の 2ノード vSAN の補足として、
vSAN のデータ / 監視トラフィックを分離する「WTS」の構成にしてみました。
vSAN-Cluster-20181211 クラスタ（WTS 構成）
監視ホストと WTS の説明は、下記のあたりが参考になると思います。
まずはネスト環境かどうかに影響されない面での、WTS でのネットワーク構成の様子です。
vSAN ノード #1
VMkernel ポートの構成を下記のようにしています。
そして、vmk0 と vmk1 は、それぞれ別の仮想スイッチに接続しています。
このように、「vSAN」と「vSAN 監視」を使い分けて
vSAN のデータと監視のトラフィックを分離しているので「WTS」構成です。
2ノード構成だと「vSAN」によるデータ トラフィックをノード間で
直接（物理スイッチなしで）ケーブル接続することがあり、その場合は WTS 構成になります。
vmk0 と vmk1 が、それぞれ別の仮想スイッチに接続されている様子です。
物理アダプタは仮想スイッチごとに 1つずつしかありませんが、
実際に本番環境の物理マシンで構成する場合は、複数の物理 NIC でチーミングすることになります。
vSAN ノード #2
vSAN ノード #2 の VMkernel ポートの構成も、ノード #1 と同様です。
VMkernel ポートの仮想スイッチへの接続も、ノード #1 と同様です。
vSAN 監視ホスト
一方、vSAN クラスタ外部に配置してある監視ホストは、
vmk0 だけ利用し、「vSAN」トラフィックを有効にしています。
vmk1 は作成されていますが、ネットワークから切断して利用していません。
監視ホストでは、vmk0 のみネットワーク接続しています。
vmk1 を接続ている仮想スイッチ「witnessSwitch」は、アップリンクの 物理アダプタ を切断してあります。
ESXi VM と、物理 ESXi ホスト側のネットワーク構成です。
vSAN ノードの ESXi VM である「vm-esxi-01」と「vm-esxi-01」、
そして監視ホストである「vm-esxi-w-01」を、vSwitch0 に接続しています。
これはネステッド ESXi 側では vmk0 にあたる接続です。
「vm-esxi-w-01」は 2の接続がありますが、実際は ESXi VM で片方の vNIC を切断状態にしています。
この物理 ESXi のもうひとつの仮想スイッチを見てみます。
この vSwitch1 は、ネスト環境で vSAN（データ）トラフィックのための
ノード間の直接接続の役割を担当させるために作成しました。
こちらは、vSAN ノードの ESXi VM 2台だけが接続されていて、監視ホストの ESXi VM は接続されていません。
そして、物理ネットワークアダプタ（物理 NIC）の接続もないので
物理 ESXi 内部だけで利用できるローカルスイッチです。
vSAN ノード側では vmk1 にあたる、
ESXi VM の 2つ目の vNIC「Network Adapter 2」が接続されていることがわかります。
ネスト外側の ESXi VM の vNIC の MAC アドレスと、
ネスト内側の vSAN ノードでの vmk1 の MAC アドレスがことなるため、
この vSwitch1 でも「無差別モード」の通信を許可（承諾）しておきます。
ネステッド環境ではネットワーク構成の理解が難しいこともあると思いますが、
1台の物理マシンにネスト環境が収まる場合は、今回のように
物理 NIC を割り当てないローカル仮想スイッチを作成するという方法もあります。
つづく。
今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。
一連の投稿へのリンクは下記をどうぞ。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-13
14日目は、2ノード vSAN を 2セット展開しています。
ただし、本日の話題は 2 ノード vSAN 自体は直接的に関係ないもので
2 ノード vSAN を大量展開するときの Tips 紹介です。
2ノード vSAN は、ROBO（リモートオフィス / ブランチオフィス） や
エッジ コンピューティングでの利用が想定さたソリューションです。
そのため、大量に小規模クラスタを展開するケースにむけて
セットアップ作業の自動化、省力化に注目されることも多いようで、
PowerCLI スクリプトによる自動化 Tips も多く公開されています。
たとえば、VMware Sample Exchange で多くのサンプル スクリプトを見つけることができます。
vSAN Samples - Samples - VMware {code}
PowerCLI スクリプトを作成する場合には、まずは手動のコマンドライン実行で
これから自動化したい作業をしてみるとよいと思います。
たとえば、2ノード vSAN の PowerCLI セットアップで利用するコマンドラインは
下記のような様子になります。（少し古い投稿ですが）
PowerCLI で vSAN セットアップをためしてみる。（2 Node 版）
今回は、2セット構築した vSAN のひとつで、作業の省力化手法として
vSAN のプロアクティブ テスト機能のひとつである「仮想マシン作成テスト」を実行してみます。
テストは、「実行」ボタンから実行できます。
テストを実行した vSAN クラスタで、
ESXi ホストごとにテスト VM が作成 → 削除されます。
すべてのホストで成功しました。
このように、ただ正常に仮想マシンの作成 → 削除ができるか確認されます。
スクリプトなどでセットアップ処理を自動化しているような場合は、
PowerCLI からでも、このテストを実行できます。
PowerCLI コマンドレットは、Cmdlet Reference などで探すことができます。
Online Documentation - Cmdlet Reference - VMware {code}
今回利用する Test-VsanVMCreation コマンドレットのリファレンスです。
Test-VsanVMCreation - PowerCLI System.Collections.Hashtable.ModuleName Help Reference
テスト対象の vSAN クラスタです。
PowerCLI> Get-Cluster vSAN-Cluster-20181214A | Get-VsanClusterConfiguration | ft -AutoSize
Cluster VsanEnabled IsStretchedCluster Last HCL Updated
------- ----------- ------------------ ----------------
vSAN-Cluster-20181214A True True 2018/12/14 2:57:00
テストを実行します。
Test Result が「Passed」と表示され、成功したことがわかります。
PowerCLI> Get-Cluster vSAN-Cluster-20181214A | Test-VsanVMCreation | ft -AutoSize
Cluster Test Result Time of Test
------- ----------- ------------
vSAN-Cluster-20181214A Passed 2018/12/14 11:43:11
タイムスタンプから、vSphere Client 側にもテスト結果が反映されていることがわかります。
このように ボタン / コマンドひとつで手軽に VM 作成テストができるので、
vSAN デモ / ラボ環境を大量に作成するような場合にも
とりあえずの正常性確認に利用できそうかなと思います。
ただしこの機能は、初期構築時のテストで利用するものとしておき、
本番運用を開始している vSAN で頻繁に実行するのは避けたほうがよいかなと思います。
つづく。
今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。
一連の投稿へのリンクは下記をどうぞ。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-12
13日目は、2ノード vSAN を、3ノード vSAN にしてみます。
vSAN クラスタは、12日のものを流用しています。
vSAN-Cluster-20181211 クラスタ（2 ノード → 3 ノード）
2ノード → 3ノード以上 vSAN の変更については、下記のドキュメントが参考になります。
Converting a 2 Node Cluster with WTS to a 3 Node Cluster
Convert a Stretched Cluster to a Standard vSAN Cluster
2ノード vSAN が構成されています。
この vSAN クラスタを 3ノード vSAN にします。
3ノード目の ESXi と、その実体の ESXi VM です。
3ノード目は vCenter に登録ずみですが、vSAN クラスタの外部にあります。
この ESXi も、他のノードと同様にネステッド ESXi によるものです。
追加した ESXi のネットワーク構成は、既存の 2台の ESXi に合わせてあります。
今回は、既存の 2ノードのネットワーク構成は特に変更していません。
本来であれば、2ノード間を直接接続してる構成の場合、
このあとの手順の前に、物理ネットワークのケーブル結線を変更します。
3ノード目も結線できるように、物理ネットワーク スイッチを介してノード間を接続することになります。
vSAN クラスタのホストを一旦停止するか
もしくは物理 NIC 片系ずつ差し替えなどの方法で、変更しておきます。
また、追加ノードと既存ノードとの ping などによる疎通確認も、ここで実施しておきます。
（本番環境では）ここで vSAN 上の VM を一旦停止して、
すべての ESXi をメンテナンスモードにしておくほうが無難です。
ESXi のインストール手順によっては、追加ノードで vSAN で利用する予定のディスクで、
自動的にローカル データストアが作成されてしまうことがあります。
その場合、事前にローカル データストアは削除しておきます。
vSAN クラスタに、ノード#3 を追加します。
この時点ではまだ vSAN ディスクグループが作成されていないので、手動で作成します。
今回のディスクグループは、ハイブリッド構成です。
ディスクグループが作成されました。
ストレッチ クラスタを「無効化」します。
これ以降は「監視ホスト」が不要になります。
2ノード ストレッチクラスタ構成のために作成していたフォールトドメインは、削除してしまいます。
これで、ESXi ホストそれぞれがフォールト ドメインのようになる、デフォルト構成に戻ります。
ESXi ホストから、vSAN Witness タグを削除します。
これは、SSH などで ESXi にログインして作業します。
削除前は、vmk0 に witness タグが付与されています。
[root@esxi-01:~] esxcli vsan network list
Interface
VmkNic Name: vmk0
IP Protocol: IP
Interface UUID: 18f8105c-3ad7-e471-4708-005056a0bc23
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: witness
Interface
VmkNic Name: vmk1
IP Protocol: IP
Interface UUID: 2ef7105c-b8b0-d3fe-0e5a-005056a0bc23
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: vsan
削除すると、vSAN トラフィックの vmk1 の表示だけが残ります。
もともと 2 ノード vSAN だった両方のホストから、witness タグを削除します。
[root@esxi-01:~] esxcli vsan network ip remove -i vmk0
[root@esxi-01:~] esxcli vsan network list
Interface
VmkNic Name: vmk1
IP Protocol: IP
Interface UUID: 2ef7105c-b8b0-d3fe-0e5a-005056a0bc23
Agent Group Multicast Address: 224.2.3.4
Agent Group IPv6 Multicast Address: ff19::2:3:4
Agent Group Multicast Port: 23451
Master Group Multicast Address: 224.1.2.3
Master Group IPv6 Multicast Address: ff19::1:2:3
Master Group Multicast Port: 12345
Host Unicast Channel Bound Port: 12321
Multicast TTL: 5
Traffic Type: vsan
vSphere Client 確認でも、vSAN タグだけになったことが確認できます。
vSAN Witness Appliance による監視ホストは、停止しておきます。
これで 2ノード vSAN が、3ノード vSAN になりました。
（本番では）ここで ESXi のメンテナンスモードを解除して、VM を起動するとよいと思います。
監視ホストが削除されて vSAN ノードが追加されたことで、
vSAN オブジェクトの「監視」コンポーネントがリビルドされます。
そのため、構成変更直後は vSAN オブジェクトが「可用性が低下」となります。
ただしコンポーネント 2つが正常な状態なので、データにはアクセス可能な状態です。
リビルド タイマーを待つようですが、「今すぐ再同期」をすることもできます。
「監視」コンポーネントがリビルドされると、オブジェクトが正常になります。
vSAN 健全性テストでは「vSAN オブジェクトの健全性」がエラーになっていますが、
「再テスト」で解消されます。
ただし、ネスト環境なので、いくらか警告は残ります。
ノード（のディスクグループ）追加によって、自動的にデータストア容量が増加したことも確認できます。
ネステッド vSAN 環境で、2ノード → 3 ノード変更の練習をしてみる様子でした。
ちなみに、ノード #3 追加前にすべての ESXi VM で VM のスナップショットを取得しておくと
リトライしやすく検証が捗ると思います。
つづく。
今月は1日1回くらい、さまざまな ネステッド vSAN 6.7 U1 を構成してみています。
一連の投稿へのリンクは下記をどうぞ。
昨日はこちら。
ネステッド vSAN 6.7 U1 を楽しむ。2018-12-14
15日目は、2ノード vSAN を展開して、その監視ホストを
疑似的に vSAN から物理的に距離があるデータセンタに配置してみます。
vSAN-Cluster-20181215 クラスタ
2ノード vSAN の ESXi ホストと、監視ホストを別ネットワークに配置しています。
この2つのネットワークは、拠点間接続ルータ役の Linux VM で疑似的に構成しています。
今回利用した Linux は、Oracle Linux 7.5 です。
ホスト名は、VM 名にあわせて「lab-gw-01」にしています。
[root@lab-gw-01 ~]# cat /etc/oracle-release
Oracle Linux Server release 7.5
vNIC を 2つ用意して、それぞれのセグメントの IP アドレスを付与しておきます。
vSAN ネットワーク側 vNIC（vNIC#1）のネットワーク設定。
[root@lab-gw-01 ~]# ip address show ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:a0:d4:4a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.25/24 brd 192.168.1.255 scope global noprefixroute ens192
valid_lft forever preferred_lft forever
inet6 2400:4070:1b32:6100:250:56ff:fea0:d44a/64 scope global mngtmpaddr dynamic
valid_lft 14381sec preferred_lft 14381sec
inet6 fe80::250:56ff:fea0:d44a/64 scope link
valid_lft forever preferred_lft forever
監視ホスト ネットワーク側 vNIC（vNIC#2）のネットワーク設定。
[root@lab-gw-01 ~]# ip address show ens224
3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:a0:d3:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.10.25/24 brd 192.168.10.255 scope global noprefixroute ens224
valid_lft forever preferred_lft forever
inet6 2400:4070:1b32:6100:250:56ff:fea0:d39b/64 scope global mngtmpaddr dynamic
valid_lft 14293sec preferred_lft 14293sec
inet6 fe80::250:56ff:fea0:d39b/64 scope link
valid_lft forever preferred_lft forever
簡易的なルータとして動作するように、
firewalld を停止して、net.ipv4.ip_forward を有効「1」にしておきます。
なお、今回の ip_forward の設定は一時的なもので、Linux OS を再起動すると無効に戻ります。
[root@lab-gw-01 ~]# systemctl stop firewalld
[root@lab-gw-01 ~]# systemctl disable firewalld
[root@lab-gw-01 ~]# sysctl -w net.ipv4.ip_forward=1
vSAN クラスタの vCenter / ESXi と、監視ホストとで
デフォルト ゲートウェイ設定だけではネットワーク接続できない場合は、
スタティック ルートを設定する必要があります。
たとえば、ESXi では下記のように esxcli でルーティングを設定できます。
[root@esxi-01:~] esxcli network ip route ipv4 add --network 192.168.10.0/24 --gateway 192.168.1.25
[root@esxi-01:~] esxcli network ip route ipv4 list
Network Netmask Gateway Interface Source
------------ ------------- ------------ --------- ------
default 0.0.0.0 192.168.1.1 vmk0 MANUAL
192.168.1.0 255.255.255.0 0.0.0.0 vmk0 MANUAL
192.168.10.0 255.255.255.0 192.168.1.25 vmk0 MANUAL
また、vCenter Server Appliance では下記のように
Appliance Shell（appliancesh）でルーティングを設定できます。
VMware vCenter Server Appliance 6.7.0.20000
Type: vCenter Server with an embedded Platform Services Controller
Last login: Sat Dec 15 13:19:46 2018 from 192.168.1.240
Connected to service
* List APIs: "help api list"
* List Plugins: "help pi list"
* Launch BASH: "shell"
Command> networking.routes.add --prefix 24 --interface nic0 --destination 192.168.10.0 --gateway 192.168.1.25
Command> networking.routes.list
Routes:
1:
Static: False
Destination: 0.0.0.0
Interface: nic0
Prefix: 0
Gateway: 192.168.1.1
2:
Static: False
Destination: 192.168.1.0
Interface: nic0
Prefix: 24
Gateway: 0.0.0.0
3:
Gateway: 192.168.1.25
Prefix: 24
Destination: 192.168.10.0
Interface: nic0
Static: True
まず、vSAN と監視ホストとの間でネットワーク遅延が特にない状態です。
lab-gw-01 のゲスト OS で、tc コマンドを利用してネットワーク遅延を発生させます。
なお、今回は ens192（vNIC#1）に遅延設定をしていますが、
SSH 接続経路の NIC に遅延設定をいれると操作が遅くなるため、
環境によっては別方向の NIC（vNIC#2 である ens224 など）に遅延設定をしてもよいです。
設定変更まえの、Linux ルータでの vNIC の状態です。
まだネットワーク遅延（delay）をエミュレーションする設定はありません。
[root@lab-gw-01 ~]# tc qdisc show dev ens192
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
vSAN のリモートサイトの監視ホストとのネットワーク遅延は、500ms までサポートされています。
Networking and Latency Requirements
vSAN の健全性チェックにある「サイト遅延の健全性」の閾値も 500ms なので、
あえて 550ms の遅延を発生させてみます。
[root@lab-gw-01 ~]# tc qdisc add dev ens192 root netem delay 550ms
[root@lab-gw-01 ~]# tc qdisc show dev ens192
qdisc netem 8001: root refcnt 2 limit 1000 delay 550.0ms
vSAN の ESXi から監視ホストへ ping を実行しておくと、設定した瞬間に遅延が発生したことがわかります。
ネットワーク遅延がある環境なので、健全性チェックでも「再テスト」で警告となりました。
遅延設定は、下記のようなコマンドラインで解除できます。
[root@lab-gw-01 ~]# tc qdisc del dev ens192 root
設定すると、ネットワーク遅延が解消されます。
このように、手軽にネットワーク遅延のテストができたりします。
ネスト環境で、物理マシン 1台でこのような検証をする場合は、
今回のように物理マシン内にルータ役の VM も置いたりすることがあります。
つづく。
10gbE throughout my network but I'm bottlenecked at 1gbE.
Here's my scenario:
ESXi 6 host 10gb fiber to procurve 6600 switch
vCenter Server 6.5 on a VM
Storage on iSCSI via Open Media Vault with 10gbE fiber to Procurve 6600 switch (LSI 9750 RAID6 11x 4TB enterprise 7200RPM disks)
Backup appliance (may or may not be pertinent here but it's where I'm ultimately attempting to get the 10gb throughput so I'll mention it)
Iperf 2 proves 7gb+ through to an Ubuntu VM on the host to the backup appliance
Iperf proves 7gb+ from VM to VM
Iperf proves essentially all links are 10gb capable
Jumbo frames are enabled throughout. VM, switch, vswitch, vkernel, storage, appliance, etc.
However, when I transfer a file, vMotion, SCP, Backup via nbd transport, EVERYTHING is maxed out at 1G. There are NO 1G links in the mix. iSCSI is bound to the 10G link.
Is there a license for 10G within VMware? Is there a setting in the web client I haven't found? (I'm new to the vsphere web client and can't stand the networking section) Something has to be in play here that I haven't been privy to.
Thank you
Hello.
I'm hopping someone has some clue why this is happening.
Using esxi 6.5u2, passthrough GPU (NVIDIA 2080 TI) works perfectly. On 6.7U1 it works until I reboot the Windows VM. After rebooting I get error code 43 and the only working fix is to reboot the host. The GPU passtrhough only works on the first VM boot. If I reboot the VM it stops working with error code 43.
Downgrading to esxi 6.5U2 fixes the issue.
Any suggestions ?
I have been a Fusion Pro user for many years. I frequently run Debian or Ubuntu 64-bit guests on a MacOS host. Sometimes I run just one VM at a time, other times I run a few. Everything has been pretty great for the past few years ...until either MacOS Mojave or Fusion Pro 11 came along (or both). Now I'm having a really tough time.
I currently have a 2018 MacBook Pro Core i9 with 32GB RAM, a 1TB SSD and Radeon Pro 560X. I also have a 2012 iMac Core i7 with 32GB RAM and Nvidia GTX 680MX. Both run MacOS Mojave (10.14)
My iMac (and previous MacBook Pro) had been running MacOS High Sierra and Fusion Pro 10 for the past few months without issue and my new MacBook only ran Fusion Pro 10 for a few days before Fusion Pro 11 came out. It has been downhill ever since.
Both computers are now running MacOS Mojave with Fusion Pro 11 and my VMs are really hard to work with on both machines. The guests behave otherwise normally unless I let them sit idle for several minutes and then I get the spinning beach ball when trying to interact with them again. It takes anywhere from 30-40 seconds to a few minutes for the VMs to start responding to me again.
Most of the time it takes so long for them to respond that I end up force-quitting Fusion. When I open it back up, the VMs are still running and are responsive again (which I find odd because they aren't resuming; they are just still there running)... until a I let them sit idle again and then it's back to beach ball time.
I have tinkered with the guest RAM and processor settings on several different VMs. I have also tinkered with the sleep and automatic suspend settings on the guests. All to no avail. I have been running VMs like this for years with few to no problems and certainly nothing like this.
I have tried open-vm-tools and the VMWare Tools on different VMs to see if they offered any differences (uninstalling the other each time before switching). They don't help. In previous versions of Fusion I have been using open-vm-tools with great success but now it's buggy (I had to write a script to restart open-vm-tools at login in order to get the screen to resize when dragging by the corners). VMWare Tools hasn't worked for me in a long time and when I tried it again with Fusion Pro 11 I met the same lack of success. It installs fine but my screen won't resize and I can't get an actual full-screen mode to work (with VMWare Tools).
Is anyone else experiencing this slow performance with Fusion Pro 11 and MacOS Mojave combined?
If anyone has any suggestions on how I might fix the problem I'll be incredibly grateful. The situation I've got now has me wondering if I need to try falling back to Fusion Pro 10 or High Sierra. I really don't want to do that.
Thanks, in advance, for any help you can offer.
CW.
Message was edited by: ITdojo - corrected a typo.
Hello. I have an Alienware 17 R5 laptop with Windows 10 Pro x64 installed. I recently installed VMware Workstation 15 Pro and then I installed Linux Mint 19 Cinnamon x64 as a new VM. Everything is fine and shared folders work, but, both copy and paste and drag and drop do not work, no matter the direction ( ie. to/from guest/host ).
I'm using VMware Workstation 15 Pro version 15.0.2 build 10952284 and I have the latest, I believe, VMware Tools installed with a version of 10.3.2-9925305.
In the VM's setting under "Guest isolation" I have both "drag and drop" and "copy and paste" checked.
Any help would be appreciated.
Thanks,
jdb2
Hello,
I have NSX-T 2.3 env managing a vSphere env of ESXi 6.5. All hosts in the cluster are prepared as transport nodes and all are in Overlay TZ. I have created a logical switch on NNSX manager which i can see conveyed to NSX controllers(if i check on controllers via cli) however i don't see those logical switches on ESXi hosts when i run "get logical-switches" command on nsxcli shell of ESXi host.
Output from controller:
----------------------------
nsxt-ctlr1> get logical-switch
VNI UUID Name
67584 xxxxxxx-xxxxx-x-xx-xxx switch1
67586 xxxxx-xxxxx-xxxx-xxxxx test1
nsxt-ctlr1> get logical-switch 67586 transport-node-table
nsxt-ctlr1>
I am following the NSX-T2.3 troubleshooting guide and i have confirmed on host that the following services are running:
1- nsx-mpa
2- nsx-opsagent
3- netcpad
I also checked the controllers and manager output from host:
host> get managers
- 192.168.0.11 Connected
host> get controllers
Controller IP Port SSL Status Is Physical Master Session State Controller FQDN
192.168.0.250 1235 enabled not used false null NA
192.168.0.252 1235 enabled connected true up NA
192.168.0.251 1235 enabled not used false null NA
host# esxcli network ip connection list | grep 1235
tcp 0 0 192.168.0.16:20410 192.168.0.252:1235 ESTABLISHED 89665 newreno nsx-proxy . <--- As per troubleshooting guide this should be netcpa but in my output it is nsx-proxy??
host# esxcli network ip connection list | grep 5671
tcp 0 0 192.168.0.16:61104 192.168.0.11:5671 ESTABLISHED 91052 newreno mpa
tcp 0 0 192.168.0.16:22875 192.168.0.11:5671 ESTABLISHED 91052 newreno mpa
Not sure why logical switches are not seen on hosts:
Output from host:
--------------------
Host> get logical-switch
Logical Switches Summary
------------------------------------------------------------
Overlay Kernel Entry
============================================================
VNI DVS name VIF num
Overlay LCP Entry
============================================================
VNI Logical Switch UUID
VLAN Backed Entry
============================================================
Logical Switch UUID VLAN ID
Any help would be highly appreciated.
Thanks,
Amit
I'm trying to use Windows file sharing (SMB) on Windows 10 (v1809) host / Linux guest running in VMware Workstation Player 15.0.2.
However, I'm not able connect to 192.168.121.1:445 (connection refused) neither from the host, nor from the guest.
192.168.121.1 is the IP address of VMware Virtual Ethernet Adapter for VMnet8 (NAT).
The adapter is up, and ping 192.168.121.1 works fine.
The host is listening on TCP 0.0.0.0:445.
Windows firewall is off, antivirus software is disabled.
Both "Client for Microsoft Networks" and "File and Printer Sharing for Microsoft Networks" are checked in the adapter properties.
If I disable "File and Printer Sharing for Microsoft Networks" in the properties of "VMware Virtual Ethernet Adapter for VMnet8" and then enable it again, everything gets right, and I can connect to 192.168.121.1:445. However, after reboot it does not work again.
This problem appeared after upgrade from Workstation Player 14 to Workstation Player 15.0.2.
I have vCenter 6.5 u2 and vplex metro cluster with 2 vnx 5400 . now I want to install Microsoft 2016 server with Microsoft 2017 SQL Server Always On. I have read some articles but I would like to ask experts here again. I need the share disk for MS SQL Server Always On. the sharing disk must be the physical mode or virtual rdm mode. each of the virtual machines will run on 6.5 u2 with different ESXi .
it also supports vmotion virtual machines not storage vmotion ?
is not validating the license.
what could be happening?
your help, please
I have been using VMware Fusion for a number of years to access hospital websites through Windows via Citrix Receiver and now Workspace. I keep Fusion up to date, as I do Windows (now Windows 10), and my Macs. Using Citrix on my Mac (without Fusion and Windows) never worked very well, and I was never able to print from a Citrix connection using a Mac.
For a long time Fusion/Windows worked well in every respect. But then I began having trouble with one of the hospital sites, trouble which progressively worsened, and then with the others. Now I can't access any of the 3 hospitals usefully through Citrix. Either I can't connect, the connection drops soon after access, or the connection is way too slow to work. The Citrix access works fine for all three hospitals on Windows machines. Also, Fusion on my Mac works well for everything else including a clinic that I access through FortiClient.
Interestingly, Citrix seems to often work pretty well on iOS devices (I haven’t tried printing.), but the screens are too small for the kind of work I do, so I haven't used Citrix on iOS much.
The hospitals all use different versions of Receiver/Workspace, some more up to date than others, but if I have a recent Workspace client installed on my Windows computer, it works well with all of the hospitals. The attitudes of the hospital IT departments vary, but the most important hospital won't support Macs at all, VM or directly.
I'm on the road a lot and much prefer my Mac over a Windows computer. I've developed a workaround, accessing my Windows computer through a remote desktop, but that is clunky.
I doubt that I'm the only one having this problem, but I can't find it mentioned in Google searches or in searches on the WMware support site. I know that Citrix and WMware are competitors, but it is difficult to believe that the products would be made incompatible intentionally. Does anyone have any insight in to what the problem may be?
We have 3 VMWare hosts, with shared and direct attached storage. We have been moving things around, and temporarily moved some VM's to a Windows 2012r2 Storage server. We setup the storage as NFS 4.1 in VMWare, and setup following the many guides on the internet on the 2012r2 server.
I'm not sure what happened, but we can no longer extend or create storage. I have tried many many things on both the VMware side and the server 2012r2 server, but am at a loss. None of the 3 hosts can create disks on the 2012 datastore. I can create disks on my OpenSuse NFS storage, as well as the local direct attached storage. All 3 vmware hosts are acting the same.
The error message I get when trying to create a disk:
A general system error occurred: Error creating disk Device or resource busy
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of Unlink[file] failed
File system specific implementation of Lookup[file] failed
File system specific implementation of LookupAndOpen[file] failed
File system specific implementation of Ioctl[file] failed
File system specific implementation of RenameFile[file] failed
I can browse the data store, and I can create folders, edit files, etc.. I can mount existing disks and the vm works. I just can't create new, or extend the size of existing.
Any ideas?
Thanks!
