カテゴリー: 仮想化

投稿日:

HPE Morpheus VM Essentials / HVM が Ubuntu 24.04 ベースにも対応するも別環境として構築必須

しれっとドキュメントが更新されているので気が付きにくいのですが、Ubuntu 22.04 LTSベースだった HPE Morpheus VM Essentials / HVM が v8.0.5 からUbuntu 24.04 LTS ベースに対応しています。

ただ、クラスターに登録する際のインタフェースを見る限りでは、Ubuntu 22.04ベースはHPE VM 1.1クラスタ、Ubuntu 24.04ベースは HPE VM 1.2クラスタと分割する必要があるようです。（2025年5月末時点でのドキュメントには、そもそもクラスタのバージョンについて書かれていませんが・・・)

現状運用しているUbuntu 22.04ベースのHPE VM 1.1クラスタをUbuntu 24.04ベースのHPE VM 1.2クラスタにアップデートすることについての記述がないので、継続運用性に若干疑問が・・・

投稿日:

HPE VMEssentialsでNVIDIA vGPUは使えるか？

HPE VMEssentials環境でNVIDIA vGPUが使えるか試してみたところ、libvirtを直接操作することで仮想マシンにvGPUの割り当てが行えることを確認した。

ただし、HPE VMEssentialsで管理していると思われる仮想マシンのXML形式の設定ファイルと、virsh dumpxml で取得できるXML形式の設定ファイルの内容は別物になっていて、HPE Web UIで設定変更するとvirshで直接編集した結果は破棄されてしまうので注意が必要

仮想マシンの起動/停止レベルであれば問題ないが、設定変更はダメだった

HPE VMEssentialsのGUIでパススルー設定をして仮想マシンに割り当てるという設定も可能ではあるのだが、パススルー設定できるデバイスでvGPUデバイスが選択できない状態だった。つまりは、NVIDIA vGPUドライバを入れずに仮想マシンから直接GPU全体を割り当てる、といった使い方しかできない。

HPE VMessentials側の設定:下地作り

パススルーする際に必要となるIOMMU関連設定は、hpe-vm v8.0.5.1では設定実施済みとなっていた。

必要なのはLinux標準のnouveauドライバを使用しないようにするための blacklist.conf 設定だった

実施後、nvidia vGPU のうちUbuntu版の nvidia-vgpu-ubuntu-570_570.133.10_amd64.deb をインストールして対応完了

Secure Boot有効の場合はUEFIへのキー埋め込みも行ってくれた。

また、sriov-manager -e ALL を実行して、GPUを分割されるか確認

pcuser@vgpuserver:~$ lspci -d 10de: -nnk
08:00.0 3D controller [0302]: NVIDIA Corporation GA107GL [A2 / A16] [10de:25b6] (rev a1)
        Subsystem: NVIDIA Corporation Device [10de:157e]
        Kernel driver in use: nouveau
        Kernel modules: nvidiafb, nouveau, nvidia_vgpu_vfio, nvidia
root@vgpuserver:~# /usr/lib/nvidia/sriov-manage -e ALL
Enabling VFs on 0000:08:00.0
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 148: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
/usr/lib/nvidia/sriov-manage: line 90: /sys/bus/pci/drivers/nvidia/bind: No such file or directory
root@vgpuserver:~# lspci -d 10de:
08:00.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.4 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.5 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.6 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:00.7 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.1 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.2 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.3 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.4 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.5 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.6 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:01.7 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.0 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.1 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.2 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
08:02.3 3D controller: NVIDIA Corporation GA107GL [A2 / A16] (rev a1)
root@vgpuserver:~#

分割されるようであれば、これが起動時に実行されるよう/usr/local/lib/systemd/system/nvidia-sriov.service を作成し、起動する

root@vgpuserver:~# mkdir -p /usr/local/lib/systemd/system
root@vgpuserver:~# vi /usr/local/lib/systemd/system/nvidia-sriov.service
root@vgpuserver:~# cat /usr/local/lib/systemd/system/nvidia-sriov.service
[Unit]
Description=Enable NVIDIA SR-IOV
Before=pve-guests.service nvidia-vgpud.service nvidia-vgpu-mgr.service

[Service]
Type=oneshot
ExecStart=/usr/lib/nvidia/sriov-manage -e ALL

[Install]
WantedBy=multi-user.target
root@vgpuserver:~# systemctl  daemon-reload
root@vgpuserver:~# systemctl status nvidia-sriov.service
○ nvidia-sriov.service - Enable NVIDIA SR-IOV
     Loaded: loaded (/usr/local/lib/systemd/system/nvidia-sriov.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
root@vgpuserver:~# systemctl enable --now nvidia-sriov.service
Created symlink /etc/systemd/system/multi-user.target.wants/nvidia-sriov.service → /usr/local/lib/systemd/system/nvidia-sriov.service.
root@vgpuserver:~# systemctl status nvidia-sriov.service
○ nvidia-sriov.service - Enable NVIDIA SR-IOV
     Loaded: loaded (/usr/local/lib/systemd/system/nvidia-sriov.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2025-05-22 18:08:35 JST; 1s ago
    Process: 2853 ExecStart=/usr/lib/nvidia/sriov-manage -e ALL (code=exited, status=0/SUCCESS)
   Main PID: 2853 (code=exited, status=0/SUCCESS)
        CPU: 44ms

May 22 18:08:35 vgpuserver systemd[1]: Starting Enable NVIDIA SR-IOV...
May 22 18:08:35 vgpuserver sriov-manage[2857]: GPU at 0000:08:00.0 already has VFs enabled.
May 22 18:08:35 vgpuserver systemd[1]: nvidia-sriov.service: Deactivated successfully.
May 22 18:08:35 vgpuserver systemd[1]: Finished Enable NVIDIA SR-IOV.
root@vgpuserver:~#

再起動してnvidia-smiが動くか確認



pcuser@vgpuserver:~$ nvidia-smi
Tue May 27 15:39:51 2025
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.133.10             Driver Version: 570.133.10     CUDA Version: N/A      |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A2                      On  |   00000000:08:00.0 Off |                  Off |
|  0%   50C    P8              9W /   60W |       0MiB /  16380MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+
pcuser@vgpuserver:~$

HPE VMessentials側の設定:libvirtいじり

v8.0.5時点ではHVM経由ではvGPU割り当てができないので、libvirtを直接いじってvGPUを仮想マシンに割り当てる必要がある

参考になるドキュメントは「Configuring the vGPU Manager for a Linux with KVM Hypervisor」

まず、このデバイスがサポートしている”nvidia-3桁数字”という書式のデバイス種別を確認するため「mdevctl types」を実行。また、同時に「0000:08:00.4」といった形でPCIデバイスのアドレスを確認

root@vgpuserver:~# mdevctl types
0000:08:00.4
  nvidia-742
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1B
    Description: num_heads=4, frl_config=45, framebuffer=1024M, max_resolution=5120x2880, max_instance=16
  nvidia-743
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2B
    Description: num_heads=4, frl_config=45, framebuffer=2048M, max_resolution=5120x2880, max_instance=8
  nvidia-744
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1Q
    Description: num_heads=4, frl_config=60, framebuffer=1024M, max_resolution=5120x2880, max_instance=16
  nvidia-745
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2Q
    Description: num_heads=4, frl_config=60, framebuffer=2048M, max_resolution=7680x4320, max_instance=8
  nvidia-746
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-4Q
    Description: num_heads=4, frl_config=60, framebuffer=4096M, max_resolution=7680x4320, max_instance=4
  nvidia-747
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-8Q
    Description: num_heads=4, frl_config=60, framebuffer=8192M, max_resolution=7680x4320, max_instance=2
  nvidia-748
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16Q
    Description: num_heads=4, frl_config=60, framebuffer=16384M, max_resolution=7680x4320, max_instance=1
  nvidia-749
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-1A
    Description: num_heads=1, frl_config=60, framebuffer=1024M, max_resolution=1280x1024, max_instance=16
  nvidia-750
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-2A
    Description: num_heads=1, frl_config=60, framebuffer=2048M, max_resolution=1280x1024, max_instance=8
  nvidia-751
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-4A
    Description: num_heads=1, frl_config=60, framebuffer=4096M, max_resolution=1280x1024, max_instance=4
  nvidia-752
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-8A
    Description: num_heads=1, frl_config=60, framebuffer=8192M, max_resolution=1280x1024, max_instance=2
  nvidia-753
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16A
    Description: num_heads=1, frl_config=60, framebuffer=16384M, max_resolution=1280x1024, max_instance=1
＜略＞
  nvidia-753
    Available instances: 1
    Device API: vfio-pci
    Name: NVIDIA A2-16A
    Description: num_heads=1, frl_config=60, framebuffer=16384M, max_resolution=1280x1024, max_instance=1
root@vgpuserver:~#

vGPUでCUDAを使う場合はA2-?Q デバイスあたりを使う

0000:08:00.4にある RAM2GBのA2-2Q の nvidia-745 で定義を作成する

まず「0000:08:00.4」をlibvirtで使用するデバイスIDに変換するためvirsh nodedev-listコマンドで確認する

root@vgpuserver:~# virsh nodedev-list --cap pci|grep 08_00_4
pci_0000_08_00_4
root@vgpuserver:~#

「pci_0000_08_00_4」の「nvidia-745」が定義ファイルで使う値となる

また、定義ごとに一意のUUIDが必要になるので「uuidgen」コマンドを実行して値を確認してファイルを作成する

root@vgpuserver:~# uuidgen
73f353e8-7da8-4b76-8182-04c5a1415dec
root@vgpuserver:~# vi vgpu-test.xml
root@vgpuserver:~# cat vgpu-test.xml
<device>
    <parent>pci_0000_08_00_4</parent>
    <capability type="mdev">
        <type id="nvidia-745"/>
        <uuid>73f353e8-7da8-4b76-8182-04c5a1415dec</uuid>
    </capability>
</device>
root@vgpuserver:~#

作成したファイルをnodedevとして登録する

root@vgpuserver:~# virsh nodedev-define vgpu-test2.xml
Node device 'mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4' defined from 'vgpu-test2.xml'

root@vgpuserver:~# virsh nodedev-list --cap mdev --inactive
mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4

root@vgpuserver:~# virsh nodedev-list --cap mdev

root@vgpuserver:~#

登録できたmdevを開始する

root@vgpuserver:~# virsh nodedev-start mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4
Device mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4 started

root@vgpuserver:~# virsh nodedev-list --cap mdev
mdev_73f353e8_7da8_4b76_8182_04c5a1415dec_0000_08_00_4

root@vgpuserver:~# virsh nodedev-list --cap mdev --inactive

root@vgpuserver:~#

こうして作られたmdevデバイスをvirtshコマンドを使って直接仮想マシンに追加する

root@vgpuserver:~# virsh attach-device almalinux --persistent /dev/stdin <<EOF
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='on'>
  <source>
    <address uuid='73f353e8-7da8-4b76-8182-04c5a1415dec'/>
  </source>
</hostdev>
EOF
Device attached successfully

root@vgpuserver:~#

これで設定ができたのであとは仮想マシンを起動して、仮想マシン内でvGPUドライバをインストールすれば使えました

ただ、HVM管理UIで設定を変えるとmdev設定は消えてしまうので、実用するにはつらいですね

投稿日:

Proxmoxで作った仮想マシンのsnapshotはどうやって見えるのか？

Proxmoxで仮想マシンを作った場合、仮想マシンのsnapshotの作られ方が仮想マシンを置く場所(データストア)によって異なっている。

zfsについては簡単に確認できたが、それ以外についてどうなるのかを確認した。

まず、proxmoxのWeb UIからスナップショットを作成した

これをコマンドで確認していく

まず、Proxmox VE側のコマンドで仮想マシンにsnapshotがあるかどうかは「qm listsnapshot <VMID>」を実行して確認できる。これは各ファイルシステムで共通となる。

root@pve3:~# qm listsnapshot 103
`-> test                        2025-04-17 15:19:16     no-description
 `-> current                                            You are here!
root@pve3:~#

次に各ファイルシステムごとにそれぞれ確認していく手法が違う。

ZFSの場合

例えばzfsの場合であれば 「zfs list -t snapshot」で確認できる。

root@pve3:~# qm listsnapshot 101
`-> zfs-test-snap               2025-04-17 15:39:18     no-description
 `-> current                                            You are here!
root@pve3:~# zfs list -t snapshot
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
rpool/data/vm-101-disk-0@zfs-test-snap     0B      -   139K  -
rpool/data/vm-101-disk-1@zfs-test-snap     0B      -  22.8G  -
rpool/data/vm-101-disk-2@zfs-test-snap     0B      -  22.1M  -
rpool/data/vm-101-disk-3@zfs-test-snap     0B      -  85.2K  -
root@pve3:~#

NFSの場合

NFSの場合、仮想マシンをqcow2形式で作成した場合のみsnapshot作成が可能となる。

まず仮想マシンの設定を確認

root@pve3:~# qm config 105
agent: 1
boot: order=sata0;ide0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide0: none,media=cdrom
ide2: none,media=cdrom
machine: pc-i440fx-9.2+pve1
memory: 2048
meta: creation-qemu=9.2.0,ctime=1744345484
name: wintest3-nfs
net0: e1000=BC:24:11:FD:D4:F3,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
parent: nfs-snap
sata0: ontap:105/vm-105-disk-0.qcow2,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=7a3e58d8-be9e-4e03-a040-bd1635aa3dfe
sockets: 1
vmgenid: f361fff2-f474-4260-99ac-586c42db009b
root@pve3:~# qm listsnapshot 105
`-> nfs-snap                    2025-04-17 15:39:29     no-description
 `-> current                                            You are here!
root@pve3:~#

該当する領域をlsコマンドで確認

root@pve3:~# ls -l /mnt/pve/ontap/images/105
total 13607536
-rw-r----- 1 root root 45504004165 Apr 17 15:36 vm-105-disk-0.qcow2
root@pve3:~#

見た目には1ファイルしかないように見える。

このファイルに対して「qemu-img snapshot -l ファイル名」を実行するとsnapshotが作成されているかどうかがわかる。

root@pve3:~# qemu-img snapshot -l /mnt/pve/ontap/images/105/vm-105-disk-0.qcow2
Snapshot list:
ID      TAG               VM_SIZE                DATE        VM_CLOCK     ICOUNT
1       nfs-snap              0 B 2025-04-17 15:39:29  0000:00:00.000          0
root@pve3:~#

cephの場合

cephの場合、rbdコマンドのオプションでいろいろ指定していくのだが、確認がちょっとめんどい

まずは、仮想マシンの設定を「qm config <VMID>」を実行して確認する。

root@pve3:~# qm config 103
agent: 1
boot: order=scsi0;ide2;net0
cores: 2
cpu: x86-64-v2-AES
ide2: none,media=cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1744338514
name: linux2-ceph
net0: virtio=BC:24:11:3A:D1:9E,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
parent: test
scsi0: cephpool:vm-103-disk-0,iothread=1,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=37f0d81e-3ed1-417a-9a10-3d8f556e3b37
sockets: 1
vmgenid: 0ea7ac3f-7b05-49d0-90c0-fbba87cc63ae
root@pve3:~# qm listsnapshot 103
`-> test                        2025-04-17 15:19:16     no-description
 `-> current                                            You are here!
root@pve3:~#

scsi0の行にある「cephpool」が使用しているデータストア名となる。

Ceph RDBが使用しているOSD Pool名を「ceph osd pool ls」を実行して確認する

root@pve3:~# ceph osd pool ls
.mgr
cephpool
cephfs_data
cephfs_metadata
root@pve3:~#

cephfs_dataとcephfs_metadataはCeph FSのほうで使っているデータで、仮想マシンをおくデータストアはcephpool のほうとなる。

cephpoolにある仮想マシン用のディスクを「rbd ls cephpool」で確認する

root@pve3:~# rbd ls cephpool
vm-103-disk-0
root@pve3:~#

この仮想マシンについて、snapshotが作成されているかは「rbd snap ls cephpool/<仮想ディスク名>」で確認する

root@pve3:~# rbd snap ls cephpool/vm-103-disk-0
SNAPID  NAME  SIZE    PROTECTED  TIMESTAMP
    10  test  40 GiB             Thu Apr 17 15:19:16 2025
root@pve3:~#
投稿日:

VMware Flingsにあったソフトウェアがbroadcomになって移転した先

ESXi for ARM EditionやUSB Network Native Driver for ESXi といった以前VMware Flings http://flings.vmware.com にあったソフトウェアは、2023年10月に https://developer.vmware.com/samples にリダイレクトされるようになった。

このURLは、 https://developer.broadcom.com/samples にリダイレクトされるのだが、2025年4月2日時点では、errorとなっている。

では、以前VMware Flings にあったものがどこにあるのかというと Broadcom communityの「Welcome to the new home for Flings!」にあった

2024年8月に更新されたvSphere GPU Monitoring を最後に更新はないように見えたけど、

よくみてみたら「Nested ESXi Virtual Appliance」は ESXi 8.0 Update 3c VAが出てた

2025/09/17追記

5月にまた構造変更があったようで、フォーラム とBroadcom SupportのFree Downloadsに追加された「Flings」となりました

投稿日:

Oracle Cloudのオブジェクトストレージにcyberduckで接続する

Oracle Cloud(OCI)のオブジェクトストレージに cyberduck を使って接続する際、なんかうまくいかなかったのでメモ書き

us-phoenix-1にあるので、OCI Object Storage (us-phoenix-1).cyberduckprofile を選択したのだが選択しても表示されるサーバ名は「s3.amazonaws.com」となっている。

cyberduckprofileの内容を確認すると下記なので、本来サーバに表示されるべきなのは「<namespace>.compat.objectstorage.us-phoenix-1.oraclecloud.com」なんじゃないのか？という疑問点が・・・

	<key>Protocol</key>
	<string>s3</string>
	<key>Vendor</key>
	<string>oracle-us-phoenix-1</string>
	<key>Description</key>
	<string>OCI Object Storage (us-phoenix-1)</string>
	<key>Hostname Placeholder</key>
	<string>&lt;namespace&gt;.compat.objectstorage.us-phoenix-1.oraclecloud.com</string>
	<key>Hostname Configurable</key>
	<true/>

なお、cyberduckのバージョンは 9.1.2 (42722) でした。

じゃあ、OCIにつなぐときはどう接続すればいいのか？

とりあえず、プロファイルはOCI Object Storageを選択する

サーバ名は「<namespace>.compat.objectstorage.us-phoenix-1.oraclecloud.com」

ここでいう<namespace>は、Oracle Cloudコンソールで[ストレージ]-[オブジェクトストレージ]-[バケット(bucket)]で表示される「ネームスペース」のこととなる。

cyberduckに入力すると以下のような感じになる。

続いてAccess KeyとSecret KeyをOracle Cloudコンソールで作成する。

[アイデンティティとセキュリティ]-[ドメイン]でドメイン「Default」を選択

[アイデンティティ・ドメイン]-[ユーザー]にて、API操作用のユーザを作成

作成後、該当ユーザを選択し、[リソース]-[顧客秘密キー]を開く

「秘密キーの生成」をクリック

ここで表示される「生成されたキー」が Secret Keyとなる。

書いてある通りに再表示できないので、間違えずに保存すること。

画面を閉じて一覧に戻ると、Access Keyが確認できる。

これで、Access KeyとSecret Keyが入手できたので、Cyberduck設定画面に入力する

これで接続をすると以下のようにOracle Cloud上のオブジェクトストレージのbucket内容が表示されるのを確認できた。