VirtualBox KVM の一般公開配布

 (cyberus-technology.de)
1 ポイント 投稿者 GN⁺ 2024-02-09 | 1件のコメント | WhatsAppで共有

VirtualBox KVM の一般公開リリース

  • Cyberus Technology は、VirtualBox の KVM バックエンドをオープンソースとして公開した。
  • VirtualBox は、さまざまなゲスト OS をサポートし、複数のホスト OS 上で一貫したユーザーインターフェースを提供するマルチプラットフォームの仮想マシンモニター（VMM）である。
  • KVM バックエンドを使用すると、VirtualBox は Linux KVM ハイパーバイザーを活用して仮想マシンを実行でき、これは標準の VirtualBox が使用するカスタムカーネルモジュールの代わりとなる。

オープンソース公開

  • Cyberus Technology は、オープンソースへのコミットメントを守るため、GitHub で KVM バックエンドをオープンソースライセンスのもとで公開した。
  • ユーザーは GitHub で VirtualBox と Cyberus Technology の KVM バックエンドをビルドし、改善された機能を直接活用できる。
  • 2024 年のロードマップには、さらに多くの興味深い機能が含まれており、アップデートがリリースされるたびに技術的内容を扱う追加の記事を公開する予定である。

サポートを受ける

  • VirtualBox と KVM を利用したい場合、またはカスタムの仮想化ソリューションが必要な場合、Cyberus Technology はガイダンスとエンジニアリングサービスを提供する用意がある。
  • サポートを希望するユーザーは、サポートフォームまたは service@cyberus-technology.de へのメールで連絡できる。

GN⁺ の意見:

  1. VirtualBox の KVM バックエンドのオープンソース公開は、仮想化技術の発展と、より広い互換性を求めるユーザーおよび開発者コミュニティにとって重要な前進である。
  2. 今回の発表は、仮想マシンの性能向上、セキュリティ強化、ハードウェアおよびゲストのユースケースに対するサポート拡大を可能にする技術的進歩を意味する。
  3. オープンソースコミュニティに貢献しようとする Cyberus Technology の取り組みは、オープンソースソフトウェアの発展と革新の促進に寄与するとみられる。

関連記事

1件のコメント

 
GN⁺ 2024-02-09
Hacker Newsのコメント

  • VirtualBoxを使う人は Extension Pack に注意すべき。Oracleは訴訟に非常に積極的だ
    https://www.reddit.com/r/sysadmin/comments/147k6az/oracle_is...
    https://www.reddit.com/r/sysadmin/comments/d1ttzp/oracle_is_...
    https://www.theregister.com/2019/10/04/oracle_virtualbox_mer...
    私たちの組織ではVirtualBoxを禁止した。Oracleを相手にするより、VMware Workstationやvirt-managerの方がはるかに安く済む

    • まさにそれを言おうとしていた。ここでも同じで、OracleはほとんどのVBoxユーザーが必要とする Extension Pack に執着しているように見えた
      だからできるだけ早く全員がそれを使えないようにしなければならなかった。もちろんVBoxだけの話ではなく、データベースも同様なので、単に避けるのが一番だ
    • Oracleをただ無視したらどうなるのか？ 実際に強制する力はあるのか？ ダウンロードを無料で公開しているなら無料であるべきだ
      道端でバナナを渡しておいて、3か月後に戻ってきて1000ドルを要求することはできない

  • ついに来た。仮想マシンを動かすたびに、性能が良く扱いやすいのでVirtualBoxよりlibvirtを選ぶが、GUIの選択肢は本当にひどかった
    libvirt向けの「最良」のGUIである virt-manager でさえ、バグが多く機能も不足している。HiDPI画面との相性が悪く、IPv6の設定方法もない、といった具合だ
    libvirt/KVMより性能が劣っても使い勝手が良いという理由でVirtualBoxを選んだことが何度もあったが、もうその必要はなさそうだ

    • IPv6はサポートされている。実際、ハイパーバイザーまで含めて IPv6専用ネットワーク を運用している
      $ virsh net-dumpxml default6
      default6
      73590ea2-eb15-4e67-b104-319721bdf302
      必要ならDHCPv6も使える
    • virt-managerはWaylandで HiDPI と相性が良い。逆にVirtualBoxのGUIはWaylandでとてもバグが多い
      事実上、両者は正反対だ。私はGUIがよりシンプルなのでvirt-managerを使っているし、どうせVirtualBoxの設定も悪夢に近い
      いずれにせよ、この機能は正しい方向への一歩だ。ディストリビューションが採用するのか、いつかアップストリームに統合されるのか気になる
    • GUIの選択肢がひどいという点には100%同意する。実際に仮想マシンを扱うとき、コマンドラインと格闘したくなくてlibvirtを完全に避け、最近までVMwareを使っていた
      当時はメインPCがWindows 10で、Windowsのコマンドライン環境はかなりお粗末だった
    • virt-managerは悪くないと思っていたが、具体的に挙げられている不満はもっともに見える
    • 主にどんなゲストを動かしていて、libvirt/KVM でより高い性能を見たのか気になる

  • これは実質的にVirtualBoxをvirt-managerとvirshの代替にするということか？
    私の知る限り、VirtualBoxはGPUのような PCIパススルー をサポートしていないが、そのような場合をどう扱うのか気になる
    LinuxではQEMU/KVMに移行して以来VirtualBoxを振り返っていないが、WindowsではVirtualBoxを使っていて、そのたびにGUIの方がずっと良く親切だと感じる
    追記すると、VirtualBoxはExtension Packを通じて実験的なPCIパススルーを提供している [0]。これをKVMバックエンドでも使えるのだろうか？
    [0] https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm...

  • 実用的な利点は、カーネルがアップグレードされるたびに、サードパーティ製ドライバーであるvboxカーネルモジュールを再コンパイルしなくてよいことだ。DKMSが管理者の介入なしに処理しようとはするが、常に不具合がないわけではない
    一方でVirtualBoxアプリケーションはデスクトップとうまく統合されるよう設計されているので、ゲストへVNCで接続することは代替になりにくい
    FreeBSD側でもbhyveハイパーバイザーに対して同様の取り組みがあればよいのだが
    用語の問題も興味深いが、最近Linuxの直接レンダリングマネージャーであるDRMの話題ですでに扱われていた。これらの略語は「ICT全体」よりも狭い集団で使われており、キーボード・ビデオ・マウス機器も同様だった
    Linux内部をそのレベルで扱う専門家は1%にも満たず、サーバールームの現場エンジニアも1%未満なので、こうした用語についての集団的認識がなく、再利用されたのだ
    LVMはすでにストレージ分野で使われているし、LKVMも紛らわしい

    • これを FreeBSD 向けに作るのは素晴らしいプロジェクトになるだろう。ただし規模が大きすぎて、何らかの資金援助なしには難しい
    • DKMSとカーネルモジュール更新を安定して処理できないディストリビューションを使うなんて、想像もつかない。NixOSで DKMS の問題に遭遇したことは一度もない
      downvoteしても、あなたのディストリビューションがより有能になるわけではない

  • LinuxでKVMとvirt-managerですでに得られるものに比べて、これが何をさらにもたらすのかよく分からない

    • VirtualBoxでWindowsを直接実行したときの性能は非常に高く、通常はvirt-manager（QEMU）より優れている。QEMUもきちんとチューニングすれば素晴らしい性能が出るが、多少手を入れる必要がある。
      VirtualBoxは全体としてユーザーフレンドリー。ゲスト統合、ドラッグ＆ドロップ、クリップボード、USBパススルー、オーディオ対応もVBoxはとても良い
    • デスクトップ環境の大半を仮想化して使っている。最初はLinuxホストとLinuxゲストを主に使うのでKVMとvirt-managerに行きたかったが、欲しかった2つの重要機能である暗号化と移植性を、その方法でどう実現すればいいのか分からなかった。
      ほとんどの仮想マシンは暗号化してあるので、持ち歩いても安心できる。いろいろな秘密情報も別途暗号化してあるが、仮想マシン自体の暗号化のおかげで、空港で機器をなくしても、アクセスされるべきでないものが露出するのではと心配しなくてよい。
      virt-managerとKVMでも可能な方法はあるが、気に入るものがなかった。ホストのファイルシステムレベルの暗号化に依存したくなかったし、移植性の問題もあり、以前にフルディスク暗号化で少し問題があったため、それに頼るのは気が進まなかった。
      VirtualBoxも本質的にはフルディスク暗号化をしているようなものだが、ゲストには見えず、安定しているように見える。
      移植性の面では https://www.vbox.me/ を使って仮想マシンとホストをフラッシュドライブにインストールし、追加インストールなしでどのWindowsホストでも自分の環境を実行できるはずだ。まだ実際には試していないが、大きな利点だった。
      今では環境の大半がVagrantで自動構成されている: https://github.com/robsheldon/vagrantfiles なので、virt-managerの利点の一部も得られている。
      Oracleに何か依存するのは本当に気に入らない
    • まともなUIと、可能ならVirtualBoxアプライアンスの利用サポートが期待できる

  • KVMはキーボード・ビデオ・モニター系デバイスの文脈でしか聞いたことがなく、仮想マシンという概念にはあまり合わない気がする。ここでは別の意味なのか？

    • そう、かなり違う。基本的にはLinuxをハイパーバイザーとして使えるようにするプロジェクトで、非常に広く使われている。
      https://en.m.wikipedia.org/wiki/Kernel-based_Virtual_Machine
    • 単純化すると、こういう文脈になる。Linuxの世界には大きなハイパーバイザーが2つある。
      Xenはカーネルを拡張して仮想CPUをタイムスライスでサポートする。
      KVMは各仮想コアをLinuxスケジューラを使うプロセスとして割り当てる。
      ハードウェア仮想マシンのvCPUコアがプリエンプトされると、レジスタなどを再設定する必要があるvmexit呼び出しが発生し、コストが高い。
      昔のAWSインスタンスはXenで動いていて、ゲスト間の公平性を合わせやすいという利点があった。
      KVMには、赤黒木ベースでよく最適化されたLinuxスケジューラの恩恵を受けられる利点がある。
      たとえば新しいCPUが出ると、KVMはアップストリームでサポートを得られるが、Xenは自前で対応する必要がある。
      cgroupsのような技術が改善されるにつれ、タイムスライス満了のためにスレッドがプリエンプトされずに完了できる利点が、vmexitコストの回避につながった。
      理論的には、本質的に最適化されたLinuxの中核機能を活用できる点がVirtualBoxにも利益をもたらすはずだ。
      KVMを使う人の大半は、実装方式を隠してくれるlibvirtのような抽象化レイヤーを使う。
      実際にプロセスを見ると、実装がKVMでもqemuが見えるはずだ
    • Kernel-Based Virtual Machineの意味で、2007年からある仮想マシンエンジンだ: https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine
    • https://linux-kvm.org/page/Main_Page

  • これは本当に気になる。侵入テスターとしてLinuxノートPCを使っていて、VirtualBox内のKali VMで多くの時間を過ごしている。
    KVMバックエンドでどの程度の性能向上が期待できるのだろうか？

    • この構成に関連して、具体的に1つ聞きたい。興味本位で侵入テストを始めてみようと思い、出発点としてHackTheBoxを触ってみることにした。
      そこのVPNに接続する必要があるので、この活動を個人ネットワークから分離したほうがよさそうに思えた。
      侵入テスト用VMではどんなネットワーク構成を使っているのか気になる。理想的には、VMはインターネット、したがってHTB VPNにはアクセスできるが、ローカルネットワーク内部にはアクセスできないようにしたい。
      ただ、それを信頼できる形で実装する方法がよく分からない。そもそも考えすぎで実用的ではないのかもしれないので、専門家の見方が知りたい。
      普通ならQEMUを使うだろうが、VirtualBoxにこれをより簡単にする機能があるなら、このケースではVirtualBoxを使ってもよい
    • 設定とワークロード次第。最近のIntel CPU基準では、我々の性能ダッシュボードで一部のベンチマークに**+10%**が見られる。
      ただし、一般化して言うのは難しい

  • 過去に顧客の一部がVBoxを使っていたため、VirtualBox機能の一部をサポートするためにlibvirtへ貢献したことがある。
    あのときこれがあれば便利だっただろうし、すべての顧客にKVM仮想マシンを使ってもらえただろう。
    作業お疲れさま

  • かっこいいのは確かだが、自分がもう年を取ってひねくれただけかもしれないけれど、10年前ならすごかったと思う。今これを本当に気にする人はいるのだろうか？

  • 最近ではLinuxの中でLinux GUIを仮想化するなら、virt-manager、VMware、VirtualBoxよりずっと良い方法も可能だ。
    crosvmを使えば共有メモリバッファでWaylandを共有し、ゲストでOpenGLとVulkanのアクセラレーションも得られる。
    こうすると、ゲストアプリケーションがホストのWaylandコンポジタを通してシームレスに表示される

    • そう、実際かなり良い。Chromebookも持っているが、Linuxアプリの統合は本当にシームレスだ。
      ただしVBoxの主なユースケースは大半がWindowsだ