Ubuntu User Blog

記事の更新日：2026/09/23　記事の文書一部修正 1.概要 この記事は2026年7月から8月にかけて検証した結果を整理したものです。以前、Firecrackerの動作検証を行い、Slackwareを利用したMicroVMを構築を踏まえて、全体を整理しました。 2026年4月にSlackwareのmicroVM作成にチャレンジする目的でrootdisk(rootfs作成)の調査をしました。その時から時間が空いてしまったのですが、もう一度、仕切り直しをして、Firecrackerで自作Slackware64 15.0のmicroVM稼働に挑戦しました。 Firecrackerで独自のmicroVMを動かすためには、microVMのkernelとrootfsが必要です。これを作成するためにはKVM環境に２つのSlackware64 15.0を作成します。１つはkernelBuildができる環境を準備します。もう一つはインストール時のモジュール選択を最低限にしたrootfs用途です。この２つの仮想マシンからFirecracker上で起動するために必要なファイルを作成して動かすことに挑戦しました。その内容を記述します。 私の評価は以下の通りです。 (1) 環境構築はKVM仮想環境を利用します (2) minimal kernel作成は、削って作るよりも、加えて作ることが楽でした (3) minimal rootfsは、Slackwareだから可能です。柔軟性が高いと思います (4) Firecrackerで起動できるように設定することが案外難しい 2.詳細 (1) 環境準備 HW: i3-7100, Meomry 16GB, SSD 256GB SW: LinuxMint 22.3 (a)kvmの導入 sudo apt -y install virt-manager qemu-system 導入後、再起動します。 (b)Slackware64 15.0のDownload Mirrorサイトからslackware64-15.0-isoをDownloadします。 https://mirrors.slackware.com/slackware/slackware-iso/slackware64-15.0-iso/ (c)仮想マシン作成(kernelBuildができる環境) 仮...

記事の更新日：2026/09/28　評価を追記 1.概要 microVMのFirecrackerを試しました。AWS Fargateで利用されている技術です。 loginできないDocker Container環境だと認識していましたが、 正しい内容とその仕組みを知る機会となりました。この内容を記述します。 私の評価は以下の通りです。 (1) AWS Fargateの技術をFirecrackerを試すことで理解できます (2) Firecrackerはコンテナではなく、microVMを管理する仕組みでした (3) Fargateはコンテナベースであるので、Firecrackerとの相違点はわかっていません (4) kernel, root-fsを準備して、Firecrackerに組込んで起動します、案外難しい 2.詳細 (1) ネット情報で基礎知識を取得 下記資料がすべてを示しています。 Firecracker https://firecracker-microvm.github.io/ KVM環境の上に、microVMを複数動作させ、そこでContainerを動かす仕組みのようです。 実際にmicroVMを起動すると100MB程度のメモリで動作しています。 試験環境はIntel i3, Memory 16GB, SSD 256GB, LinuxMint 22.3を利用しました。 手順は上記URLの下の方の下記部分にあります。 Announcing the Firecracker Open Source Technology 手順の記述内容に一部誤り（curl -L => curl -L -Oなど)があり、 下記参考資料を参照して実行します。 私はhome dicrectoryにfirecracker directryを作成して作業しました Firecrackerをさわって大量のmicroVMを立ち上げてみた https://dev.classmethod.jp/articles/reinvent2018-try-firecracker/ また、LinuxMint 22.3は/dev/kvmの権限設定は既定値で設定済みでした。 (a) firecrackerのdownload curl -L -O https://github.com/firecracker-...

記事の更新： 2026/08/22 1.概要 Ubuntu上のQEMU/KVMでmacOSを動作させる検証を行い、成功事例（macOS-Simple-KVM）と失敗事例（quickemu）を記述します。 Ubuntu上にQEMU/KVM仮想マシンでmacOSを体験できる情報をネットで見つけて、チャレンジしました。githubの情報で動作確認をして、成功事例と失敗事例を記載します。成功事例はmacOS-Simple-KVMを利用しました。失敗事例はquickemuを利用しました。その内容を記述します。 注意事項 macOSは無料で使用できますが、Apple純正ハードウエア以外で使用することはmacOSソフトウエア使用許諾契約に違反する行為です。すべては自己責任でお願いします。 2.詳細 (1) 成功事例 Catalinaを導入できます。Sequiaへのupgradeを試しましたが失敗しました。 https://github.com/foxlet/macOS-Simple-KVM 上記手順に沿って作業をします。 環境はamd Ryzen 4core 16GB memory ubuntu-22.04.5環境です Getting Started sudo apt-get install qemu-system qemu-utils python3 python3-pip Step 1 ./jumpstart.sh --Catalina Step 2 qemu-img create -f qcow2 MyDisk.qcow2 64G basic.shを修正（下記内容を追加）     -drive id=SystemDisk,if=none,file=MyDisk.qcow2 \     -device ide-hd,bus=sata.4,drive=SystemDisk \ sh basic.sh これから先はMacOSの導入手順で、Catalinaを無事に起動できます。 Catalina導入後、設定のupdateからSequiaにupgradeにもチャレンジしました。 しかし、仮想ディスクが64GBでは不足となり、upgrade失敗しました。 追加検証 仮想ディスクを100GBに変更してSequiaへのupgradeを試しましたが、 仮...

記事の更新日：2026/07/17 1.概要 2024年にubuntu-20.04環境のKVMでubuntu-20.04-arm64を動かしました。今回、LinuxMint環境で動作確認を再度作成したので、記事をリライトします。x86_64環境でarm64を動かすにはqemuのaarch64のエミュレーションを利用します。Virt-Managerでubuntuのarm64の環境にisoからインストールすることは可能ですが、遅くて実用的ではありません。理由はエミュレーションなので命令単位に実行するためです。 今回の試験は、KVM上でLinuxMint/Ubuntuのarm64が動作するのを確認して、arm64のPC購入の検討をする予定でした。従って、インストールすることでなく、動かすことが目標なので作成済み仮想マシンから導入するのが早道と考え直しました。その内容を記述します。 2.詳細 (1) LinuxMint環境 環境はLinuxMint 22.3です (a)KVM環境を構築 $ sudo apt -y install virt-manager qemu-system (b)ubuntu-24.04 server仮想マシンイメージ取得 $ https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-arm64.img Diskサイズを10Gに変更 $ qemu-img resize noble-server-cloudimg-arm64.img 10G (c)仮想マシン設定に必要な情報の作成 user-dataをvimで作成します #cloud-config user: ubuntu password: password chpasswd: { expire: false } ssh_pwauth: true user-data.isoを作成します $ touch meta-data $ genisoimage -output ./user-data.iso -volid cidata -joliet -rock user-data meta-data (d)仮想マシンのインストール $ virt-install \ --connect qemu:///system \ --name ub...

記事の更新日：2026/09/30　評価を加筆 1.概要 Windows11をローカルアカウントでインストールする方法をKVM環境で試してみました。Windows11はライセンス認証なしでも短期間の評価利用ならばインストール可能です。実機確認や簡単な評価には良い方法だと思ったので、この内容を記述します。 私の評価は以下の通りです。 (1) Windowsは有償製品のため試験をするには様々な制限があります (2) 試験をするための評価用の環境構築は90日間の評価期間が設定されています (3) Windows11の導入にはマイクロソフトアカウントが必要です (4) 評価用にローカルアカウントでインストールする方法を試してみました 注意事項 Windowsの利用にあたっては、Microsoftが定める使用許諾契約（EULA）を遵守する必要があります。ライセンス違反（不正なプロダクトキーの利用、規約外の商用利用など）は違法行為となるため、必ず正規のライセンスを取得・確認した上で操作を行ってください。 2.詳細 (a) Windows11のISOファイル入手 Windows11のISOファイルは、Microsoftサイトから入手しました (b) 仮想環境(KVM) Ubuntu/LinuxMintにKVM環境を導入しました。 (c) 仮想TPMとUEFI Windows11のインストール条件をクリアするために導入します。 $ sudo add-apt-repository ppa:stefanberger/swtpm-focal $ sudo apt-get update $ sudo apt-get install swtpm swtpm-tools (d) Windows11仮想マシンについて Memory=8192MB, CPU=2, Disk=80GBに設定しました また、参考資料に沿って、BIOSとTMPを設定後、Boot OptionをCD-bootにします (e) Windows11インストール ライセンスキーはなしで、特に問題なく実行できます。 (f) Windows11の設定 参考資料に沿って、「ネットワークに接続しましょう」で、Shift+F10でコマンドプロンプトを表示 cd oobe BypassNRO.cmd 再起動になり、Windowsの設定を最初...

 1.概要 改めてKVM環境を調べてみました。KVM環境はパーテイションを１つ作成して導入したのですが、インストール時にインストーラが２つ目のパーティションを作成します。パーティションのタイプがBIOS bootと変わっています。その内容を記述します。 Legacy BIOSを利用して、物理ディスクにUbuntu 20.04を導入する場合、１つのパーティションだけで十分でした。MBRと作成したパーティション( ルート利用 )で導入できました。uefi BIOSに変わってから先頭の2048セクタは利用できず、更に、MBRブート用にboot partition( BIOS boot )が必要になっています。これが、KVM仮想環境にも適用されています。 現時点の仮想環境はLegacy BIOSが基本のようです。uefiBIOS向けに特別な方法を利用して設定する手段はありますが、枯れている技術で問題ないのでしょう。普通のPCも枯れた技術の選択肢を残してほしいものです。 2.詳細 KVM環境に導入したubuntu-24.04のterminalでfdiskで調べると下記２つのパーティションがありました。 /dev/vda1   4096 52426751 52422656  25G Linux filesystem /dev/vda2   2048     4095     2048   1M BIOS boot インストール時に作成したものは/dev/vda1だけです。 /dev/vda2はインストーラが自動作成するノノですが、気になったのはパーティションタイプのBIOS bootです。 fdiskで更にタイプを調べると下記設定でした。 4 BIOS boot fdiskのタイプ一覧を調べると04の設定は、FAT16 <32M となっています。 04 FAT16 <32M /dev/vdaはGPT設定されており、BIOS bootパーティションがbootのために必要なようです。場所は/dev/vda2ですが、ディスクの先頭にアロケーションされています。  MBRからGPTに変更になって一番困ったことはマルチブートの設定...

1.概要 microk8sをlxdで動作させる場合、lxd上のubuntuコンテナ上でpodを動作させます。pod自体がコンテナなので、コンテナの上でコンテナが動作するような形に見えます。最初、lxdのubuntu-VM上で動作させると思っていたのですが、構成が異なることに気が付きました。 kubernatesはmaster nodeとworker nodeに分かれています。しかし、microk8sは全てがmaster nodeであり、worker nodeでもあるようです。kubernatesのmaster nodeの弱点をカバーできそうな気がしました。master nodeが停止しても他のnodeがmaster nodeとして機能しそうな気がします 2.詳細 (a) lxd導入 lxdをubuntu-20.04 desktopに導入します (b) プロファイル設定 $ lxc profile create microk8s $ wget https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s-zfs.profile -O microk8s.profile $ cat microk8s.profile | lxc profile edit microk8s $ rm microk8s.profile (c) コンテナ作成と設定内容修正 k8s0の名称でubuntu20.04のコンテナを作成します。 $ lxc launch -p default -p microk8s ubuntu:20.04 k8s0 規定値の設定が大きいので修正をします。 $ lxc stop k8s0 $ lxc config set k8s0 limits.cpu=2 $ lxc config set k8s0 limits.memory=2GiB $ lxc start k8s0 同様にk8s1も作成します。 (d) microk8s導入 k8s0にmicrok8sを導入します $ lxc exec k8s0 -- sudo snap install microk8s --classic 次にk8s0上に/etc/rc.localを作成します $ cat << EOF > r...

記事の更新： 2026/09/02 1.概要 この記事は2022年の記事です。Android-x86はLinuxであると考えて、PC上で動作しないかを検証を湯治しました。最新環境での検証はできていませんが、価値ある記事と考えて、少しだけリライトをして、備忘録に残すことにしました。 Ubuntu 20.04環境をベースに、PC上でAndroid OSを動作させるプロジェクト「Android-x86（バージョン 8.1-r6）」の動作試験を行いました。今回は、検証用として以下の3つのアプローチで導入を試みています。 方法①： KVMによる仮想マシン上での実行（Legacy BIOS） 方法②： 物理PCのGRUBから直接カーネルをブート（Legacy BIOS） 方法③： 物理PCのGRUBから直接カーネルをブート（UEFI環境 / 英語配列ノートPC） 結論から言うと「GRUBによる直接ブート」が圧倒的に快適に動作します。それぞれの構築手順と、実際に触って見えてきた注意点や課題をまとめました。 今回実施した3つの検証環境における 特徴、メリット・デメリットの比較 は以下の通りです。 検証環境 ① KVM（仮想環境） ② BIOS PC（物理） ③ UEFI PC（物理） 主な特徴 動作は遅い [1] 実機で快適 [1] 実機で高速 [1] キーボード 日本語対応 [1] 日本語対応 [1] 英語配列 [1] 終了方法 正常に終了可能 [1] リセットが必要 [1] リセットが必要 [1] メリット 安全、手軽 [1] 高性能 [1] 高性能 [1] デメリット 低速 [1] 終了不可 [1] 終了不可 [1] 2.詳細 (1)    KVMによる仮想マシン上での実行（Legacy BIOS） (a) KVM環境構築 ubuntu-20.04の標準を導入しました。 (b) KVM設定 参考資料を参照して、KVM上にandroid-x86を導入して動作します。 Memory=2GB, CPU=2, Disk=20GBに設定し、NICのデバイスのモデルをハイパーバイザーのデフォルト設定にしました。android-x86はNIC接続に対応していないようで、Wifi接続だけ対応しています。KVM環境には既定値でwifiのエミュレート機能があるようです。 (c)...