てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible] 「つまずき Ansible 【Part13】ansible-base 2.10.0 の changelog を眺める」ふりかえり

ansible つまずきAnsible ansible2.10

はじめに

2020/08/15 に、YouTube Live で「つまずき Ansible 【Part13】ansible-base 2.10.0 の changelog を眺める」という配信をしました。

実際に作業しながらエラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、デモではなく、ansible-base 2.10.0 の changelog を眺めて、どんな変更だろうなぁというのをコメントする回です。

ansible/CHANGELOG-v2.10.rst at stable-2.10 · ansible/ansible · GitHub

やったことや、わかったことをふりかえります。

動画

www.youtube.com


■ やったこと（見た changelog）


Part14 にむけて

以下のネタを検討中です。気が向いたものをやります。

  • connection: local ななにか
  • Ansible Toewr / AWX をコマンドがら操作する
  • ansible.cfg
  • Jinja2、フィルター
  • Windows
  • when、assert など

[Ansible] 「つまずき Ansible 【Part12】実行順序などの制御」ふりかえり

ansible つまずきAnsible

はじめに

2020/08/08 に、YouTube Live で「つまずき Ansible 【Part12】実行順序などの制御」という配信をしました。 実際に作業しながらエラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、forksや、order など、実行の方式や順序などに関わる機能を試しました。

やったことや、わかったことをふりかえります。

動画

www.youtube.com

今回のテーマの特性上、このブログの文章をより動画を見ていただいたほうが分かりやすいと思います・・。


■ やったこと

forks による同時実行数の制御

設定名は DEFAULT_FORKS。

デフォルトは 5。

ansible-playook コマンドでは -f または --fork オプションで指定可能。

配信時は試してませんが、ansible.cfg の場合は以下の設定。

[defaults]
forks=5

throttle による同時実行数の制限

Play や Task 単位で指定できる。たとえば、Play 全体では forks は 5 だが、特定のタスクだけ throttle: 1 を指定すると、そのタスクだけ 1ホストずつ実行できる。

    - name: 2. sleep
      command: "sleep {{ wait }}"
      throttle: 1

order による実行ホスト順序の制御

各ホストの実行順序を制御できる。完了順（ログ表示順）ではないので注意。（fork 数を 1にすると、1ホストずつ実行するので、開始順=完了順になる）

デフォルトは inventory で、インベントリの定義順。

stragety による実行戦略の制御

デフォルトは linearで、1タスクごとに各ホストの完了を待って次のタスクに進む。

他には、free がある。

serial による Play あたりの実行ホスト数の制御

1つの Play を何ホストずつ実行するかの指定。

---
- hosts: sv
  gather_facts: false
  serial: 1

  tasks:
    - name: 1. sleep
      command: "sleep {{ wait }}"
      
    - name: 2. sleep
      command: "sleep {{ wait }}"

    - name: 3. sleep
      command: "sleep {{ wait }}"
  • 実行ログ
(a29) [root@2a5505f15a98 stumble]# ansible-playbook -i sv.ini server.yml 

PLAY [sv] *********************************************************************************************************

TASK [1. sleep] ***************************************************************************************************
changed: [sv1]

TASK [2. sleep] ***************************************************************************************************
changed: [sv1]

TASK [3. sleep] ***************************************************************************************************
changed: [sv1]

PLAY [sv] *********************************************************************************************************

TASK [1. sleep] ***************************************************************************************************
changed: [sv2]

TASK [2. sleep] ***************************************************************************************************
changed: [sv2]

TASK [3. sleep] ***************************************************************************************************
changed: [sv2]

PLAY [sv] *********************************************************************************************************

TASK [1. sleep] ***************************************************************************************************
changed: [sv3]

TASK [2. sleep] ***************************************************************************************************
changed: [sv3]

TASK [3. sleep] ***************************************************************************************************
changed: [sv3]

PLAY [sv] *********************************************************************************************************

TASK [1. sleep] ***************************************************************************************************
changed: [sv4]

TASK [2. sleep] ***************************************************************************************************
changed: [sv4]

TASK [3. sleep] ***************************************************************************************************
changed: [sv4]

PLAY RECAP ********************************************************************************************************
sv1                        : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 
sv2                        : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 
sv3                        : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 
sv4                        : ok=3    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

strategy: linear、strategy: free、serial: 1 の動きまとめ

まとめてくださいました。


Part13 にむけて

以下のネタを検討中です。気が向いたものをやります。

  • connection: local ななにか
  • Ansible Toewr / AWX をコマンドがら操作する
  • ansible.cfg
  • Jinja2、フィルター
  • Windows

[Ansible] IPv4/v6アドレスをホストとして利用可能かどうか assert でチェックする

ansible

はじめに

Ansible には、ipaddr という、IPv4/v6アドレスを扱う便利なフィルターがあります。

この記事では、与えられたIPv4/v6アドレス（プレフィックス数付き）が、ホストとして利用可能なアドレス かどうかassert するサンプルをご紹介します。

  • 動作確認環境
    • Ansible 2.9.11
    • netaddr 0.8.0
      • Ansible 標準では含まれないので必要に応じて pip install netaddr でインストール

Playbook

以下の Playbook を利用します。変数 addresses にチェック対象の IPv4/v6 アドレスをプレフィックス数付きで定義します。 利用可能アドレス とコメントしたアドレスが assert 成功して、それ意外は失敗する想定です。

---
- hosts: localhost
  gather_facts: false

  vars:
    addresses:
      - 10.0.0.0/24
      - 10.0.0.1/24     # 利用可能アドレス
      - 10.0.0.254/24   # 利用可能アドレス
      - 10.0.0.255/24
      - fe80::/64
      - fe80::1/64    # 利用可能アドレス
      - fe80::ffff:ffff:ffff:fffe/64  # 利用可能アドレス
      - fe80::ffff:ffff:ffff:ffff/64

  tasks:
    - name: asset usable address
      assert:
        that:
          - item | ipaddr('host')    # ホストアドレスであること
          - item != (item | ipaddr(-1))   # ブロードキャストアドレスでないこと
      loop: "{{ addresses }}"

ipaddr('host') でホストアドレスかどうかをチェックします。 10.0.0.0/24 はネットワークアドレスなので失敗します。個人的な直感とは違い、10.0.0.255/24 のようなブロードキャストアドレスは成功します。

そのため、もう一つの 条件で item != (item | ipaddr(-1)) も併せてチェックします。 たとえば、10.0.0.1/24 | ipaddr(-1) は 10.0.0.255/24 になります。

実行結果

Playbook を実行します。

$ ansible-playbook -i localhost, net.yml 

PLAY [localhost] ***************************************************************************************************

TASK [asset usable address] ****************************************************************************************
failed: [localhost] (item=10.0.0.0/24) => {
    "ansible_loop_var": "item",
    "assertion": "item | ipaddr('host')",
    "changed": false,
    "evaluated_to": false,
    "item": "10.0.0.0/24",
    "msg": "Assertion failed"
}
ok: [localhost] => (item=10.0.0.1/24) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": "10.0.0.1/24",
    "msg": "All assertions passed"
}
ok: [localhost] => (item=10.0.0.254/24) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": "10.0.0.254/24",
    "msg": "All assertions passed"
}
failed: [localhost] (item=10.0.0.255/24å) => {
    "ansible_loop_var": "item",
    "assertion": "item | ipaddr('host')",
    "changed": false,
    "evaluated_to": false,
    "item": "10.0.0.255/24å",
    "msg": "Assertion failed"
}
failed: [localhost] (item=fe80::/64) => {
    "ansible_loop_var": "item",
    "assertion": "item | ipaddr('host')",
    "changed": false,
    "evaluated_to": false,
    "item": "fe80::/64",
    "msg": "Assertion failed"
}
ok: [localhost] => (item=fe80::1/64) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": "fe80::1/64",
    "msg": "All assertions passed"
}
ok: [localhost] => (item=fe80::ffff:ffff:ffff:fffe/64) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": "fe80::ffff:ffff:ffff:fffe/64",
    "msg": "All assertions passed"
}
failed: [localhost] (item=fe80::ffff:ffff:ffff:ffff/64) => {
    "ansible_loop_var": "item",
    "assertion": "item != (item | ipaddr(-1))",
    "changed": false,
    "evaluated_to": false,
    "item": "fe80::ffff:ffff:ffff:ffff/64",
    "msg": "Assertion failed"
}

PLAY RECAP *********************************************************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

無事に、利用可能アドレス としていたアドレスのみが All assertions passed となりました。

おわりに

ipaddr フィルターには他にもたくさんの機能がありますので、IPアドレスに関する操作をしたい場合は、リファレンスを参照することをおすすめします。

docs.ansible.com

[Ansible] 「つまずき Ansible 【Part11】トラブルシューティング手法を試す」ふりかえり

ansible つまずきAnsible

はじめに

2020/08/01 に、YouTube Live で「つまずき Ansible 【Part11】トラブルシューティング手法を試す」という配信をしました。 実際に作業しながらエラーと戦って進めるシリーズです。

tekunabe.connpass.com

今回は、July Tech Festa 2020 や Cloud Operator Days Tokyo 2020 で@saito_hidekiさんから発表があった、以下の資料を参考にながら、トラブルシューティングの手法をいつくつか試しました。

www.slideshare.net

やったことや、わかったことをふりかえります。

動画

www.youtube.com


■ やったこと

log_path によるログ保存

設定名は DEFAULT_LOG_PATH。

ansible.cfg の場合は以下の設定。相対パスでもOKの模様。

[defaults]
log_path=ansible.log

環境変数での設定の場合は ANSIBLE_LOG_PATH。

コマンド実行時の一時的に有効にする場合は、以下のよいうに指定する。

$ ANSIBLE_LOG_PATH=ansible1.log ansible-playbook -i inventory.ini ios_show.yml

ANSIBLE_DEBUG によるデバッグ

設定名は DEFAULT_DEBUG、

環境変数での設定の場合は、ANSIBLE_DEBUG。大量のログが表紙されるので、一時的な設定にするのが吉。

$ ANSIBLE_DEBUG=True ansible-playbook -i inventory.ini ios_show.yml

前述の log_path 指定したファイルにも出力される。

--step によるステップ実行

ansible-playbook コマンドの --step オプションで、各タスクの実行前に一時停止できる。

n でスキップ、y で実行（次のタスクでまた止まる）、c で継続（この後は止まらない）

# ansible-playbook -i inventory.ini ios_show.yml --step

PLAY [ios] ***************************************************************************************************************************
Perform task: TASK: 1. show version (N)o/(y)es/(c)ontinue: y

Perform task: TASK: 1. show version (N)o/(y)es/(c)ontinue: ***************************************************************************

TASK [1. show version] ***************************************************************************************************************
ok: [rt01]
ok: [rt02]
Perform task: TASK: 2. show ip route (N)o/(y)es/(c)ontinue: c

Perform task: TASK: 2. show ip route (N)o/(y)es/(c)ontinue: **************************************************************************

TASK [2. show ip route] **************************************************************************************************************
ok: [rt02]
ok: [rt01]

TASK [3. show ip route] **************************************************************************************************************
ok: [rt01]
ok: [rt02]

PLAY RECAP ***************************************************************************************************************************
rt01                       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
rt02                       : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

--start-at-task による、開始タスクの指定

ansible-playbook コマンドの --start-at-task オプションで、どのタスクから始めるかを指定できる。

ansible-playbook -i inventory.ini ios_show.yml --start-at-task "2. show ip route"

としたときに、以下のように 2. show ip route という名前のタスク移行が実行される。

    - name: 2. show ip route
      ios_command:
        commands:
          - show ip route

新たにわかったこと

試した限り、同じ名前のタスクが合った場合は、上にあるタスクから実行される模様。

また、--start-at-task "2. show ip*" のようなワイルドカード指定もできた。 "2. show ip" ではマッチしない。

Playbook Debugger によるデバッグ

以前の配信でも利用した便利な Playbook Debugger。

たとえば、以下のように Play レベルで debugger: always を指定すると、各タスクの各ホスト実行後にデバッガーが起動する。

---
- hosts: ios
  gather_facts: false
  debugger: always
  
  tasks:
    - name: 1. show version
      ios_command:
        commands:
          - show version

    - name: 2. show ip route
      ios_command:
        commands:
          - show ip route

    - name: 3. show ip route
      ios_command:
        commands:
          - show ip route

変数の値を途中で確認したり

[rt02] TASK: 1. show version (debug)> p task_vars["ansible_user"]
'admin'

書き換えたりもできる。

[rt02] TASK: 1. show version (debug)> task_vars["ansible_user"]="hogehoge"
[rt02] TASK: 1. show version (debug)> u

再実行は r。

[rt02] TASK: 1. show version (debug)> r

新たにわかったこと

前述の --step の機能を包含していると思っていがそうではなかった。

  • --step
    • タスクの実行前に止まる
    • タスク単位（ホスト単位ではなく）で止まる
  • Playbook Debugger
    • タスクの実行後に止まる
    • ホスト単位で止まる

ANSIBLE_KEEP_REMOTE_FILES による、Pythonファイルの保存

Ansible がマネージドノードに送って実行する Python ファイルは、通常は実行後に削除されるが、それを残すことに酔ってデバッグの材料になる。

設定名は DEFAULT_KEEP_REMOTE_FILES。

環境変数での設定の場合は ANSIBLE_KEEP_REMOTE_FILES。

# ANSIBLE_KEEP_REMOTE_FILES=True ansible -i inventory.ini sv -m shell -a "hostname"
awx | CHANGED | rc=0 >>
centos7

ターゲットノードでファイルが残る。

[root@centos7 ~]# cd .ansible/tmp/ansible-tmp-1596282623.326226-90936-50539150331503/
[root@centos7 ansible-tmp-1596282623.326226-90936-50539150331503]# ll
合計 124
-rwx------. 1 root root 124866  8月  1 20:50 AnsiballZ_command.py

実行もできる。

[root@centos7 ansible-tmp-1596282623.326226-90936-50539150331503]#./AnsiballZ_command.py 

{"changed": true, "end": "2020-08-01 20:52:07.803865", "stdout": "centos7", "cmd": ["hostname"], "rc": 0, "start": "2020-08-01 20:52:07.801926", "stderr": "", "delta": "0:00:00.001939", "invocation": {"module_args": {"creates": null, "executable": null, "_uses_shell": false, "strip_empty_ends": true, "_raw_params": "hostname", "removes": null, "argv": null, "warn": true, "chdir": null, "stdin_add_newline": true, "stdin": null}}}


Part3 にむけて

以下のネタを検討中です。気が向いたものをやります。

  • connection: local ななにか
  • Ansible Toewr / AWX をコマンドがら操作する
  • ansible.cfg
  • Jinja2、フィルター
  • Windows

無償版 ESXi への vCenter(VCSA 7.0)の デプロイが Stage1 の 80% から進まない

vmware esxi vcsa

はじめに

タイトルオチですがまとめておきます。 この手の作業は初めてだったのですが、多くの人が通り道のようですね・・。

環境

  • ESXi 7.0.0b
  • VMware vCenter Server Appliance 7.0

現象

vCenter Server Appliance 7.0 を GUI でデプロイしおうとしたところ、 Stage 1 の 80% から進まず止まってしまいました。

f:id:akira6592:20200731205250p:plain
進まない

調べて出会ったのがこちらの記事です。（助かりました）

技術メモメモ: vCSA (vCenter Server Appliance) 6.7のインストールが80%で止まる件

インストール先のESXiは無償ライセンスで運用しており、それが原因のようだ。試しに60日間の機能無制限の評価ライセンスでESXiを構築して同様にvCSAをインストールしてみたところ、問題なくインストールすることができた。

対策

ちょうど VMUG Advantage に入ったばかりで、各種ライセンスを1年間利用できる状態だったので「VMware vSphere 7 (ESXi)」のライセンスキーを取得して、ESXiに投入しました。

f:id:akira6592:20200731210601p:plain
投入前（無償版ライセンス）

f:id:akira6592:20200731210013p:plain
投入後

投入後、勝手にデプロイが進んでいきました。

f:id:akira6592:20200731210105p:plain
この後も順調でした

f:id:akira6592:20200731210742p:plain
デプロイと基本設定後

[Ansible] 「AnsibleでA10 Thunder のADC機能を設定しよう！（基礎編）」に参加させていただきました

ansible a10

はじめに

2020/07/28 に A10ネットワークス株式会社さん主催の「【リモート勉強会】第２回：AnsibleでA10 Thunder のADC機能を設定しよう！（基礎編）」に参加させていただきました。

www.a10networks.co.jp

第1回が好評だっため、同じ内容で再度開催されたとのことです。実際私も第1回に参加した人からのススメもあって今回参加しました。

資料や、環境、Q&Aの体制が整っていて、実際にハンズオンができてとても有意義な勉強会でした。

この記事では、この勉強会通して学んだことのうち、特に知れてかったポイントなどをまとめます。


使用テキスト

使用されたテキストはこちらです。

github.com

LB としての基本的な設定を少しずつ Playbook を使って設定していく流れです。

Playbook のサンプルや解説はもちろん、実行ログや Thnder 側での確認手順なども詳細に書かれて、操作に迷うところはありませんでした。


基本は Collection モジュールを使用する

Ansible 本体にも、a10_*モジュールがありますが、これらは基本的に利用されないようです。

これまでもいくつかサンプルを見て察しがついていたのですが、代わりに以下の collection を利用するのが良いようです。


環境

README.mdにもあるように、各種 PATH が設定されていました。

[root@ansible playbook]# ansible-config dump --only-changed
DEFAULT_ACTION_PLUGIN_PATH(env: ANSIBLE_ACTION_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_axapi/plugins/action']
DEFAULT_CLICONF_PLUGIN_PATH(env: ANSIBLE_CLICONF_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/cliconf']
DEFAULT_TERMINAL_PLUGIN_PATH(env: ANSIBLE_TERMINAL_PLUGINS) = [u'/root/.ansible/collections/ansible_collections/a10/acos_cli/plugins/terminal']


a10.acos_axapi のモジュールの ansible_host オプションなどは省略可能

テキストでは、以下のように ansible_host や ansible_username といった接続に関わるオプションが各タスクごとに指定されていました、（引用元）

  - name: Configure virtual server
    a10_slb_virtual_server:
      ansible_host: "{{ ansible_host }}"
      ansible_port: "{{ ansible_port }}"
      ansible_username: "{{ ansible_username }}"
      ansible_password: "{{ ansible_password }}"
      name: "vip1"
      ip_address: "10.0.1.100"
      port_list:
        - port_number: "80"
          protocol: "http"
          service_group: "sg1"
          pool: "p1"
      state: present

タスクごとに指定するのは、冗長だと思って楽にできる方法ががあるか質問したところ、実はインベントリファイルの変数設定さえあれば、タスク側は指定不要とご回答いただきました。 テキストではわかりやすさのため指定しているとのこと。

つまり上記の例では、以下のように書けます。

  - name: Configure virtual server
    a10_slb_virtual_server:
      name: "vip1"
      ip_address: "10.0.1.100"
      port_list:
        - port_number: "80"
          protocol: "http"
          service_group: "sg1"
          pool: "p1"
      state: present

あとで、この README.md を確認したらちゃんと書いてありました。

If you want to use an Inventory file to perform respective configurations through a playbook, you don't need to specify ansible_host, ansible_username, ansible_password and ansible_port in the playbook.


a10_write_memory は毎回 changed になる

running-config を startup-config に保存する a10_write_memory というモジュールがあります。

このモジュールは実行のたびに毎回 changed になります。設定の「定義」ではなく、write memory という「操作」なので、そうなのだろうなと思います。

一方で、他の設定定義系のモジュールの多くは冪等性があるようです。そのため、もし、設定変更時のみ write memory したい場合は、handlers を組みわせることになると思います。


部分宣言的な定義

Virtual-Serverを構成するPlaybookの作成のところで、以下のような説明がありました。

既存のport_list設定（port 80 http）を残す場合は、必ずPlaybookに記述する必要があります。 記述がない場合は、既存のport設定が消えて新規の（Playbook内に記述された）port設定のみが設定される形になります。

つまりもともと port 80 http がある状態で、以下のように port 443 https のみの port_list にした場合、 port 80 http が消えて port 443 https のみになるということです。

      port_list:
        - port_number: "443"
          protocol: "https"
          service_group: "sg1"
          pool: "p1"
          template_client_ssl: "ssl1"

このような挙動を取るものを、私は勝手に部分宣言的な定義と呼んでいます。

Network Resource Module でいう state: overridden や state: replace のような動きですね。

注意が必要な一方で、あるべき姿を宣言する形（引き算を考えなくていい）便利だと思います。


構造化データの取得には state: noop

各モジュールの state オプションは present や absent の他にも noop という値も指定できます。 get_type オプションを併せて使うと、構造化データで結果を取得できるそう。

参考

tenko.hatenablog.jp


a10.acos_cli.acos_command モジュールは設定変更もできる

（これはテキストには出てこず、Q&Aのやりとりをきっかけに調べました）

私がこれまで見てきた *_command モジュールは、主に show コマンド用です。例えば、 ios_command モジュールで、configure terminal してなにか設定変更系コマンドを指定しても正常に実行できません。

一方で、a10.acos_cli.acos_command モジュールでは、設定変更もできるようです。

例えば、以下のような例がモジュール内のドキュメントに記載されています。

    - name: Run multiple sequential commands on ACOS device
      a10.acos_cli.acos_command:
        commands:
          - command: configure
          - command: slb template http test1
          - command: write memory
          - command: end

ただ、実際は、a10.acos_cli.acos_config モジュールのほうが、設定変更に特化した機能が多いため、a10.acos_cli.acos_config のほうが設定変更に適していると思います。


a10.acos_cli.acos_command モジュールは内部で show running-config を実行する

（こちらもテキストには出てこず、Q&Aのやりとりをきっかけに調べました）

前述のように、設定変更もできることに起因するようですが、a10.acos_cli.acos_command モジュールは内部で show running-config を実行するようです。

事前事後のコンフィグの差分を確認し、差分があれば chenged にする、という処理がありました、

これだけ聞くと、あぁそうなのか、という感じですが、気にしないといけないのは権限です。

show running-config を実行するには、enable する必要があります。ということは、相応の設定が必要になります。 enable パスワードが空なのであれば、空であるという指定 ansible_become_password="" が必要です。場合によっては。ansible_become_method=enable も併せて必要になるケースもあるようです。

試せていませんが、使用しているユーザーが特権ユーザーであれば become 系は不要なのかなと予想しています。


おわりに

親切なテキストと、十分な環境、的確な回答をいただける Q&A が揃っていて、とても安心して作業できました。 もしまた開催されたらおすすめできる内容でした。

ありがとうございました。

おまけ

おかげさまで時間内にすべて終わりました。最後は HTTPSのVirtual-Serverの構成 です。

記念の動作確認 GIF です。LB で SSL を終端しつつラウンドロビンしています。（Firefox の Ctrl+F5 (スーパーリロード) しています）

f:id:akira6592:20200728205155g:plain
ラウンドロビンしている様子

Intel NUC 上の ESXi 7.0 に BUFFALO の USB NIC を認識させる

nuc esxi vmware

はじめに

先日、第10世代 Intel NUC を購入して ESXi 7.0b をインストールしました。

f:id:akira6592:20200724140643p:plain:w400
ESXi 7.0b

物理 NIC を追加したくなったため調べたところ、以下の記事を見つけました。

tech-mmmm.blogspot.com

この記事で紹介されているチップセット「AX88179」と同じらしい「BUFFALO 有線LANアダプター LUA4-U3-AGTE-BK ブラック Giga USB3.0対応」がたまたま家に転がっていたため、試しました。

BUFFALO 有線LANアダプター LUA4-U3-AGTE-BK ブラック Giga USB3.0対応 【Nintendo Switch動作確認済み】

BUFFALO 有線LANアダプター LUA4-U3-AGTE-BK ブラック Giga USB3.0対応 【Nintendo Switch動作確認済み】

  • 発売日: 2018/11/23
  • メディア: Personal Computers

ほとんど前述の記事の手順と同じです。とても参考になりました。私の環境の場合は、ESXi 7.0 なので、ドライバのファイル名（後述）だけ違います。

接続

USB NIC を NUC の余っている USB 3.0 のポートに接続します。

接続直後の確認

ESXi に SSH でログインして、lsusb コマンドで、接続直後の状態を確認します。

[root@localhost:~] lsusb
Bus 001 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 002 Device 001: ID 0e0f:8003 VMware, Inc. Root Hub
Bus 001 Device 002: ID 8087:0026 Intel Corp.
Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
[root@localhost:~]

ASIX Electronics Corp. AX88179 Gigabit Ethernet が追加されました。 ただし、まだドライバをインストールしていないため、ESXi 上の 物理NIC としては認識されていない状態です。

ドライバのダウンロードとインストール

こちらのサイトからドライバをダウンロードします。

ESXi 7.0 を利用しているので、ドライバファイルは ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip を選択します。

f:id:akira6592:20200724140143p:plain
ESXi 7.0 向けのドライバを選択

ダウンロードしたドライバファイルを、データストアブラウザや SCP などで ESXi へコピーします。

その後、esxcli software vib install -d ドライバのzipファイル名 でドライバをインストールします。

[root@localhost:~] esxcli software vib install -d /vmfs/volumes/datastore1/ESXi700-VMKUSB-NIC-FLING-34491022-component-15873236.zip
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_vmkusb-nic-fling_0.1-4vmw.700.1.0.34491022
   VIBs Removed:
   VIBs Skipped:

ESXi の再起動を要求されているので、再起動します。

確認

正しく認識されたか ESXi の web にログインして確認します。

vusb0 という物理NIC が追加されました。

f:id:akira6592:20200724140420p:plain
vusb0 が追加された

f:id:akira6592:20200724140539p:plain
vusb0 の詳細

おわりに

たまたま家に転がっていた NIC でできてよかったです。

長期的に利用したわけではないので安定面はまだ不明ですが、とりあえずは認識しました。

f:id:akira6592:20200724141053p:plain
リンクアップもしてます


2021/01/06 追記: ホスト再起動後に通信不可に

仮想スイッチのアップリンクとしてしばらく特に問題なく使っていたのですが、ホストを再起動したときにちょっとしたトラブルに遭遇しました。

症状

割り当てていた仮想スイッチのアップリンクから外れていました。

f:id:akira6592:20210106203629p:plain
アップリンクから外れる

仮想スイッチのの設定で「アップリンクの追加」を押すと、もう空きがないと。あれ？

f:id:akira6592:20210106203849p:plain
あれ？

物理 NIC としては認識はしていました。

f:id:akira6592:20210106203534p:plain
NICは認識

どうも中途半端な状態になっていました。

対策（その場しのぎ）

いろいろ試したのですが、うまくいったのは以下の手順。

まず、仮想スイッチの設定画面を開きます。

f:id:akira6592:20210106204024p:plain
仮想スイッチの設定画面を開く

すると、この画面にはちゃんとお目当てのNICがアップリンクに設定されているので、特に何もせず「保存」を押す。

f:id:akira6592:20210106204136p:plain
ここには設定済み状態

何回か再現して試しましたが、私の場合はこれで治りました。

f:id:akira6592:20210106204455p:plain
アップリングが再度わりあたった

さらに追記

Twitter で教えていただきましたが、現状は制限があるようです。 以下ページの Persisting USB NIC Bindings にある方法を試してみましたが、私の環境では症状変わらずでした。ただ、試してみる価値はあると思います。

flings.vmware.com