Mon, Dec 07, 2020
Proxmox VE 6.3 が出ています
仮想環境プラットフォームとしてとても便利なProxmox VEですが、バージョン6.3が出ています。
変更点は https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.3 にありますが、順当に少しずつ機能が強化されてるという所でしょうか。あと今回は、Proxmox Backup Server との統合機能がメインかな。
地味にモダンなインタフェースになっているところもあります。例えば、今までプルダウンメニューで選択していたブート順の指定が、GUIのドラッグ&度ラップで出来るようになっていたりします。
日本語訳については最新版が反映されていないようです(画面ではテスト環境なので最新版になってますが、まだバグがありますね)。
そのほか、クラスタ回りとかストレージ回りで少しずつ改良がされているようです。ただ、openSUSE をゲストOSにしてテストするような場合にはあまり影響はないようです。
Sun, Dec 06, 2020
Kubernetesのメモリ使用量を測ってみる
某LUGで、Kubernetesのメモリ使用量を気にされていたので、測ってみました。
結論
masterノードはKubernetes起動後、1.3G前後のメモリを使用。workerは、コンテナを動かせば動かしただけメモリを使用。15pod程度では、2つのworkerでそれぞれ1G使わない程度でした。
方針
KVM上にKubicを展開して、そこでKubernetesを動かします。
VMの起動のみの状態、Kubernetesを起動した状態、いくつかのpodを動かした状態、で、freeや、topのメモリ使用量上位10のプロセスを拾ってみます。
また、Kubernetes起動後はcrictl statsの結果も見てみます。今回、IDを名前で置き換えていますのでご注意下さい。(通常のcrictl statsですと、IDのみの表示となり名前は表示されません。)
環境
- Kubernetes
- master 1 worker 2 構成
- KVM上で動かす
- OSはKubic
- CPU数 master 2 worker 1
- メモリ それぞれ 3G
- Kubernetes 1.19.4
- ホスト
- openSUSE 15.2
- CPU Ryzen 3900
- メモリ 32G
Kubic・・・openSUSEプロジェクトで開発している、Kubernetes専用OSです。Tumbleweedをベースにしていて、Kubernetesを動かすことに焦点を絞ったパッケージ構成&システム設定。プリビルドなイメージが毎日のように公開されるため、ignitionなどの初期設定ツールを使って手早く最新Kubernetesを展開できます。
Ryzen 3900・・・コア数12なので、VMは結構たてられます。目指せおうちクラウド。
ちなみに、saltstackのマスター用VMを別途立てていて、各ゲストは基本的にそこから制御しています。(今回のコマンド実行は直接各ゲストで行いました。)
VMの起動のみ
master
worker1
worker2
利用可能メモリが、3台とも2.5G程度であることがわかります。
Kubernetes起動後
Kubernetesとネットワークアドオンのweaveを起動します。
master
worker1
worker2
masterがさらに1G程使用しました。workerは数百程度の使用にとどまっています。
podを幾つか起動した後
15個程podを走らせてみます。
走らせたサービスは、Promeheus、Grafana、DokuWiki、Nextcloud、Harborなどです。
master
worker1
worker2
masterの使用量はほとんどかわりませんが、動いたpod分、両workerのメモリが使用された感じです。
参考までに、pod一覧です。
感想
色々と検証しているときは、clairが1G以上メモリを使ったりしていましたが、今回計測しているときは100Mいかないぐらいでした。当然ですが、podの起動だけでなく、実際に使ってみた時のメモリ使用量なんかが実運用上では参照値になると思います。
まだ、プロセスやコンテナの動作と使用メモリとの関連を掴みきれてないので、追って調査してみたいと思います。コンテナのメモリとディスクの関連も。
なお、今回動かしたサービスの殆どはiscsiのPersistentVolumeに接続しています。このあたりの方法も消費リソースと関わっていそうですね。
Kubernetesってメモリ使うんだよなー、よし、各ノードに6G割り当てるか、とかやっていたのですが、今回の計測で今の所3Gでも大丈夫なことがわかったので、設定を変更しました。やはり適切な設定は適切な計測から、ですね。ちなみに、Kubernetesでpodを動かす時に、CPU使用率やメモリ使用量の上限などを設定できます。このあたりについてもおいおい見ていきたいと思います。
Open Developers Conference に参加します
この記事は openSUSE Advent Calendar の6日目です。今日時点でまだ半分残っているので、みなさん参加してくださいね!
12月19日(土)に OSC でおなじみの OSPN 主催で開発者向けイベント Open Developers Conference 2020 Online が開催されます。今回は openSUSE としてではなく Cross Distro Developers Camp として出展します。
https://event.ospn.jp/ODC2020-Online/
14時からのセミナーでは「Linuxディストリビューション大集合 〜あなたのLinuxディストリビューションを見つけてみよう〜」と題し、「ディストリビューション」についての説明の後、各ディストリビューションの関係者からそれぞれのディストリビューションの特徴について紹介する予定です。openSUSE については私が担当し、Debian、Solus についての発表も聞けます。
セミナーの後、15時15分からの枠では、パネルディスカッション形式でディストリビューションの開発について話す予定です。パネリストの体験談と会場からの質問をもとに、ディストリビューションの開発に参加してみようかなと思ってもらえるような情報を提供できればと思っています。
Fri, Dec 04, 2020
TIPS: zypper でローカルにインストールされたパッケージ一覧を表示する
2020-12-08 コマンドの引数にコメントをいただき、一部修正しました。
openSUSE でインストール済みのパッケージ一覧を表示するときには、 rpm -qa コマンドを使っていました。しかし、Proxmox VE で使うコンテナイメージには rpm コマンドが含まれていませんでした。もちろんzypper コマンドで rpmコマンドを入れれば良いのですが、zypper コマンドだけで出来る方法がないか考えてみました。結果、
zypper –no-refresh se -i -t package
で代用することが出来ることが分かりました。結果はこんな感じになります。リモートリポジトリの検索を全部やめてしまえばローカルだけになる、と言う仕掛けです。
S | Name | Summary | Type
—+———————————–+————————————————————————–+——–
i+ | aaa_base | openSUSE Base Package | package
i+ | apache2 | The Apache Web Server | package
i+ | apache2-example-pages | Example Pages for the Apache 2 Web Server | package
i | apache2-prefork | Apache 2 “prefork” MPM (Multi-Processing Module) | package
i | apache2-utils | Apache 2 utilities | package
i+ | apparmor-abstractions | AppArmor abstractions and directory structure | package
i+ | apparmor-parser | AppArmor userlevel parser utility | package
i | augeas | An utility for changing configuration files | package
i | augeas-lenses | Official set of lenses for use by libaugeas0 | package
i | bash | The GNU Bourne-Again Shell | package
Thu, Dec 03, 2020
Proxmox VE のCTでXは動くのか
結論から先に書きます。Proxmox VEのLXC コンテナでX をぅこかすことは出来ませんでした。
コンソールとしてSPICEクライアントやxterm.js も指定できるので、出来るかなと思ったのですが、そうは問屋が卸しませんでした。
Xはインストール出来ます。しかし、xinit で起動してみると、 /dev/tty0 がないと言ってきて起動しません。確かに、/dev/ 配下を見ると、
ls -l
total 0
crw–w—- 1 root tty 136, 0 Nov 20 10:10 console
lrwxrwxrwx 1 root root 11 Nov 20 10:03 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Nov 20 10:03 fd -> /proc/self/fd
crw-rw-rw- 1 nobody nobody 1, 7 Nov 11 08:28 full
lrwxrwxrwx 1 root root 25 Nov 20 10:03 initctl -> /run/systemd/initctl/fifo
lrwxrwxrwx 1 root root 28 Nov 20 10:03 log -> /run/systemd/journal/dev-log
drwxrwxrwt 2 nobody nobody 40 Nov 20 10:03 mqueue
crw-rw-rw- 1 nobody nobody 1, 3 Nov 11 08:28 null
crw-rw-rw- 1 root root 5, 2 Nov 20 2020 ptmx
drwxr-xr-x 2 root root 0 Nov 20 10:03 pts
crw-rw-rw- 1 nobody nobody 1, 8 Nov 11 08:28 random
drwxrwxrwt 2 root root 40 Nov 20 10:03 shm
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Nov 20 10:03 stdout -> /proc/self/fd/1
crw-rw-rw- 1 nobody nobody 5, 0 Nov 15 23:26 tty
crw–w—- 1 root tty 136, 0 Nov 20 10:03 tty1
crw–w—- 1 root tty 136, 1 Nov 20 10:03 tty2
crw-rw-rw- 1 nobody nobody 1, 9 Nov 11 08:28 urandom
crw-rw-rw- 1 nobody nobody 1, 5 Nov 11 08:28 zero
となっていて、/dev/tty0 がありません。そこで以下を試してみました。
- /dev/console を /dev/tty0 に ln しようとしたのですが、
Invalid cross-device link エラーで駄目 - ln -s でやってみたのですが、xinit を動かしたときに
parse_vt_settings: Cannot find a free VT: Inappropriate ioctl for device
エラーで駄目 - mknod tty0 c 136 0 でデバイスファイルを作ろうとしたのですが、
operation not permitted
エラーで駄目
でした。これで行き止まり。
ちなみに、他のディストリビューションも見てみましたが、結果は同じ。そもそも tty0 がないところから同じでした。
というわけで、残念ながらコンテナ内でXを動かすのには失敗しました。
Wed, Dec 02, 2020
Proxmox VEのLXCでopenSUSEを使う
手軽な仮想化環境 Proxmox-VE は、LXC を使ったコンテナ環境も用意されています。コンテナ環境では、kernel は 仮想化環境のベースOSのものを使いますが、ユーザランドはopenSUSE のものが使われます。この記事を書いている時点で openSUSE 15.2 相当のコンテナ環境があったので使ってみることにしました。
openSUSE 15.2 のコンテナ環境は、Proxmox VE 標準で用意されていますので、それをWebインタフェースから選択するだけでダウンロード、インストールができます。
インストール完了後は、パッケージの総数は181個でした。見てみましたが、最低限の動作をするために必要なものだけしかない状態です。ssh,sshもないですし、yastも入っていませんでした。ほとんど何も出来ないと行っていいでしょう。/ ディレクトリも 213M しか使っていませんでした。必要最低限のユーザランドを一気に入れてしまうFreeBSDよりまさらにコンパクトです。さすがにzypper は入っていましたので、パッケージの追加は出来ます。
そこで、まずは zypper update を行ったのち、openssh を入れ、さらに yast (パッケージとしてはyast2) を入れてみました。
yast を入れた直後の画面は図1のようになります。
何もないですね。この時点では、yast2-ycp-ui-bindings, yast2-perl-bindings,yast2,yast2-core,yast2-xml,yast2-logs,yast2-ruby-bindings,yast2-hardware-detection,yast2-pkg-binding というものしか入っていません。 yast のサブメニューに対応するパッケージを何も入れていないため、何もないわけです。
そこで、他のサーバを参考にしつつ、yast パッケージを入れてみることにしました。取りあえずはSamba サーバにしたいため、yast2-samba-server を入れることにしました。すると、yast2-samba-client を含め、関連するパッケージが42個も入りました。
続いてSamba本体のパッケージ Samba を入れます。ここでも40パッケージが追加されました。
さて、Sambaをyast で設定するためには少し準備が必要です。useradd でユーザの追加、共有ディレクトリの準備とアクセス権の設定をします。また、pdbedit でSamba用ユーザの登録をします。その後に yast で Sambaの設定をします。しかし、起動すると、図2のように cups を無効にするかどうかを聞いてきます。
今はSamba経由で印刷することはほぼ皆無なので、最初から無効にしておいてもいいんじゃないかと思うのですけどね。
さて、一通り設定が終わり、Sambaを起動しようとしたのですが、smbdがなぜか起動しません。ログを見ると、
ERROR: failed to setup guest info.
と言うエラーが出ていました。これはSambaが使うゲストユーザの定義がないということでした。調べて見ると、普通OSをインストールしたときには、nobody というユーザが作られているのですが、このLXC環境では入っていなかったのでした。そこで、uid 65534,gid 65533 の nobody を作りました。これでsmbの起動はOKとなりました。
Mon, Nov 30, 2020
ファイルサーバーで Spotify を再生する
openSUSE Advent Calendar 2020 が始まりました。今年も完走できるのか!?まだ空きがありますので、みなさんご協力お願いします。
みなさん、Spotify を使っていますか? Spotify は定額サブスクリプションで音楽をストリーミングで聴けるサービスです。再生クライアントはデスクトップ、モバイル各種プラットフォームに対応しており、さらに Linux 用の公式クライアントもあります。
これまで音楽を再生するときは、PC から再生するか、PCの電源が切れているときは、スマホとオーディオアンプ(AI-301DA)を Bluetooth で接続して再生していました。ただ、スマホからの再生は電池を消費するのがちょっと難点です。
ということで、常時電源が点いているファイルサーバー(もちろん OS は openSUSE)から Spotify を再生できるようにしてみました。Spotify の公式クライアントにはちょっと便利な機能があり、自身のアカウントでログインした、他のデバイスの Spotify クライアントを使ってリモートで再生することができます(Spotify Connect)。スマホの Spotify クライアントを使って、PC や Amazon Echo から再生するというのがおそらく一般的な使い方です。
ファイルサーバーにはディスプレイが接続されておらず、デスクトップ環境も動いていませんので、公式の Spotify クライアントではなく、今回は Spotifyd という OSS の非公式クライアントを使用してみました。その名の通り、デーモンとしてバックグラウンドで動作するクライアントです。
ビルド・インストール
誰かが作ったパッケージがあるにはあるのですが、今回はソースからビルドしてインストールしました。master ブランチではなく、リリース版の 0.2.24 を使います。設定ファイルのフォーマットが違う(master では TOML 形式になっている)ので、ドキュメントのバージョンには気をつけて下さい。
https://github.com/Spotifyd/spotifyd/releases/tag/v0.2.24
Rust は openSUSE Leap 15.2 で提供されているものが使えました。
$ sudo zypper in cargo alsa-devel make gcc
ドキュメントに従ってビルドします。
cargo build --release
ビルド結果は target/release/spotifyd
にありますので、これをファイルサーバーの /opt/spotifyd/bin
あたりに転送します。
設定
/etc/spotifyd.conf を作成します。設定例は README.md に書いてあるとおりです。 https://github.com/Spotifyd/spotifyd/blob/v0.2.24/README.md
- password: Spotify の管理画面でデバイス用のパスワードを発行しておく
- device: 書いてあるとおり
aplay -L
で使いたい出力のデバイス名を調べて下さい - cache_path: /var/cache/spotifyd あたりに設定しておきましょう
自動起動に使用する service ファイル(/etc/systemd/system/spotifyd.service
)はこんな感じです。ソースコードの contrib ディレクトリ内の例からは少し変えてあります。まず、User
は spotifyd ユーザーを作成して root から落としてあります。RestartSec
は、spotifyd がときどき落ちていることがあったので、起動ループになると嫌だなと思い、長めに設定してみました。
[Unit] Description=A spotify playing daemon Documentation=https://github.com/Spotifyd/spotifyd<br>Wants=sound.target After=sound.target Wants=network-online.target<br>After=network-online.target [Service] ExecStart=/opt/spotifyd/bin/spotifyd --no-daemon Restart=always RestartSec=300 User=spotifyd Group=nobody Type=simple [Install] WantedBy=default.target
あとは spotifyd を起動して、クライアントからデバイスに接続できるかを試してみて下さい。
$ systemctl enable spotifyd<br>$ systemctl start spotifyd
Tue, Sep 29, 2020
Singularity + openSUSEでコンテナ管理
当ブログではお久しぶりです。鹿野と申します。
あ〜、同じ苗字の人が多いのでそれで(汗)
今回はSingularityを使用して、コンテナ運用する方法を紹介します!
Singularityって何か?
一言で言うと、Dockerみたいなコンテナフレームワークです。
下記のような特徴を持っています。
・ 主に一般ユーザーで使用することを想定(故にGPUとも相性抜群!)
・ Dockerイメージをそのまま使用可能(DockerHUB……もちろん使えます)
……のため、主にスパコンで使用されることが多いようです。
(私も仕事でそっち方面の調査していく中でたどり着いた次第だったり)
openSUSEとSingularityは相性抜群!??
openSUSE 15.2ではSingularityは公式パッケージが用意されています。
ワンクリックインストールも可能ということですね!
https://software.opensuse.org/package/singularity
zypperでももちろんインストール可能です。
zypper install singularity
実は、公式パッケージが用意されてるのは現時点でかなり稀のディストリのようです。RHELやCentOSではRPMファイルが公開されているのみですし、DebianやUbuntuに至っては自分でコンパイルする必要があったり。
openSUSEがDeepLearningに力を入れてる!
……と数日前まで本気で疑ってましたが、どうやら間違えではなさそう???
PyTorch with CUDAを動かしてみよう!
openSUSE 15.2 で Singularityインストール後は下記のおまじないが必要です。
usermod -a -G singularity (Singularityを動かすユーザ名)
openSUSEのSingularity READMEにも書いてありますが、要するにsingularityのグループに実行するユーザを追加してあげる必要があります。(これするならDockerと変わらない気もしなくもないですが……まぁGPUをコンテナ内で動かすという点では一般ユーザ権限で動かせるのは利点なのかな……?)
あとは下記のコマンドで、Singularity用コンテナイメージをビルドすると、コンテナ内でPyTorch + CUDA で動かすことができます。
singularity build pytorch.sif docker://pytorch/pytorch:latest singularity shell --nv pytorch.sif
たったこれだけですね!
NVIDIA-Dockerのような煩わしさがなく、非常にシンプルだと思います。
singularity shellコマンドに –nv オプションをつけてあげるとコンテナ内でGPUが使用できます。NVIDIAのGPUを使用するには事前にNVIDIAのドライバなども必要ですが、それについては下記のURLから。
https://opensuse-community.org/
まとめ
いかがでしたでしょうか。
簡単にopenSUSE + Singularityを使用して、コンテナ内でGPU(PyTorch)を使用する方法を紹介しました。
openSUSE 15.2でAI開発がしやすくなった!?という触れ込みは、どうやら嘘ではなかったのかも??←筆者がそもそも半信半疑だったとか(汗)
Sun, Aug 30, 2020
OSC 2020 online/kyoto
今年のOSCは感染症の影響ですべてオンラインになりました。京都開催のOSCもZoom+Youtube配信。openSUSEのセッションは、2020/08/28 に
「あつまれ!openSUSEユーザーの森」というタイトルで、LTに近い感じで数人がどのようにopenSUSEを使っているかを紹介するという内容でした。
おもしろかったのは、タスクバーをどこに置くか、と言う事が人それぞれだったということです。システムで決まっている位置はあるのですが、使い勝手とかを考慮して、上だったり右だったり左だったり。
自分はリモート接続で繋いだとき、実画面よりも仮想画面の縦方向が長いと、タスクバーが下にあると操作ができなくなってしまうため、常時上にしています。いわゆるMac風ですね。ただ、Windowsだと、メッセージの一部(通知)が右端にしか表示されないため、右に寄せている、という話も出ました。それはそれでしょうが無いと納得でした。
Sun, Apr 26, 2020
openSUSE Leap で iSCSI Target のセットアップ
最近、電源が壊れたPCを1台リプレースし、余ったマザーボード、CPU、メモリーでファイルサーバーを構築しました。その際にデータをファイルサーバーに移し、デスクトップ PC の HDD を外してしまったので、仮想マシン用の VM の仮想ディスクイメージもファイルサーバーに移す必要がありました。しかし、Hyper-V のディスクイメージは Samba サーバーに置くことができないようなので、仮想マシンのディスクイメージを iSCSI で Hyper-V に接続するようにしてみました。
今日は openSUSE Leap 15.2 (beta) で iSCSI Target(サーバー)のセットアップ方法を紹介します。今回設定する構成はディスクイメージを iSCSI で公開するファイルサーバーと、ファイルサーバーと同じネットワークにあり、そのディスクイメージを使用する Windows 10 のデスクトップ PC からなる単純なものです。
必要なパッケージは targetcli をインストールすれば揃います。YaST でも設定できるのですが、設定できる項目が少ないようなので、targetcli を使って設定します。
$ sudo zypper in targetcli
それでは targetcli を起動して設定していきます。
$ sudo targetcli
まずはディスクイメージファイルを作成します。targetcli の中で /backstores/fileio に移動して、create コマンドでディスクイメージを作成できますここでは /var/storage/disk1.img に 10 GB のディスクイメージ作成します。 /var/storage ディレクトリは先に作成しておく必要があります。
ls コマンドで disk1 が作成されたことが確認できます。
/> cd backstores/fileio /backstores/fileio> create file_or_dev=/var/storage/disk1.img name=disk1 size=10G Created fileio disk1 with size 10737418240 /backstores/fileio> ls o- fileio ............................................................. [Storage Objects: 1] o- disk1 ....................... [/var/storage/disk1.img (10.0GiB) write-back deactivated] o- alua ............................................................... [ALUA Groups: 1] o- default_tg_pt_gp ................................... [ALUA state: Active/optimized]
次に /iscsi で create コマンドを実行し、iSCSI の target を作成します。create の IQN 形式の ID を省略すると勝手に作成してくれます。
/backstores/fileio> cd /iscsi /iscsi> create Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a. Created TPG 1. Global pref auto_add_default_portal=true Created default portal listening on all IPs (0.0.0.0), port 3260. /iscsi> ls o- iscsi ...................................................................... [Targets: 1] o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a ................ [TPGs: 1] o- tpg1 ......................................................... [no-gen-acls, no-auth] o- acls .................................................................... [ACLs: 0] o- luns .................................................................... [LUNs: 0] o- portals .............................................................. [Portals: 1] o- 0.0.0.0:3260 ............................................................... [OK]
この target で公開するディスク (lun0) を作成し、最初に作成したディスクイメージ(/backstores/fileio/disk1)を割り当てます。
/iscsi> cd iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a/tpg1/luns /iscsi/iqn.20...21a/tpg1/luns> create storage_object=/backstores/fileio/disk1 Created LUN 0. /iscsi/iqn.20...21a/tpg1/luns> ls o- luns .......................................................................... [LUNs: 1] o- lun0 ....................... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)]
最後に、この taget にはデスクトップPC からしかアクセスできないようにします。ここではデスクトップPCのID(Windows の iSCSI イニシエーターに設定するもの)を iqn.2020-04.example.com:desktop-pc とします。tpg1/acls 内でイニシエーター名を指定し、create コマンドを実行します。さらに、ユーザーIDとパスワードを設定し、事実上誰からもアクセスできる状態にならないようにします。
/iscsi/iqn.20...21a/tpg1/luns> cd ../acls /iscsi/iqn.20...21a/tpg1/acls> create iqn.2020-04.example.com:desktop-pc Created Node ACL for iqn.2020-04.example.com:desktop-pc Created mapped LUN 0. /iscsi/iqn.20...21a/tpg1/acls> cd iqn.2020-04.example.com:desktop-pc/ /iscsi/iqn.20...om:desktop-pc> set auth userid=testuser Parameter userid is now 'testuser'. /iscsi/iqn.20...om:desktop-pc> set auth password=testpassword1234 Parameter password is now 'testpassword1234'. /iscsi/iqn.20...om:desktop-pc> ls o- iqn.2020-04.example.com:desktop-pc ..................................... [Mapped LUNs: 1] o- mapped_lun0 .................................................. [lun0 fileio/disk1 (rw)]
この段階で mapped_lun0 が作成され、iqn.2020-04.example.com:desktop-pc に mapped_lun0 が作成されます。Leap 15.1 で試したときは、この mapped_lun0 が自動的に作成されず、Windows の iSCSI イニシエーターから接続してもディスクが何も表示されない状態になってしまいました。このような場合は、次のコマンドで mapped_lun を作成することができます。
create mapped_lun=0 tpg_lun_or_backstore=lun0
これまでの設定は以下の通りです。この状態で Windows の iSCSI イニシエーターでファイルサーバーに接続すると、ディスクの管理で iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a の lun0 (/backstores/fileio/disk1, /var/storage/disk1.img) がディスクとして見えるようになります。あとは Hyper-V でこのディスクを割り当てれば仮想マシンのディスクとして使用することができます。
/> ls / o- / ................................................................................. [...] o- backstores ...................................................................... [...] | o- block .......................................................... [Storage Objects: 0] | o- fileio ......................................................... [Storage Objects: 1] | | o- disk1 ..................... [/var/storage/disk1.img (10.0GiB) write-back activated] | | o- alua ........................................................... [ALUA Groups: 1] | | o- default_tg_pt_gp ............................... [ALUA state: Active/optimized] | o- pscsi .......................................................... [Storage Objects: 0] | o- ramdisk ........................................................ [Storage Objects: 0] | o- rbd ............................................................ [Storage Objects: 0] o- iscsi .................................................................... [Targets: 1] | o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a .............. [TPGs: 1] | o- tpg1 ....................................................... [no-gen-acls, no-auth] | o- acls .................................................................. [ACLs: 1] | | o- iqn.2020-04.example.com:desktop-pc ........................... [Mapped LUNs: 1] | | o- mapped_lun0 ........................................ [lun0 fileio/disk1 (rw)] | o- luns .................................................................. [LUNs: 1] | | o- lun0 ............... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)] | o- portals ............................................................ [Portals: 1] | o- 0.0.0.0:3260 ............................................................. [OK] o- loopback ................................................................. [Targets: 0] o- vhost .................................................................... [Targets: 0] o- xen-pvscsi ............................................................... [Targets: 0]