Wireless bridged networking di KVM. Mengapa begitu rumit?


8

Saya telah menggunakan VirtualBox (dan kadang-kadang VMWare) selama bertahun-tahun dan saya tidak pernah punya masalah dengan adapter jaringan virtual, tidak peduli apakah yang fisik kabel atau tidak.

Saya juga bermain beberapa waktu lalu dengan KVM dalam pengaturan kabel dan, meskipun saya harus mengedit beberapa file konfigurasi untuk membuatnya bekerja, saya juga bisa membuat adaptor yang dijalin tanpa masalah besar.

Hari ini saya memutuskan (keliru, tampaknya) untuk mencoba menggunakan KVM di laptop yang menjalankan Ubuntu 13.10 dan mencoba membuat mesin virtual dengan jaringan yang dijembatani melalui antarmuka nirkabel. Sangat menyakitkan untuk mengatur ini.

Setelah mengikuti semua tutorial yang saya temukan ( misalnya ) dan harus me-reboot laptop saya beberapa kali untuk mendapatkan koneksi kembali, saya menyerah dan kembali ke VirtualBox lama saya yang terkenal.

Dan, sebenarnya, hal pertama yang saya perhatikan ketika saya melihat ke dokumentasi KVM resmi adalah bahwa mereka mencegah mencoba menjembatani adaptor nirkabel karena, menurut mereka :

Metode yang ditampilkan di sini, tidak akan berfungsi dengan sebagian besar (semua?) Driver nirkabel, karena ini tidak mendukung bridging.

Jadi, pertanyaan saya adalah:

  • Kenapa mereka mengatakan bahwa sebagian besar adapter nirkabel tidak mendukung bridging jika bekerja di VirtualBox dan VMWare hanya "out-of-the-box"?
  • Dan apa perbedaan antara hypervisor ini yang membuatnya sangat rumit di KVM, jika berhasil?

Jawaban:


10

Latar belakang KVM

Saya pikir ini sebagian karena harapan dengan KVM. KVM adalah yang pertama dan terutama produk server dan bukan produk desktop untuk virtualisasi. Itu dapat digunakan di salah satu aplikasi tetapi pasti lebih cocok untuk digunakan di server.

Saya menggunakannya pada 3+ host di tempat kerja masing-masing hosting 5-10 VMs masing-masing dan telah berjalan dengan sempurna dan mudah dikelola, dan pada dasarnya hanya berfungsi.

Pertanyaan 1

Kenapa mereka mengatakan bahwa sebagian besar adapter nirkabel tidak mendukung bridging jika bekerja di VirtualBox dan VMWare hanya "out-of-the-box"?

Saya yakin Anda menarik kesimpulan ini dari uraian ini di situs web KVM .

PERINGATAN: Metode yang ditampilkan di sini, tidak akan bekerja dengan sebagian besar (semua?) Driver nirkabel, karena ini tidak mendukung bridging.

Pernyataan ini ada di sini karena biasanya demikian. Saya percaya inilah sebabnya mengapa ketika Anda menginstal VirtualBox atau VMWare biasanya ada modul kernel yang diinstal dan produk-produk ini menyediakan pembungkus mereka sendiri untuk melakukan hal ini untuk memudahkan membuatnya lebih mudah. Produk-produk ini pada dasarnya mengatasi masalah ini.

Saya percaya masalah ini juga masalah pengemudi. Driver untuk WiFi di Linux masih tidak berarti dibandingkan dengan dukungan yang disediakan oleh driver Windows untuk perangkat keras yang sama. Itu hanya fakta kehidupan.

CATATAN: Saya pernah menggunakan NIC nirkabel di masa lalu sehingga saya tidak dapat menggunakan mode bridge sebelumnya. Saya biasanya mengatasi masalah dengan menggunakan VirtualBox atau mendapatkan NIC yang berbeda untuk laptop saya.

Saya juga akan menyoroti bahwa VirtualBox atau VMware tidak dapat melakukan ini, setidaknya tidak sampai versi yang lebih baru. Lihat ini sebagai bukti dari VMware KB:

Jika host Anda memiliki adaptor jaringan nirkabel, Anda tidak dapat menggunakan jaringan bridged pada host Linux di VMware Workstation 5 atau lebih rendah, VMware Server 1.x, versi GSX Server, semua host di VMware Workstation 3 atau lebih rendah, atau di VMware GSX Server 2 atau lebih rendah. Di bawah produk ini, jika Anda ingin menjalankan mesin virtual pada host yang menggunakan adapter Ethernet nirkabel, Anda harus mengkonfigurasi mesin virtual Anda untuk menggunakan NAT atau jaringan host-only.

Sumber: Menggunakan jaringan yang dijembatani dengan NIC nirkabel (760)

Pertanyaan # 2

Dan apa perbedaan antara hypervisor ini yang membuatnya sangat rumit di KVM, jika berhasil?

Saya benar-benar tidak dapat menjelaskan pertanyaan khusus ini, selain untuk mengatakan bahwa jika mudah saya bayangkan fitur ini akan diaktifkan. Saya pikir inti masalahnya berkaitan dengan fitur ini yang membutuhkan 3 atau lebih kelompok untuk mengoordinasikan upaya mereka (pembuat perangkat keras, driver devs., Kernel Linux, & KVM).

Situasi ini sering kali merupakan hasil ketika Anda memerlukan beberapa grup untuk bekerja bersama di dunia open source (IMO)!

Jadi bisakah saya mengaturnya atau apa?

Anda dapat mengatur ini dengan mengikuti petunjuk dari 2 artikel ini. Pengaturan membutuhkan menggunakan perangkat TUN / TAP yang dapat dimasukkan ke mode jembatan.


Baik. VirtualBox memalsukan "jembatan" ke jaringan nirkabel. Tidak akan pernah berhasil menjembatani ke klien nirkabel, karena AP akan menolak bingkai dengan alamat MAC yang belum dikaitkan dengannya.
Michael Hampton

5

KVM, seperti perangkat lunak Linux asli lainnya, mencoba menggunakan kode yang sudah ada alih-alih menciptakan kembali roda. Inilah yang membuatnya jauh lebih baik daripada semua solusi lain, karena ketersediaan perangkat lunak untuk Linux dan kecepatannya diperbarui dan ditingkatkan, tetapi ini juga memberinya keterbatasan dari solusi lain.

Dalam hal ini, pelakunya adalah bridge-utils, yang bekerja dengan mengatur NIC yang sedang dijembatani dalam mode promiscous. Banyak driver NIC nirkabel di linux tidak mendukung mode itu, tetapi itu bukan kesalahan KVM.

Anda masih memiliki opsi untuk menggunakan NAT atau OVS atau apa pun yang didukung KVM (dan ada banyak teknologi yang tersedia)


"pelakunya adalah jembatan-utils, yang bekerja dengan menetapkan NIC yang sedang dijembatani dalam mode promiscous." Adakah peluang Anda dapat menautkan ke satu atau lebih sumber terpercaya tentang ini, menambah bobot klaim ini dan / atau memberikan bacaan lebih lanjut bagi siapa saja yang ingin tahu lebih banyak? Terima kasih :)
sampablokuper

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.