News¶

LXD 4.21 リリースのお知らせ¶

10th of December 2021

はじめに ¶

LXD チームは LXD 4.21 のリリースをお知らせできることにとてもワクワクしています!

今年最後のリリースでは、多くの新機能に加えて、主にクラスタリング、イベントハンドリング、exec セッション、LXD データベース関係の多数の改良を行いました。

Enjoy!

新機能とハイライト ¶

クラスターメンバーグループ ¶

大きなクラスターのオペレーターは他とは異なるシステムをいくつか持っていることが多いです。
段階的に廃止される古いシステムや、珍しいアーキテクチャーの変わった開発ボードだったり、GPU を多数搭載したマシンだったりするかもしれません。

このようなケースでは、新しいインスタンスをこのようなマシングループの 1 つにターゲットにする方法があると非常に便利です。これは、これまでは --target=NAME でマニュアルで行えました。しかし、複数のシステムを扱う場合は、手作業でロードバランシングする必要があります。

LXD 4.21 ではクラスターグループが導入されました。
これは lxc cluster group で管理し、一度クラスター内の関連するサーバーに割り当てられると、特定のグループを --target=@group-name を使ってターゲットにできます。LXD はグループ内で一番負荷の低いサーバーを選択します。

これはプロジェクト内でも使用でき、restricted.cluster.groups にはプロジェクトが使用を許可されたグループのリストを指定できます。これにより、本番用と開発用の異なるハードウェアを簡単に扱うことができるようになり、どのプロジェクトとユーザーがどれとやりとりできるのかを調整できます。

加えて、最近導入された scheduler.instance クラスターメンバーオプションが拡張され、値として group が使えるようになりました。クラスターメンバー上でそのように設定されると、名前またはそのグループのひとつで直接ターゲットにされない限りは、LXD スケジューラーは常にそのクラスターメンバーに対するワークロードの自動割り当てを常にスキップするようになります。

stgraber@dakara:~$ lxc cluster group list
+---------+-----------------------+---------+
|  NAME   |      DESCRIPTION      | MEMBERS |
+---------+-----------------------+---------+
| core    | Core servers (HA)     | 4       |
+---------+-----------------------+---------+
| default | Default cluster group | 6       |
+---------+-----------------------+---------+
| lab     | Lab servers           | 2       |
+---------+-----------------------+---------+

仕様: https://discuss.linuxcontainers.org/t/lxd-cluster-server-grouping/12716
ドキュメント : https://linuxcontainers.org/lxd/docs/master/clustering#cluster-groups

cloud-init サポートの再実装 ¶

LXD はコンテナと仮想マシンでの cloud-init の使用をずっとサポートしてきました。
しかし、それは少しハック的で、user.user-data、user.vendor-data、user.network-config をイメージ固有のロジックと組み合わせ、cloud-init の静的設定ファイルを作成しました。そしてそれを cloud-init がピックアップします。

これはすべて、cloud-init が LXD をクラウドとして扱っておらず、そのため特定のデータソースを持っていなかったためです。

これは、cloud-init チームが LXD の /dev/lxd API を使った LXD データソースのサポートを開始したことで変化しています。その一環として、cloud-init をファーストクラスの LXD の機能に昇格させました。その最も目に見える変化は新しい設定キーです。

• cloud-init.user-data
• cloud-init.vendor-data
• cloud-init.network-config

新しいイメージはこれらの新しい設定キーで問題なく動作します。しかし移行を容易にするために、しばらくの間、古いイメージがサポートされたままとなります。同様に、専用のデータソースをサポートする新しい cloud-init に移行する際、移行はシームレスに行われ、ユーザーは目に見える変化はありません。

今後はこれを前提に、ネットワーク設定を変更する際のライブでの設定変更のサポートの導入や、cloud-init clean を実行して再起動し、更新された設定で cloud-init を新たに実行するといった、cloud-init データソースの将来的な改良が期待できます。

仕様 : https://discuss.linuxcontainers.org/t/lxd-first-class-cloud-init-support/12559
ドキュメント : https://linuxcontainers.org/lxd/docs/master/cloud-init

信頼済み証明書の自己更新 ¶

lxc config trust editを使って、既存の信頼済み証明書の更新ができるようになりました。
これは、ユーザーが（プロジェクトの制限を通して）LXD へのアクセスを制限している場合でも有効です。

制限されているユーザーの場合、自身の証明書（現在 LXD との通信に使っている証明書）の更新のみが許可されます。

この機能は主に LXD の API と通信を行う自動化されたシステムのためのもので、証明書の有効期限が短く、したがって失効前に更新を行うために自身が必要かもしれません。

プロジェクトでのディスクパススルーの制限 ¶

新たに restricted.devices.disk.paths オプションがプロジェクトの設定に追加されました。
このオプションは restricted.devices.disk が allow に設定されているときに有効になります。設定されている場合、インスタンスに渡すホストのパスを制限することができます。

これはホストパスのコンマ区切りのリストです。そのパスとそれ以下のパスにあるものがマウントできるようになります。

lxc project set foo restricted=true
lxc project set foo restricted.devices.disk.paths=/home/foo
lxc project set foo restricted.devices.disk=allow

プロジェクト foo のインスタンスは、source プロパティが /home/foo かその内部であれば、ディスクエントリーを使用できます。

プロジェクトでの idmap uid/gid の制限 ¶

前の例に関連した問題で、ユーザーが自身の制限付きプロジェクト内のホームディレクトリーを渡せるようにしたあと、次に出てくる問題はファイルの所有権がコンテナや仮想マシン内のものと一致しないことです。

これに対応するために、新たに restricted.idmap.uid と restricted.idmap.gid 設定オプションを追加しました。

lxc project set foo restricted=true
lxc project set foo restricted.devices.disk.paths=/home/foo
lxc project set foo restricted.devices.disk=allow
lxc project set foo restricted.idmap.uid=1000
lxc project set foo restricted.idmap.gid=1000

この結果、同じ制限されたユーザーが raw.idmap を使って、インスタンス内で uid 1000/1000 をマッピングできるようになります。したがって、raw.idmap を both 1000 1000 のように設定して、インスタンス内の uid 1000 と gid 1000 をホスト上の実際の uid 1000 と gid 1000 にマッピングされるようにし、共有ディスク上のパーミッションが揃うようにします。

これに関連して、raw.idmap が仮想マシンでも有効になりました。制限付きプロジェクト内で共有ディスクへのアクセスが、コンテナで行うのと同じようにできるようになりました。

lxc --sub-commands によるすべてのコマンドのリスト表示 ¶

lxc は時間の経過とともにかなり大きくなり、たくさんのサブコマンドやサブサブコマンドが（そしてサブサブサブコマンドがいくつか）あります。多数のヘルプや man ページを見て回るのではなく、すべてのサブコマンドを lxc --sub-commands ですべてのサブコマンドの概要を見ることができ、lxc --all --sub-commands で、あまり一般的ではないコマンドも含めることができます。

--all-projects を使ったプロジェクトをまたいだインスタンスのリスト表示 ¶

LXD のプロジェクト機能が導入されて以来、かなり頻繁にリクエストのあった機能です。すべてのプロジェクトを一度にリスト表示する API と CLI のサポートを追加しました。

stgraber@dakara:~$ lxc list --all-projects status=running
+---------+---------------+---------+------------------------+---------------------------------------------+-----------------+-----------+
| PROJECT |     NAME      |  STATE  |          IPV4          |                    IPV6                     |      TYPE       | SNAPSHOTS |
+---------+---------------+---------+------------------------+---------------------------------------------+-----------------+-----------+
| default | lxd-build     | RUNNING | 172.17.250.23 (eth0)   | 2602:fc62:b:250:216:3eff:fece:d188 (eth0)   | CONTAINER       | 0         |
+---------+---------------+---------+------------------------+---------------------------------------------+-----------------+-----------+
| default | win11         | RUNNING |                        | 2602:fc62:b:250:216:3eff:fe16:48d6 (eth0)   | VIRTUAL-MACHINE | 0         |
|         |               |         |                        | 2602:fc62:b:250:203b:9725:cde5:ebca (eth0)  |                 |           |
+---------+---------------+---------+------------------------+---------------------------------------------+-----------------+-----------+
| demo    | impish        | RUNNING | 172.17.250.25 (enp5s0) | 2602:fc62:b:250:216:3eff:fe63:64be (enp5s0) | VIRTUAL-MACHINE | 0         |
+---------+---------------+---------+------------------------+---------------------------------------------+-----------------+-----------+

新しい database-leader クラスターロール ¶

クラスターには少し前から database と database-standby ロールがあり、内部的な dqlite のセットアップが見えるようになっていました。さらに、どのサーバーが現時点のデータベースリーダーに選出されているのかを確認できるようになりました。

stgraber@dakara:~$ lxc cluster list
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
|  NAME   |                 URL                 |      ROLES       | ARCHITECTURE | FAILURE DOMAIN |        DESCRIPTION        | STATE  |      MESSAGE      |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| asuras  | https://[2602:fc62:b:100::200]:8443 | database         | aarch64      | default        | APM X-Gene 2              | ONLINE | Fully operational |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| athos   | https://[2602:fc62:b:100::204]:8443 | database-standby | x86_64       | default        | Intel Xeon E5-2695v2 (2x) | ONLINE | Fully operational |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| delmak  | https://[2602:fc62:b:100::205]:8443 | database         | aarch64      | default        | Qualcomm Centriq 2400     | ONLINE | Fully operational |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| entak   | https://[2602:fc62:b:100::201]:8443 | database-standby | aarch64      | default        | APM X-Gene 2              | ONLINE | Fully operational |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| madrona | https://[2602:fc62:b:100::202]:8443 |                  | aarch64      | default        | APM X-Gene 2              | ONLINE | Fully operational |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+
| vorash  | https://[2602:fc62:b:100::203]:8443 | database-leader  | aarch64      | default        | APM X-Gene 2              | ONLINE | Fully operational |
|         |                                     | database         |              |                |                           |        |                   |
+---------+-------------------------------------+------------------+--------------+----------------+---------------------------+--------+-------------------+

一貫性のある単位 ¶

LXD が表示するデフォルトの単位は、ディスクとメモリ使用量に対しては IEC (base 2)、ネットワークの使用量は Metric (base 10) となるように調整されています。

これは、LXD が報告するディスク・メモリ使用量が、ほとんどのディストリビューションで df と free のようなツールがデフォルトで使用する使用量と一致するように行われます。

この変更の結果は、lxc info、lxc list、lxc project usage、lxc storage info、lxc storage volume info で見ることができます。

stgraber@dakara:~$ lxc info lxd-build
Name: lxd-build
Status: RUNNING
Type: container
Architecture: x86_64
PID: 8891
Created: 2021/08/20 16:28 EDT
Last Used: 2021/11/21 17:29 EST

Resources:
  Processes: 44
  Disk usage:
    root: 4.43GiB
  CPU usage:
    CPU usage (in seconds): 670
  Memory usage:
    Memory (current): 550.27MiB
    Swap (current): 3.48MiB
  Network usage:
    eth0:
      Type: broadcast
      State: UP
      Host interface: vethb7314fa0
      MAC address: 00:16:3e:ce:d1:88
      MTU: 1500
      Bytes received: 205.19MB
      Bytes sent: 6.31MB
      Packets received: 273612
      Packets sent: 62221
      IP addresses:
        inet:  172.17.250.23/24 (global)
        inet6: 2602:fc62:b:250:216:3eff:fece:d188/64 (global)
        inet6: fe80::216:3eff:fece:d188/64 (link)
    lo:
      Type: loopback
      State: UP
      MTU: 65536
      Bytes received: 100.80kB
      Bytes sent: 100.80kB
      Packets received: 856
      Packets sent: 856
      IP addresses:
        inet:  127.0.0.1/8 (local)
        inet6: ::1/128 (local)

仮想マシンでの routed ネットワーク ¶

routed nictype オプションを仮想マシンでも動作するように拡張しました。

しかしコンテナとは違い、インスタンス内のデバイスをあらかじめ設定することができないので、VM 内に正しいアドレス、ルート、DNS を設定するために、ユーザーによる手動の設定が必要です。

routed タイプの NIC での ipv4.routes と ipv6.routes のサポート ¶

また、routed nictype に関連して、これらの NIC のエントリーに ipv4.routes と ipv6.routes を設定できるようになりました。

これは他の NIC タイプと同様に動作し、ホストは指定されたアドレスまたはサブネットに対するエントリーをルートテーブルに追加し、インスタンスに直接ルーティングします。

ネットワークゾーンで NAT されたアドレスをスキップするオプション ¶

ネットワークゾーンに network.nat オプションが新たに追加されました。false に設定すると、NAT されたレコードに対するすべてのレコードがゾーンから削除されます。

これにより、IPv4 は NAT されており、IPv6 はグローバルにルーティングされている環境で、グローバルにアクセスできるレコードだけを持つクリーンな DNS ゾーンを取得できます。

セキュリティフィルタリングオプションを使った IP アドレスファミリーのブロック ¶

アドレスに対する none エントリーとフィルタリングオプションを組み合わせることで、インスタンス内の IP ファミリーを完全に無効化できるようになりました。

IPv4 を無効化するには:

• security.ipv4_filtering=true
• ipv4.address=none

IPv6 を無効化するには:

• security.ipv6_filtering=true
• ipv6.address=none

遅い可能性のある rbd du を無効化する新たなストレージ設定オプション ceph.rbd.du ¶

Ceph ユーザーは停止したインスタンス、特に多数のスナップショットを持つインスタンスのディスク使用量のリスト表示が、非常に非常に遅いことに気づいているかもしれません。Ceph RBD のオプションをいくつか有効化（fast-diff が思い浮かびます）してスピードアップする方法があります。それでも理想的な方法とはいえず、かなりの負荷がかかる可能性があります。

インスタンスが停止しているときはディスク使用量を取得しないようにしたい場合は、ストレージプールで ceph.rbd.du=false が設定できるようになりました。

プロジェクト間のインスタンスとボリュームの移動の最適化 ¶

LXD は、プロジェクト間のインスタンスとストレージボリュームの移動を少し前からサポートしています。しかし移動する際の通常の方法は、クライアントがインスタンスやボリュームを新しいプロジェクトにコピーし、その後オリジナルを削除するというものでした。

これにより、一時的にデータが重複してしまい、かなりの負荷がかかることになります。

LXD 4.21 で、この操作がサーバーサイドでサポートされるようになり、ほとんどの場合で単純な名前の変更と同じくらいの速度で行えるようになりました。

クラスタメンバー間のカスタムボリュームのコピー・移動のサポート ¶

Ceph/CephFS 以外では、クラスター内のカスタムストレージボリュームは、それらを保存しているサーバー特有のものです。つまり、同じカスタムストレージボリューム名がクラスター内にいくつも存在でき、違うものを参照できます。

これは、2 つのクラスターメンバー間でこのようなボリュームをコピーや移動したい場合に問題を引き起こしていました。これに対応するため、lxc storage volume copy POOL VOLUME-NAME TARGET-VOLUME-NAME --target SOURCE-MEMBER --destination-target DESTINATION-MEMBER を実行できるようになりました。

--target は実質ソースを参照しているため、ネーミングが少し混乱する可能性があります（そのサーバーに対するリクエストをターゲットにしているため）。しかし、新たに追加された --destination-target は正しい移動先サーバーをターゲットにして、マイグレーションを完了できます。

すべての変更点（翻訳なし）¶

このリリースでの完全な変更点のリストは次の通りです:

試用環境 ¶

この新しい LXD リリースは私たちの デモサービス で利用できます。

ダウンロード ¶

このリリースの tarball は ダウンロードページ から取得できます。

ビルド済みバイナリーは次のように使えます:

• Linux: snap install lxd
• MacOS: brew install lxc
• Windows: choco install lxc

LXD 4.20 リリースのお知らせ ¶

6th of November 2021

はじめに ¶

LXD チームは LXD 4.20 のリリースをお知らせできることにとてもワクワクしています!

このリリースは、たくさんの新しい機能満載の非常に忙しいリリースでした。

VM ユーザーは、ライブマイグレーションの初期実装とコアスケジューリングのサポートを見てハッピーになるでしょう。コンテナユーザーは sysctl 関連の新しい設定ができるようになりました。

新機能の大部分はネットワークに関係したものです。ピアネットワークの関係、自動生成される DNS のネットワークゾーン、SR-IOV でアクセラレーションされる OVN ネットワークなどです。

そして最後に、クラスタリングの面では、どのサーバーが新しいワークロードを受け取るのかをコントロールできるようになりました。

Enjoy!

新機能とハイライト ¶

仮想マシンのライブマイグレーション ¶

LXD に仮想マシンのライブマイグレーションの初期実装がなされました。

この機能は、ふたつの独立したサーバー間を移動するためには lxc move を使うだけで、もしくはクラスター内での移動のためには lxc move --target を使うだけで動作します。

これを使うには、VM 上で migration.stateful を有効にする必要があります。この設定を有効にすると、GPU、USB、ホストの PCI デバイスが使用できなくなり、さらに virtiofs が無効化されます（ファイルシステムパススルーが 9p に制限されます）。

現時点の実装では、すぐにインスタンスのステートフルストップを実行したあと、（実行時の状態を含む）全データのマイグレーションが行われ、ターゲット上でリストアされます。

これは Ceph を使用している場合は 2-3 秒で済みますが、他のストレージバックエンドではかなり時間がかかる可能性があります。BTRFS と ZFS 上のボリュームを非常に手軽に素早くリフレッシュできるようになるように、今後 6 ヶ月 LXD の改良に取り組みます。これによりこれらのストレージバックエンドでも同じくらいのパフォーマンスが得られるようになるでしょう。

OVN 向けネットワークピアリング ¶

LXD のネットワーキングに OVN を使い、複数のネットワークが定義されている際に、現在は、あるネットワークから他のネットワークへのルーティングは OVN を出て、アップリンクのネットワークを通り、再度 OVN へ入ってきます。これはネットワークフローを完全にコントロールするために必要な場合もありますが、大きなボトルネックになる可能性があります。

これを解決するために、LXD でネットワークピアをサポートしました。ピアは一組のネットワークの両側に追加されます（プロジェクト間でも可能）。ピアが確立すると OVN は、トラフィックが OVN から出ないように、一方のネットワークから他方のネットワークへ直接ルーティングするように設定されます。

ピアの関係を使うことで ACL ルールを簡単にすることもできます。@some-network/some-peer をソースもしくはデスティネーションフィールドで使うことで、特定のピアネットワークに出入りするトラフィックに作用させることができます。

このようなピアを管理するには、新しい lxc network peer コマンドを使います。API レベルでは、すべて /1.0/networks/NAME/peers 配下となります。

仕様 : https://discuss.linuxcontainers.org/t/lxd-ovn-network-to-network-routing/12165
ドキュメント : https://linuxcontainers.org/lxd/docs/master/network-peers

ネットワークゾーン（DNS） ¶

多数のプロジェクトで多数のインスタンスを管理している方々は、すべてのインスタンスが有効な正引きと逆引きの DNS レコードが、ネットワーク全体で利用できることの真価を認めるでしょう。

これまでは、内蔵の dnsmasq DNS サーバーと、dnsmasq が自動生成する DNS ゾーンを使うしかありませんでした。しかし、この方法はひとつのプロジェクト内のひとつのネットワークにしか使えませんでした。そして、大規模なインフラ内では簡単に統合して機能させられませんでした。これを解決する別の方法として、完全に手動で準備した DNS サーバーを別に動作させる選択肢がありました。

今回のリリースで、LXD にネットワークゾーンの概念を導入しました。これは事実上、LXD ネットワークに結びついた DNS ゾーンです。そして、正引き DNS レコード、逆引き IPv4, IPv6 レコードに使用できます。

この機能を設定するには、最初にいくつかゾーンを作成します（lxc network zone create）。次に、次の設定のいずれかを設定し、適切なネットワーク上の適切なレコードタイプに割り当てます。

• dns.zone.forward
• dns.zone.reverse.ipv4
• dns.zone.reverse.ipv6

最後に、ゾーンは少なくともひとつの対となる DNS サーバーに設定する必要があります。これは、ゾーン自体をキーとする次の設定を使って行います:

• peers.NAME.address
• peers.NAME.key

クライアントとなる DNS サーバーが LXD からゾーンを取得できるようにするためには、これらのいずれか、もしくは両方が設定されている必要があります。

これらがすべて設定されると、外部の DNS サーバーはそのゾーンに関して LXD からゾーン転送（AXFR）を行えるようになり、そのゾーンを提供できるようになります。LXD 自身はゾーン転送だけができ、直接問い合わせはできません。

仕様 : https://discuss.linuxcontainers.org/t/lxd-built-in-dns-server/12033
ドキュメント : https://linuxcontainers.org/lxd/docs/master/network-zones

OVN ネットワークでの SR-IOV アクセラレーション ¶

LXD での OVN ベースのネットワークでのパフォーマンス改良のために、SR-IOV アクセラレーションをサポートするようになりました。

これを動作させるには、switchdev モードをサポートする物理ネットワークカードを使用します。このようなカードはゲスト側の VF とホスト側の representor ポートの両方を提供します。適切なカードを持ったシステムが、カードをswitchdevモードに設定し、OVS ブリッジに PF を追加し、OVS を SR-IOV オフロード用に設定すると、LXD はコンテナや VM が使うために VF を自動的に割り当てます。

すべての前提条件を満たしたとき、行う必要があるのは LXD の NIC デバイスに acceleration=sriov を設定することだけで、残りは LXD がやってくれます。

特に 40G、100G、200G ネットワークでは、トラフィック処理の大部分を直接物理 NIC にオフロードすることになるので、パフォーマンスが大幅に向上します。このような環境では、ほとんどの接続では最初のパケットのみがホストシステムと OVS/OVN を経由し、残りのすべてのトラフィックはハードウェアで直接処理されます。

ドキュメント : https://linuxcontainers.org/lxd/docs/master/instances#nic-ovn

コンテナでの Linux sysctl 設定 ¶

新たな設定 linux.sysctl.* を導入しました。これによりコンテナ起動時に、直接特定の sysctl を特定の値に設定できるようになりました。

これはコンテナ内に sysctl.d エントリーを持つよりも柔軟性があります。LXD がホストから適用することで、適切にネームスペース化されているけれども、特権への昇格が必要な sysctl にアクセスできます。

ドキュメント : https://linuxcontainers.org/lxd/docs/master/instances#key/value-configuration

仮想マシンのコアスケジューリング ¶

LXD 4.19 でのコンテナに対するコアスケジューリングに続いて、コアスケジューリングを仮想マシンに拡張しました。コアスケジューリングをサポートしたカーネル上で LXD が動作している場合、LXD は、特定の VM 向けのすべての vCPU スレッドが、同じコアスケジューリンググループに属することを保証します。

コアスケジューリングは、Spectre 脆弱性のためにゲストからアタックされるリスクがある CPU で SMT を使えるように設計されています。コアスケジューリングは、ゲストが特定のコア・スレッドのペアを両方使うか、ゲストが関連するコアを使う間スレッドが使用されないことを保証します。

クラスターメンバーの設定 ¶

クラスターメンバーが設定キーをサポートするようになりました。

自由形式の user.KEY=VALUE に加えて、導入された設定キーは scheduler.instance です。この設定は、特定のクラスターメンバーには自動的にインスタンスは配置せず、CLI で --target オプションを直接指定した場合のみインスタンスを配置できます。

ドキュメント : https://linuxcontainers.org/lxd/docs/master/clustering#managing-a-cluster

ネットワークリースの改良 ¶

新しいネットワークゾーン機能は、ネットワークリースに大きく依存しているので、改良をいくつか行いました。

その改良は:

• OVN ネットワークでのネットワークリースのサポートしました
• リースのリスト内にアップリンクのネットワークが表示されるようになりました
• リストに IPv6 EUI64 アドレスが含まれるようになりました（ステートフルな DHCPv6 が有効になっていないとき）

CLI では、これらのレコードは lxc network list-leases NETWORK-NAME で見ることができます。

すべての変更点（翻訳なし） ¶

このリリースでの完全な変更点のリストは次の通りです:

試用環境 ¶

この新しい LXD リリースは私たちの デモサービス で利用できます。

ダウンロード ¶

このリリースの tarball は ダウンロードページ から取得できます。

ビルド済みバイナリーは次のように使えます:

• Linux: snap install lxd
• MacOS: brew install lxc
• Windows: choco install lxc

LXD 4.0.8 リリースのお知らせ¶

26th of October 2021

はじめに ¶

LXD チームが LXD 4.0.8 のリリースをお知らせします!

このリリースは、2025 年 6 月までサポートされる LXD 4.0 に対する 8 つめのバグフィックスリリースです。

バグ修正と改良 ¶

このリリースには、開発ブランチからの数カ月分のバグフィックスと細かな改善が含まれています。

主な変更点は次の通りです:

• コードベースが Go モジュールと vendor ディレクトリーに切り替えられました
• ディザスターリカバリーのための lxd import が lxc recover に置き換えられました
• lxc monitor で --all-projects と --format が使えるようになりました
• lxc cluster remove --force に --yes を追加しました
• ネットワークステート API のネットワークカウンターの拡張
• USB GPU の検出

これらはすべて LXD のフィーチャーリリースからバックポートされた改良です。これらの改良はデータベースの変更や、API の動きの変更が不要で、LTS リリースにバックポートするのに十分な操作性の改良になると考えられたものです。

コミットの全リストは次の通りです（翻訳なし）:

試用環境 ¶

最新の LXD リリースを デモサービス で試せます。

ダウンロード ¶

このリリースの tarball は ダウンロードページ から取得できます。

ビルド済みバイナリーは次のように使えます:

• Linux: snap install lxd
• MacOS: brew install lxc
• Windows: choco install lxc

LXD 4.19 リリースのお知らせ¶

1st of October 2021

はじめに ¶

LXD チームは LXD 4.19 のリリースをお知らせできることにとてもワクワクしています!

このリリースはバグ修正で非常に忙しいリリースで、それとともにシャットダウンロジックの改良、ディザスターリカバリーの容易化、改良されたロギング、さまざまなネットワーク設定処理の改善など、クラスタリングに関するたくさんの改良が行われています。

最近追加したネットワーク転送機能でもいくつかの修正と細かい改善を行い、BGP と新たな lxc network forward get コマンドと適切に統合されています。

このリリースの目玉機能は、インスタンスメトリクスの追加です。新しいエンドポイント（/1.0/metrics）が追加され、Prometheus のようなツールでスクレイプするのに適した、テキストの OpenMetrics エンドポイントが公開されるようになりました。

Enjoy!

新機能とハイライト ¶

インスタンスメトリクス ¶

インスタンスのリソース消費状況をトラッキングするための良い方法が、何年にもわたって頻繁にリクエストされてきました。これは、多数のプロジェクトや複数のクラスター化されたサーバーがある負荷の高いシステムで特に重要になります。

これを扱うために、LXD 4.19 では新たに /1.0/metrics API エンドポイントを導入しました。これは Prometheus や同様のツールで使うのに適した、テキストの OpenMetric エンドポイントを提供します。

現状、次のようなものに関連するさまざまなメトリクスを提供します:

• CPU
• メモリー
• ディスク
• ネットワーク
• プロセス

全体的に、メトリクス名は node-exporter のものと合わせるようにしています。これにより、既存のダッシュボードやツールの導入がとてもに簡単になります。

このエンドポイントは認証済みユーザーが常に利用できるようになっています。一方で、core.metrics_address でリッスンする追加のアドレスを設定したり、メトリクスインターフェースのみに制限される追加の信頼済み証明書を追加したりすることもできます（lxc config trust add --type metrics）。

出力例 : https://gist.github.com/stgraber/ab7f204fb4bf53dbe134f6460bf41470

仕様 : https://discuss.linuxcontainers.org/t/lxd-metric-exporter-for-instances/11735
ドキュメント : https://linuxcontainers.org/lxd/docs/master/metrics

lxc cluster list の再実装 ¶

lxc cluster list の出力で、データベースのカラムに真偽値の YES/NO だけの表示から、ロールのテキストリストを表示するように変更されました。

現時点では、ロールは database か database-standby のどちらかですが、将来的にはさらに追加される予定です。これにより、クラスター化されたサーバーが何をしているのかが正確に理解しやすくなります。

stgraber@dakara:~$ lxc cluster list s-dcmtl-cluster:
+---------+-------------------------------------+----------+--------------+----------------+----------------------+--------+-------------------+
|  NAME   |                 URL                 |  ROLES   | ARCHITECTURE | FAILURE DOMAIN |     DESCRIPTION      | STATE  |      MESSAGE      |
+---------+-------------------------------------+----------+--------------+----------------+----------------------+--------+-------------------+
| abydos  | https://[2602:fd23:8:200::100]:8443 | database | x86_64       | default        | HIVE - top server    | ONLINE | Fully operational |
+---------+-------------------------------------+----------+--------------+----------------+----------------------+--------+-------------------+
| langara | https://[2602:fd23:8:200::101]:8443 | database | x86_64       | default        | HIVE - middle server | ONLINE | Fully operational |
+---------+-------------------------------------+----------+--------------+----------------+----------------------+--------+-------------------+
| orilla  | https://[2602:fd23:8:200::102]:8443 | database | x86_64       | default        | HIVE - bottom server | ONLINE | Fully operational |
+---------+-------------------------------------+----------+--------------+----------------+----------------------+--------+-------------------+

ブロックカスタムストレージボリュームのエクスポート ¶

ファイルシステムの場合と同様に、lxc storage volume export を使って、ブロックカスタムストレージボリュームをエクスポートできるようになりました。

しかし、ブロックカスタムストレージボリュームはファイルシステムのボリュームよりもかなり大きくなる傾向があります。ですので、エクスポートとインポートにはかなりのリソースが必要になることに注意してください。

すべての変更点（翻訳なし） ¶

Here is a complete list of all changes in this release:

試用環境 ¶

この新しい LXD リリースは私たちの デモサービス で利用できます。

ダウンロード ¶

このリリースの tarball は ダウンロードページ から取得できます。

ビルド済みバイナリーは次のように使えます:

• Linux: snap install lxd
• MacOS: brew install lxc
• Windows: choco install lxc

LXD 4.18 リリースのお知らせ¶

3rd of September 2021

はじめに ¶

LXD チームは LXD 4.18 のリリースをお知らせできることにとてもワクワクしています!

今回のリリースは忙しいリリースで、多くの主要な新機能の追加や、さまざまな機能強化、修正が行われています。

Enjoy!

新機能とハイライト ¶

Go モジュールへの移行 ¶

LXD は完全に Go モジュールの使用へと移行しました。この変更はユーザーにはまったく見えないはずです。しかし、Go クライアントパッケージをインポートしたり、LXD のリリースをパッケージングする場合には影響があります。

この変更のために Makefile が更新され、期待通りに動作するはずです。リリース tarball で dist ディレクトリが廃止され、Go がネイティブにサポートする標準的な vendor ディレクトリに置き換えられました。

ネットワーク転送（フローティングIP） ¶

ブリッジと OVN の管理ネットワークでネットワーク転送がサポートされました。

この機能により、ネットワーク自身のサブネットや、（プロジェクトで制限されている場合）プロジェクト内で許可されている外部サブネットからいくつかアドレスを割り当て、ネットワーク内部の任意のアドレスに転送できます。

さらに、ネットワーク転送を使うと、プロトコルとポートをベースに、ひとつのアドレスを複数の内部アドレスに転送できます。

stgraber@dakara:~$ lxc list u1
+------+---------+-----------------------+--------------------------------------------+-----------+-----------+
| NAME |  STATE  |         IPV4          |                    IPV6                    |   TYPE    | SNAPSHOTS |
+------+---------+-----------------------+--------------------------------------------+-----------+-----------+
| u1   | RUNNING | 172.17.250.244 (eth0) | 2602:fc62:b:250:71c2:a0d8:4a72:e17a (eth0) | CONTAINER | 0         |
+------+---------+-----------------------+--------------------------------------------+-----------+-----------+
stgraber@dakara:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 170.39.196.149 icmp_seq=1 Destination Net Unreachable
--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

stgraber@dakara:~$ lxc network forward create lxdbr0 192.168.1.1 target_address=172.17.250.244
Network forward 192.168.1.1 created
stgraber@dakara:~$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.110 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.049 ms
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1027ms
rtt min/avg/max/mdev = 0.049/0.079/0.110/0.030 ms

stgraber@dakara:~$ nc -v 192.168.1.1 3389
nc: connect to 192.168.1.1 port 3389 (tcp) failed: Connection refused
stgraber@dakara:~$ lxc list win11
+-------+---------+-----------------------+--------------------------------------------+-----------------+-----------+
| NAME  |  STATE  |         IPV4          |                    IPV6                    |      TYPE       | SNAPSHOTS |
+-------+---------+-----------------------+--------------------------------------------+-----------------+-----------+
| win11 | RUNNING | 172.17.250.173 (eth0) | 2602:fc62:b:250:a7ad:46a9:82b6:50db (eth0) | VIRTUAL-MACHINE | 1         |
+-------+---------+-----------------------+--------------------------------------------+-----------------+-----------+
stgraber@dakara:~$ lxc network forward port add lxdbr0 192.168.1.1 tcp 3389 172.17.250.173
stgraber@dakara:~$ nc -v 192.168.1.1 3389
Connection to 192.168.1.1 3389 port [tcp/ms-wbt-server] succeeded!
stgraber@dakara:~$ lxc network forward show lxdbr0 192.168.1.1
description: ""
config:
  target_address: 172.17.250.244
ports:
- description: ""
  protocol: tcp
  listen_port: "3389"
  target_port: ""
  target_address: 172.17.250.173
listen_address: 192.168.1.1
location: none

この例では、外部アドレス（192.168.1.1）を転送アドレスとしてローカルブリッジネットワーク（lxdbr0）に追加し、すべてのトラフィックを u1 に流れるように設定しています。その後、3389 番ポートは win11 に送るように再設定しています。

仕様 : https://discuss.linuxcontainers.org/t/lxd-floating-ip-addresses/11801
ドキュメント : https://linuxcontainers.org/lxd/docs/master/network-forwards

ネイティブ BGP サポート ¶

LXD はたくさんのネットワーク設定をサポートしています。それらのいくつかは、インスタンスが直接パブリックアドレスを取得するために使えます。

このようなシナリオでは、個々のアドレスやサブネットを正しい LXD サーバーにルーティングし、サーバーはインスタンスへトラフィックを転送する必要があるでしょう。

これは、ルーターにスタティックなルーティングエントリーを設定して手動で行えます。しかし、多数のエントリーを扱う場合、これは非常にわずらわしく、エラーが発生しやすくなります。

ここでダイナミックルーティングと BGP の登場です。BGP をサポートすることで、LXD は関連する上流のルーターに直接接続でき、その後使用するすべての外部アドレスとサブネットのアナウンスを開始します。

これは一連の新しい設定オプションを使って設定します。
サーバーの設定レベルでは、これらは次の設定です。

• core.bgp_address
• core.bgp_asn
• core.bgp_routerid

ネットワークレベルでは、次の設定です（ブリッジもしくは OVN アップリンクネットワーク）。

• bgp.peers.NAME.address
• bgp.peers.NAME.asn
• bgp.peers.NAME.password (optional)
• bgp.ipv4.nexthop (optional, bridge only)
• bgp.ipv6.nexthop (optional, bridge only)

これにより、LXD はピアリングセッションを確立し、すべての外部（非NAT）IPv4 と IPv6 アドレスとサブネットを広告しはじめます!

fw-wan01# show bgp summary·
IPv4 Unicast Summary:
BGP router identifier 45.45.148.250, local AS number 399760 vrf-id 0
BGP table version 200
RIB entries 39, using 7488 bytes of memory
Peers 4, using 85 KiB of memory
Peer groups 4, using 256 bytes of memory

Neighbor                             V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
45.45.148.251                        4     399760     19844     19843        0    0    0 4d22h57m            1        4
45.45.148.252                        4     399760     19850     19849        0    0    0 5d19h19m            1        4
45.45.148.254                        4      64600     19838     19838        0    0    0 01w6d18h            2        0
2602:fc62:b:1000:5436:5b25:64e4:d81a 4     399760     39020     38840        0    0    0 00:15:09            3        0

Total number of neighbors 4

IPv6 Unicast Summary:
BGP router identifier 45.45.148.250, local AS number 399760 vrf-id 0
BGP table version 197
RIB entries 47, using 9024 bytes of memory
Peers 4, using 85 KiB of memory
Peer groups 4, using 256 bytes of memory

Neighbor                             V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt
2602:fc62:b:101::251                 4     399760     19844     19843        0    0    0 4d22h56m            1        3
2602:fc62:b:101::252                 4     399760     19850     19849        0    0    0 5d19h19m            1        3
2602:fc62:b:101::254                 4      64600     19838     19839        0    0    0 01w6d18h            1        3
2602:fc62:b:1000:5436:5b25:64e4:d81a 4     399760     39020     38840        0    0    0 00:15:09            3        0

Total number of neighbors 4

これは 2602:fc62:b:1000:5436:5b25:64e4:d81a が LXD サーバーである場合の、私の BGP ルーターのひとつからのビューです。見てわかるように、3 つの IPv4 と IPv6 プレフィックスを BGP でアナウンスしています。

仕様 : https://discuss.linuxcontainers.org/t/lxd-bgp-address-route-advertisement/11567
ドキュメント : https://linuxcontainers.org/lxd/docs/master/networks#bgp-integration

OVN での NAT アドレスのカスタマイズ ¶

ovn タイプのネットワークで、IPv4.nat.address と ipv6.nat.address の両方がサポートされるようになりました。

これは、NAT が有効な場合、OVN で設定されたアドレスを、外向きの IPv4 と IPv6 のトラフィックのソースとして使用する場合に期待通りに動作します。

クラスターのディザスターリカバリーのための lxd cluster edit コマンド ¶

LXD クラスターを、高可用クラスターで操作するには、3 データーベースサーバー、2 クォーラムから構成されるクォーラムが必要です。これにより、サーバーがひとつ失われても、API とデータベース全体が維持できます。

もし、2 台のマシンがリカバリー不能なダメージを受けて復帰できなかった場合、LXD はクォーラムに到達できないために起動を拒否します。この場合、既存の lxd cluster recovery-from-quorum-loss コマンドにより、他のサーバーを除去するためにデータベースの設定を書き換えることで対処できます。

しかし、8 台からなるクラスターで、3 台がデータベースサーバー、2 台がスタンバイのデータベースサーバー、他の 3 台がシンプルなクライアントであるような、はるかに複雑なケースも考えられます。

同時に 2 台のデータベースサーバーが消滅した場合、LXD は機能しません。しかしこのような環境では、すべての他のサーバーを削除し、ひとつを残して、そこから回復させるようなことは望めません。

このようなシナリオでは、新しく追加された lxd cluster edit と lxd cluster show が役立ちます。これらのコマンドで、各サーバー上の内部的なクラスター設定を見て編集できます。これらを使って、手動でロールを再度シャッフルしたり、ネットワークアドレスを更新したりできます。クラスター内の全サーバーで変更が済むと、LXD を再び起動できます。

ドキュメント : https://linuxcontainers.org/lxd/docs/master/clustering#recover-cluster-members-with-changed-addresses

カスタムボリュームでの Refresh のサポート ¶

lxc storage volume copy コマンドで、lxc copy と同様に --refresh オプションが使えるようになりました。

これにより、足りないスナップショットを転送したり、現在のボリュームの状態を転送したりできます。そして、ボリュームの最新のバックアップを別のプールや別のサーバーに保持するために使えます。

プロジェクトでのデバイス制限の追加 ¶

プロジェクトに対する制限が更新され、これまで使えなかったデバイスタイプが 2 つ追加されました。

新しい設定オプションは次の通りです:

• restricted.devices.pci
• restricted.devices.proxy

両方とも、信頼できないユーザーにとっては安全ではないと考えられますので、デフォルト値は block です。

ドキュメント : https://linuxcontainers.org/lxd/docs/master/projects

lxd init の --minimal オプション ¶

lxd init に新たに --minimal オプションが追加されました。

これは、実際は lxd init --auto と同じですが、より正確な名前で追加の設定パラメーターを許可しないコマンドになっています。

これを使うと、default という名前の dir ストレージプールと、lxdbr0 という名前の bridge タイプのネットワークを使って動作する LXD サーバーになります。

インスタンスの状態へいくつかネットワークカウンターを追加 ¶

メトリクス（prometheus）エンドポイントの作業に備えて、インスタンス上のネットワークカウンターを少し拡張し、ドロップしたパケットとエラーの両方を含めるようにしました。

stgraber@dakara:~$ lxc query /1.0/instances/u1/state | jq .network.eth0.counters
{
  "bytes_received": 100946,
  "bytes_sent": 3404,
  "errors_received": 0,
  "errors_sent": 0,
  "packets_dropped_inbound": 0,
  "packets_dropped_outbound": 0,
  "packets_received": 467,
  "packets_sent": 32
}

すべての変更点（翻訳なし） ¶

このリリースでの完全な変更点のリストは次の通りです:

試用環境 ¶

この新しい LXD リリースは私たちの デモサービス で利用できます。

ダウンロード ¶

このリリースの tarball は ダウンロードページ から取得できます。

ビルド済みバイナリーは次のように使えます:

• Linux: snap install lxd
• MacOS: brew install lxc
• Windows: choco install lxc

Older news¶

• 6th of August 2021
• 17th of July 2021
• 9th of July 2021
• 14th of June 2021
• 4th of June 2021
• 7th of May 2021
• 6th of May 2021
• 10th of April 2021
• 5th of March 2021
• 5th of February 2021
• 2nd of February 2021
• 8th of January 2021
• 11th of December 2020
• 12th of November 2020
• 22nd of October 2020
• 16th of October 2020
• 18th of September 2020
• 29th of August 2020
• 14th of August 2020
• 12th of August 2020
• 31st of July 2020
• 1st of July 2020
• 25th of June 2020
• 5th of June 2020
• 8th of May 2020
• 21st of April 2020
• 31st of March 2020
• 20th of March 2020
• 6th of March 2020
• 13th of February 2020
• 30th of January 2020
• 16th of January 2020
• 2nd of October 2019
• 6th of September 2019
• 9th of August 2019
• 11th of July 2019
• 21st of June 2019
• 17th of June 2019
• 9th of May 2019
• 5th of April 2019
• 6th of March 2019
• 7th of February 2019
• 8th of January 2019
• 12th of December 2018
• 22nd of November 2018
• 9th of November 2018
• 11th of October 2018
• 11th of September 2018
• 21st of August 2018
• 14th of August 2018
• 27th of July 2018
• 22nd of June 2018
• 5th of June 2018
• 15th of May 2018
• 2nd of April 2018
• 20th of December 2017
• 15th of November 2017
• 19th of October 2017
• 17th of October 2017
• 19th of September 2017
• 22nd of August 2017
• 25th of July 2017
• 27th of June 2017
• 30th of May 2017
• 11th of May 2017
• 25th of April 2017
• 20th of March 2017
• 8th of March 2017
• 2nd of March 2017
• 28th of February 2017
• 24th of February 2017
• 20th of February 2017
• 16th of February 2017
• 15th of February 2017
• 26th of January 2017
• 24th of January 2017
• 20th of December 2016
• 24th of November 2016
• 24th of November 2016
• 24th of November 2016
• 24th of November 2016
• 23rd of November 2016
• 22nd of November 2016
• 25th of October 2016
• 5th of October 2016
• 5th of October 2016
• 4th of October 2016
• 27th of September 2016
• 14th of September 2016
• 16th of August 2016
• 15th of August 2016
• 28th of June 2016
• 30th of May 2016
• 16th of May 2016
• 11th of April 2016
• 6th of April 2016
• 31st of March 2016
• 28th of March 2016
• 23rd of March 2016
• 21st of March 2016
• 16th of March 2016
• 11th of March 2016
• 7th of March 2016
• 2nd of March 2016
• 23rd of February 2016
• 18th of February 2016
• 10th of February 2016
• 26th of January 2016
• 19th of January 2016
• 4th of January 2016
• 21st of December 2015
• 8th of December 2015
• 24th of November 2015
• 10th of November 2015
• 27th of October 2015
• 14th of October 2015
• 25th of September 2015
• 15th of September 2015
• 1st of September 2015
• 18th of August 2015
• 4th of August 2015
• 21st of July 2015
• 7th of July 2015
• 23rd of June 2015
• 9th of June 2015
• 26th of May 2015
• 12th of May 2015
• 29th of April 2015
• 28th of April 2015
• 14th of April 2015
• 7th of April 2015
• 24th of March 2015
• 17th of March 2015
• 10th of March 2015
• 27th of February 2015
• 13th of February 2015