6.5. Red Hat Virtualization 4.4 バッチ更新 4 (ovirt-4.4.5)

6.5.1. バグ修正

以下のバグは、Red Hat Virtualization の本リリースで修正されました。

BZ#1145658
本リリースでは、メモリーダンプを別のストレージドメインに移動するか、スナップショットからメモリーダンプを削除することで、メモリーダンプが含まれるストレージドメインを正しく削除できます。
BZ#1815589
以前は、セルフホストエンジンで移行が正常に完了した後、ソースホストの HA エージェントは即座に EngineDown 状態に移行し、移行先ホストが共有ストレージを迅速に更新しなかった場合は、その後すぐにローカルでエンジンを開始しようとし、これにより、Manager 仮想マシンは稼働中としてマークされていました。そのため、移行先ホストが保持する共有ロックが原因で、仮想マシンの起動に失敗していました。また、これにより、誤ったアラームと通知も生成されていました。本リリースでは、HA エージェントは最初に EngineMaybeAway 状態に移行し、移行先ホストが更新された状態で共有ストレージを更新するためのより多くの時間を提供します。その結果、通知や誤アラームは生成されなくなりました。注記: ソースホストで仮想マシンを起動する必要があるシナリオでは、この修正により、ソースホスト上の Manager 仮想マシンの起動にかかる時間がわずかに長くなります。
BZ#1860492
以前は、Linux 仮想マシンのテンプレートの作成時に Seal オプションが使用された場合は、元のホスト名はテンプレートから削除されませんでした。本リリースでは、ホスト名は localhost または新しい仮想マシンのホスト名に設定されます。
BZ#1895217
以前は、仮想マシンが固定されたホストが削除されると、Manager は起動できませんでした。その結果、セルフホストエンジンのセットアップは失敗していました。本リリースでは、ホストが削除されると、仮想マシンはそのホストに固定されたままにはならず、Manager は正常に起動できるようになりました。
BZ#1905108
以前は、短時間の間隔で実行中の仮想マシンに複数の仮想ディスクをプラグすると、一部のディスクのプラグに失敗し、エラーメッセージ「Domain already contains a disk with that address」というエラーメッセージが表示されていました。本リリースでは、以前に仮想マシンにプラグされていた別のディスクにすでに割り当てられているアドレスが、実行中の仮想マシンにプラグされているディスクに割り当てられないようにすることで回避されています。
BZ#1916032
以前は、セルフホストエンジンのホストの ID の数が 64 よりも大きい場合、他のホストがそのホストを認識しないため、ホストは「hosted-engine --vm-status」に表示されませんでした。本リリースでは、セルフホストエンジンのホスト ID 数を 2000 まで許可しています。
BZ#1916519
以前は、ホストの使用済みメモリーでは、SReclaimable メモリーを考慮していませんでした。一方で、空きメモリーに対しては考慮していました。そのため、ホストの統計に差異が生じていました。本リリースでは、SReclaimable メモリーは使用済みメモリーの計算の一部になります。
BZ#1921119
以前は、実際にはすべてのネットワークが同期していても、クラスターページは非同期クラスターを示していました。これは、ホスト QoS が同じホストの 2 つのネットワークに割り当てられた場合に、コードの論理エラーによって生じていました。本リリースでは、このセットアップの非同期はクラスターページに表示されません。
BZ#1931786
以前は、Red Hat Virtualization Manager は 4.5 クラスターの SkuToAVLevel 設定を利用できませんでした。本リリースでは、これらのクラスターで SkuToAVLevel が利用可能となり、Windows の更新でゲストホストの Red Hat 関連のドライバーを更新することができます。
BZ#1940672
以前は、Red Hat Virtualization Manager 4.4.3+ が Skylake/Cascadelake の CPU タイプと互換性レベル 4.4 (以下) で設定されたクラスター内のホストをアップグレードすると、ホストは動作しなくなる可能性がありました。本リリースでは、クラスターが安全な Skylake/Cascadelake CPU タイプ 1 (Secure Intel Skylake Client Family、Secure Intel Skylake Server Family、または Secure Intel Cascadelake Server Family) で設定されている場合、アップグレードにより、ホストが動作不能になる可能性があるため、Red Hat Virtualization Manager はホストのアップグレードをブロックします。クラスターが安全でない Skylake/Cascadelake CPU タイプ 2 (Intel Skylake Client Family、Intel Skylake Server Family、または Intel Cascadelake Server Family) で設定されている場合、クラスターを安全な Skylake/Cascadelake CPU タイプへ変更するよう推奨する通知がユーザーに出されますが、ホストのアップグレードは続行できるようになっています。アップグレードしたホストで動作できるようにするには、ユーザーはオペレーティングシステムレベルで TSX を有効にする必要があります。