我很確定我們不是唯一使用巨型幀 (~9k) 的網站，對嗎？那麼，對於那些也在做這件事的人來說，你們在虛擬化方面做了什麼？即：
- Xen 不支援橋接介面上超過 1500 位元組的封包。為每個虛擬機器分配一個真實的介面可能可行，但對我來說是不可能的。
- 如果我仔細研究一下原始程式碼，KVM 就會做到這一點。否則我最多可以獲得 4k 資料包。搞亂原始碼並不是我真正想做的事情（再見上游補丁而不重建！）
- VMWare 沒有提它。他們的 VSphere 定價讓我望而卻步，但也許我可以只使用 ESX(,i)？
我沒有將巨型資料包用於 iSCSI 或 NFS。我確實在節點之間移動了大量數據，提高 MTU 有助於提高速度。我的平台是 CentOS 5.x，我更願意保留該平台，但我想還有其他選擇嗎？你告訴我！
有人做了沒想到的聰明事嗎？
[編輯]
我為什麼要這個？嗯，我現有的機器都使用 9000 的 MTU，發生這種情況的地方是在我們的集群層。如果我添加一台不支援巨型資料包的新機器，它就無法加入集群，並且無法工作。因此，雖然我很想重新審視「我們真的需要巨型資料包嗎？」的問題，但這是一個比僅僅讓一台新機器上線更大的專案。新機器有能夠與集群對話。現在這意味著在裸硬體上部署，這很糟糕。
答案1
對於 ESXi 4 標準虛擬交換機，您必須從 CLI 執行此操作。如果您使用（不支援的）偽控制台模式或（支援的）VMA，相關指令為：
esxcfg-vswitch -m 9000 vSwitch0
將 vSwitch0 替換為相關的虛擬交換器 ID，並根據需要對需要啟用 9K 巨型訊框的所有 vSwitch 重複此操作。
在使用分散式虛擬交換器的較大（較大）環境中，您可以從 vSphere Client GUI 變更 MTU。
答案2
根據我的經驗，巨型幀實際上離可用還很遠。卸載技術很亂，尤其是b-com提供的東西，交換器支援得不夠好。
特別是對於 VM，我會堅持使用正常的 MTU 大小，並透過使用模式 4 綁定或切換到 10G 甚至 infiniband 來提高速度。
話雖如此，afaik kvm 的 virtio_net 驅動程式的速度並沒有真正受到限制，因此儘管是 1G，但考慮到頻寬，它們可以輕鬆超越。
答案3
這不是一個直接的答案，但如果您在多個節點之間移動大量數據，您是否考慮過 Infiniband？這對於這類事情來說非常棒。