<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:clearspace="http://www.jivesoftware.com/xmlns/clearspace/rss" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Unofficial Tech Memo - Koji Komatsu</title>
    <link>http://communities.vmware.com/blogs/kkomatsu</link>
    <description>このblogは小松康二の個人的なメモですのでサポート外の設定や勘違い等が含まれている可能性があります</description>
    <pubDate>Fri, 26 Dec 2008 01:07:38 GMT</pubDate>
    <generator>Clearspace 1.10.12 (http://jivesoftware.com/products/clearspace/)</generator>
    <dc:date>2008-12-26T01:07:38Z</dc:date>
    <item>
      <title>P2V後、古いネットワークアダプタとのIPアドレス重複エラーが発生する</title>
      <link>http://communities.vmware.com/blogs/kkomatsu/2008/12/27/p2v-ip-</link>
      <description>VMware ConverterでP2VしたWindows仮想マシンで、ネットワーク接続に物理環境と同じIPアドレスを割り当てようとすると、「このネットワークアダプタ用に入力されたIPアドレスは別のアダプタに既に割り当てられています。」というようなエラーメッセージが表示される場合がある。&lt;br /&gt;
ここで指摘されるネットワークアダプタは物理環境で認識していたもので、Windowsのプラグアンドプレイ機能によってP2V後の最初の起動の際にクリーンアップされるべきものだ。ところが、デバイスマネージャには表示されないものの、レジストリ上にゴミとして残ってしまいIPアドレスの競合を引き起こしてしまうことがある。&lt;br /&gt;
&lt;br /&gt;
MSの下記KBがこの事象の詳細と対処方法を解説している。&lt;br /&gt;
&lt;a class="jive-link-external" href="http://support.microsoft.com/kb/269155/ja"&gt;http://support.microsoft.com/kb/269155/ja&lt;/a&gt;</description>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">p2v</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">converter</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">network</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">nic</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">windows</category>
      <pubDate>Sat, 27 Dec 2008 17:32:58 GMT</pubDate>
      <author>kkomatsu</author>
      <guid>http://communities.vmware.com/blogs/kkomatsu/2008/12/27/p2v-ip-</guid>
      <dc:date>2008-12-27T17:32:58Z</dc:date>
      <clearspace:dateToText>11 months, 2 days ago</clearspace:dateToText>
      <wfw:comment>http://communities.vmware.com/blogs/kkomatsu/comment/p2v-ip-</wfw:comment>
      <wfw:commentRss>http://communities.vmware.com/blogs/kkomatsu/feeds/comments?blogPostID=2389</wfw:commentRss>
    </item>
    <item>
      <title>IPマルチキャストとESX</title>
      <link>http://communities.vmware.com/blogs/kkomatsu/2008/12/24/ip-esx</link>
      <description>IPマルチキャストについてはのTechnical Paperがリリースされた。&lt;br /&gt;
&lt;br /&gt;
Using IP Multicast with VMware ESX 3.5&lt;br /&gt;
&lt;a class="jive-link-external" href="http://www.vmware.com/resources/techresources/1082"&gt;http://www.vmware.com/resources/techresources/1082&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
骨子をまとめてしまうと以下の3つ。&lt;br /&gt;
&lt;ul&gt;
&lt;li&gt;ESX3.5 Update2以降では、VMotionやNICチーミングのフェールオーバが発生してもマルチキャストの受信がすぐに再開される (ユニキャストのSwitch Nortificationに相当する機能として、IGMP Membership Fake Queryが実装されている）&lt;/li&gt;
&lt;li&gt;デフォルトではIGMP v3のQueryを投げるが、IGMP v2で動作しているゲストOSはこれに対してIGMP Reportを応答しない。v3で動作しているゲストOSはv2のQueryにも応答するため、ゲストOSでv2を使っているものが存在している場合やバージョンが不明な場合は、ESXの詳細設定(Advanced Settings)で、Net.IGMPVersionを2とするのが安全。&lt;/li&gt;
&lt;li&gt;ESX3.5 Update1以前のリリースでは、マルチキャストルータのIGMP Queryの間隔（多くはデフォルト60秒）を小さく設定することで、VMotion時等のマルチキャスト受信の中断時間を小さくすることができる。&lt;/li&gt;
&lt;/ul&gt;
なお、NICチーミングの負荷分散アルゴリズムでIPハッシュを使用している場合には、バージョンや構成によらずNICフェールオーバ時のマルチキャスト受信の中断はおきない。</description>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">network</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">multicast</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">vmotion</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">teaming</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">igmp</category>
      <pubDate>Wed, 24 Dec 2008 10:24:06 GMT</pubDate>
      <author>kkomatsu</author>
      <guid>http://communities.vmware.com/blogs/kkomatsu/2008/12/24/ip-esx</guid>
      <dc:date>2008-12-24T10:24:06Z</dc:date>
      <clearspace:dateToText>11 months, 3 days ago</clearspace:dateToText>
      <wfw:comment>http://communities.vmware.com/blogs/kkomatsu/comment/ip-esx</wfw:comment>
      <wfw:commentRss>http://communities.vmware.com/blogs/kkomatsu/feeds/comments?blogPostID=2382</wfw:commentRss>
    </item>
    <item>
      <title>1つのNICチーミングで分散アルゴリズムを併用する方法</title>
      <link>http://communities.vmware.com/blogs/kkomatsu/2008/12/19/1-nic-</link>
      <description>VMware ESXの大きな特徴の１つに、標準機能で柔軟なNICチーミングが実現できることがあげられる。&lt;br /&gt;
&lt;br /&gt;
NICチーミングと言えば、冗長性の確保と負荷分散による帯域の有効活用の２つの目的があるが、自動での負荷分散については3つのアルゴリズムを選択できる。このアルゴリズムの選択と物理スイッチ側のLink Aggregationの設定には関連性がある。具体的には、IPハッシュベースの場合は物理スイッチ側でLink Aggregationが必須であり、MACハッシュベースおよびポートIDベースの場合にはLink Aggregation禁止となっている。特に後者は「禁止」という点が重要だ。（&lt;a class="jive-link-external" href="http://kb.vmware.com/kb/1001938%EF%BC%89"&gt;http://kb.vmware.com/kb/1001938）&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
禁止の理由は「リバースチーミング(Reverse Teaming)」と呼ばれる実装。これはポートIDベースやMACハッシュベースの場合にはLink Aggregationされていないことを前提に、マルチキャストとブロードキャストがチーミングされた複数のNICから重複して仮想マシンに到達することを防ぐために、仮想マシンが送信に使用している物理NIC以外からのパケットをドロップするという機能。これは物理ネットワークにおけるReverse Path Forwardingと呼ばれるマルチキャストの重複転送を防ぐ機能を参考にした機能で、万一Link Aggregationされていると、ドロップすべき物理NICからのみパケットが受信され、結局仮想マシンには届かないという事態が発生しうる。&lt;br /&gt;
&lt;br /&gt;
ここまでは物理スイッチでLink Aggregationを有効にするか無効にするかというだけの話だが、それでは、同じ仮想スイッチ（同じNICチーミング）を使用する複数のポートグループで負荷分散のアルゴリズムを分けて併用したい場合はどうすればよいだろうか。本来は、Link Aggregation必須と禁止のグループが共存することはできないはずだが、一つだけ抜け穴がある。それは、リバースチーミングを無効にしてしまうこと。リバースチーミングのオフは、ESXの詳細設定(Advanced Settings)のNet.ReversePathFwdCheckを0に設定することで実現できる。もちろん、この場合にはアルゴリズムに関わらず物理スイッチ側ではLink Aggregationが必須になる。さもなければ、ブロードキャストやマルチキャストは、チーミングを構成する物理NICの枚数だけ複製され、重複して仮想マシンに届くことになる。&lt;br /&gt;
&lt;br /&gt;
なお、この設定が正式サポートである可能性は低いと思われる。</description>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">network</category>
      <category domain="http://communities.vmware.com/blogs/kkomatsu/tags">teaming</category>
      <pubDate>Sat, 20 Dec 2008 07:03:19 GMT</pubDate>
      <author>kkomatsu</author>
      <guid>http://communities.vmware.com/blogs/kkomatsu/2008/12/19/1-nic-</guid>
      <dc:date>2008-12-20T07:03:19Z</dc:date>
      <clearspace:dateToText>11 months, 1 week ago</clearspace:dateToText>
      <clearspace:replyCount>3</clearspace:replyCount>
      <wfw:comment>http://communities.vmware.com/blogs/kkomatsu/comment/1-nic-</wfw:comment>
      <wfw:commentRss>http://communities.vmware.com/blogs/kkomatsu/feeds/comments?blogPostID=2373</wfw:commentRss>
    </item>
  </channel>
</rss>

