Virtual Redfish BMC¶
The Virtual Redfish BMC is functionally similar to the Virtual BMC tool except that the frontend protocol is Redfish rather than IPMI. The Redfish commands coming from the client are handled by one or more resource-specific drivers.
Feature sets¶
The emulator can be configured with different feature sets to emulate different
hardware. The feature set is supplied either via the
SUSHY_EMULATOR_FEATURE_SET
configuration variable or through the
--feature-set
command line flag.
Supported feature sets are:
* minimum
- only Systems with Boot settings and no other optional fields.
* vmedia
- minimum
plus Managers, VirtualMedia and EthernetInterfaces.
* full
- all features implemented in the emulator.
Systems resource¶
For Systems resource, emulator maintains two drivers relying on a virtualization backend to emulate bare metal machines by means of virtual machines. In addition, there is a fake driver used to mock bare metal machines.
The following sections will explain how to configure and use each of these drivers.
Systems resource driver: libvirt¶
First thing you need is to set up some libvirt-managed virtual machines (AKA domains) to manipulate. The following command will create a new virtual machine i.e. libvirt domain vbmc-node:
tmpfile=$(mktemp /tmp/sushy-domain.XXXXXX)
virt-install \
--name vbmc-node \
--ram 1024 \
--disk size=1 \
--vcpus 2 \
--os-type linux \
--os-variant fedora28 \
--graphics vnc \
--print-xml > $tmpfile
virsh define --file $tmpfile
rm $tmpfile
Next you can fire up the Redfish virtual BMC which will listen at localhost:8000 (by default):
sushy-emulator
* Running on http://localhost:8000/ (Press CTRL+C to quit)
Now you should be able to see your libvirt domain among the Redfish Systems:
curl http://localhost:8000/redfish/v1/Systems/
{
"@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
"Name": "Computer System Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/vbmc-node"
}
],
"@odata.context": "/redfish/v1/$metadata#ComputerSystemCollection.ComputerSystemCollection",
"@odata.id": "/redfish/v1/Systems",
"@Redfish.Copyright": "Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
}
You should be able to flip its power state via the Redfish call:
curl -d '{"ResetType":"On"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/vbmc-node/Actions/ComputerSystem.Reset
curl -d '{"ResetType":"ForceOff"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/vbmc-node/Actions/ComputerSystem.Reset
You can have as many domains as you need. The domains can be concurrently managed over Redfish and some other tool like Virtual BMC.
Simple Storage resource¶
For emulating the Simple Storage resource, some additional preparation is required on the host side.
First, you need to create, build and start a libvirt storage pool using virsh:
virsh pool-define-as testPool dir - - - - "/testPool"
virsh pool-build testPool
virsh pool-start testPool
virsh pool-autostart testPool
Next, create a storage volume in the above created storage pool:
virsh vol-create-as testPool testVol 1G
Next, attach the created volume to the virtual machine/domain:
virsh attach-disk vbmc-node /testPool/testVol sda
Now, query the Simple Storage resource collection for the vbmc-node domain in a closely similar format (with ‘ide’ and ‘scsi’, here, referring to the two Redfish Simple Storage Controllers available for this domain):
curl http://localhost:8000/redfish/v1/vbmc-node/SimpleStorage
{
"@odata.type": "#SimpleStorageCollection.SimpleStorageCollection",
"Name": "Simple Storage Collection",
"Members@odata.count": 2,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/vbmc-node/SimpleStorage/ide"
},
{
"@odata.id": "/redfish/v1/Systems/vbmc-node/SimpleStorage/scsi"
}
],
"Oem": {},
"@odata.context": "/redfish/v1/$metadata#SimpleStorageCollection.SimpleStorageCollection",
"@odata.id": "/redfish/v1/Systems/vbmc-node/SimpleStorage"
}
UEFI boot¶
By default, legacy or BIOS mode is used to boot the instance. However, libvirt domain can be configured to boot via UEFI firmware. This process requires additional preparation on the host side.
On the host you need to have OVMF firmware binaries installed. Fedora users could pull them as edk2-ovmf RPM. On Ubuntu, apt-get install ovmf should do the job.
Then you need to create a VM by running virt-install with the UEFI specific –boot options:
Example:
tmpfile=$(mktemp /tmp/sushy-domain.XXXXXX)
virt-install \
--name vbmc-node \
--ram 1024 \
--boot loader.readonly=yes \
--boot loader.type=pflash \
--boot loader.secure=no \
--boot loader=/usr/share/OVMF/OVMF_CODE.secboot.fd \
--boot nvram.template=/usr/share/OVMF/OVMF_VARS.fd \
--disk size=1 \
--vcpus 2 \
--os-type linux \
--os-variant fedora28 \
--graphics vnc \
--print-xml > $tmpfile
virsh define --file $tmpfile
rm $tmpfile
This will create a new libvirt domain with path to OVMF images properly configured. Let’s take a note on the path to the blob by running virsh dumpxml vbmc-node:
Example:
<domain type="kvm">
...
<os>
<type arch="x86_64" machine="q35">hvm</type>
<loader readonly="yes" type="pflash" secure="no">/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
<nvram template="/usr/share/edk2/ovmf/OVMF_VARS.fd"/>
<boot dev="hd"/>
</os>
...
</domain>
Because now we need to add this path to emulator’s configuration matching VM architecture we are running. It is also possible to make Redfish calls to enable or disable Secure Boot by specifying which nvram template to load in each case. Make a copy of stock configuration file and edit it accordingly:
$ cat sushy-tools/doc/source/admin/emulator.conf
...
SUSHY_EMULATOR_BOOT_LOADER_MAP = {
'Uefi': {
'x86_64': '/usr/share/OVMF/OVMF_CODE.secboot.fd',
...
}
SUSHY_EMULATOR_SECURE_BOOT_ENABLED_NVRAM = '/usr/share/OVMF/OVMF_VARS.secboot.fd'
SUSHY_EMULATOR_SECURE_BOOT_DISABLED_NVRAM = '/usr/share/OVMF/OVMF_VARS.fd'
...
Now you can run sushy-emulator with the updated configuration file:
sushy-emulator --config emulator.conf
Note
The images you will serve to your VMs need to be UEFI-bootable.
Settable boot image¶
The libvirt system emulation backend supports setting custom boot images, so that libvirt domains (representing bare metal nodes) can boot from user images.
This feature enables system boot from virtual media device.
The limitations:
Only ISO images are supported
See VirtualMedia resource section for more information on how to perform virtual media boot.
Systems resource driver: OpenStack¶
You can use an OpenStack cloud instances to simulate Redfish-managed baremetal machines. This setup is known under the name of OpenStack Virtual Baremetal. We will largely reuse its OpenStack infrastructure and configuration instructions. After all, what we are trying to do here is to set up the Redfish emulator alongside the openstackbmc tool which is used for exactly the same purpose at OVB with the only difference that it works over the IPMI protocol as opposed to Redfish.
The easiest way is probably to set up your OpenStack Virtual Baremetal cloud by following its instructions.
Once your OVB cloud operational, you log into the BMC instance and set up sushy-tools there.
Next you can invoke the Redfish virtual BMC pointing it to your OVB cloud:
sushy-emulator --os-cloud rdo-cloud
* Running on http://localhost:8000/ (Press CTRL+C to quit)
By this point you should be able to see your OpenStack instances among the Redfish Systems:
curl http://localhost:8000/redfish/v1/Systems/
{
"@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
"Name": "Computer System Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/8dbe91da-4002-4d61-a56d-1a00fc61c35d"
}
],
"@odata.context": "/redfish/v1/$metadata#ComputerSystemCollection.ComputerSystemCollection",
"@odata.id": "/redfish/v1/Systems",
"@Redfish.Copyright": "Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
}
And flip its power state via the Redfish call:
curl -d '{"ResetType":"On"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/vbmc-node/Actions/ComputerSystem.Reset
curl -d '{"ResetType":"ForceOff"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/vbmc-node/Actions/ComputerSystem.Reset
You can have as many OpenStack instances as you need. The instances can be concurrently managed over Redfish and functionally similar tools.
Systems resource driver: Ironic¶
You can use the Ironic driver to manage Ironic baremetal instance to simulated Redfish API. You may want to do this if you require a redfish compatible endpoint but don’t have direct access to the BMC (you only have access via Ironic) or the BMC doesn’t support redfish.
Assuming your baremetal cloud is setup you can invoke the Redfish emulator by running
sushy-emulator --ironic-cloud baremetal-cloud
* Running on http://localhost:8000/ (Press CTRL+C to quit)
By this point you should be able to see your Baremetal instances among the Redfish Systems:
curl http://localhost:8000/redfish/v1/Systems/
{
"@odata.type": "#ComputerSystemCollection.ComputerSystemCollection",
"Name": "Computer System Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/<uuid>"
}
],
"@odata.context": "/redfish/v1/$metadata#ComputerSystemCollection.ComputerSystemCollection",
"@odata.id": "/redfish/v1/Systems",
"@Redfish.Copyright": "Copyright 2014-2016 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
}
And flip its power state via the Redfish call:
curl -d '{"ResetType":"On"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/<uuid>/Actions/ComputerSystem.Reset
curl -d '{"ResetType":"ForceOff"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/<uuid>/Actions/ComputerSystem.Reset
Or update their boot device:
curl -d '{"Boot":{"BootSourceOverrideTarget":"Pxe"}}' \
-H "Content-Type: application/json" -X PATCH \
http://localhost:8000/redfish/v1/Systems/<uuid>
curl -d '{"Boot":{"BootSourceOverrideTarget":"Hdd"}}' \
-H "Content-Type: application/json" -X PATCH \
http://localhost:8000/redfish/v1/Systems/<uuid>
Systems resource driver: fake¶
The fake
system driver is designed to conduct large-scale testing of
Ironic without having a lot of bare-metal machines or being able to create a
large number of virtual machines. When the Redfish emulator is configured with
the fake
system backend, all operations just return success. Any
modifications are done purely in the local cache. This way, many Ironic
operations can be tested at scale without access to a large computing pool.
System status notifications¶
The fake
driver may need to simulate components that run on the VMs to test
an end-to-end deployment. This requires a hook interface to integrate external
components. For instance, when testing Ironic scalability, Ironic needs to
communicate with the Ironic Python Agent (IPA). A fake IPA can be implemented
and synchronized with the VM status using this hook, which notifies the fake
IPA whenever the VM status changes.
To enable notifications, set external_notifier
to True
in the fake system
object:
{
"uuid": "7946b59-9e44-4fa7-8e91-f3527a1ef094",
"name": "fake",
"power_state": "Off",
"external_notifier": True,
"nics": [
{
"mac": "00:5c:52:31:3a:9c",
"ip": "172.22.0.100"
}
]
}
After this, whenever the fake driver updates this system object, it will send
an HTTP PUT
request with the new system object as JSON
data. The
endpoint URL can be configured with the parameter
EXTERNAL_NOTIFICATION_URL
.
Filtering by allowed instances¶
It is not always desirable to manage every accessible virtual machine as a Redfish System, such as when an OpenStack tenant has many instances which do not represent virtual baremetal. In this case it is possible to specify a list of UUIDs which are allowed.
$ cat sushy-tools/doc/source/admin/emulator.conf
...
SUSHY_EMULATOR_ALLOWED_INSTANCES = [
"437XR1138R2",
"1",
"529QB9450R6",
"529QB9451R6",
"529QB9452R6",
"529QB9453R6"
]
...
Managers resource¶
Managers are emulated based on systems: each System has a Manager with the same UUID. The first (alphabetically) manager will pretend to manage all Chassis and potentially other resources.
Managers will be revealed when querying the Managers resource directly, as well as other resources they manage or have some other relations.
curl http://localhost:8000/redfish/v1/Managers
{
"@odata.type": "#ManagerCollection.ManagerCollection",
"Name": "Manager Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Managers/58893887-8974-2487-2389-841168418919"
}
],
"@odata.context": "/redfish/v1/$metadata#ManagerCollection.ManagerCollection",
"@odata.id": "/redfish/v1/Managers",
"@Redfish.Copyright": "Copyright 2014-2017 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
Chassis resource¶
For emulating Chassis resource, the user can statically configure one or more imaginary chassis. All existing resources (e.g. Systems, Managers, Drives) will pretend to reside in the first chassis.
SUSHY_EMULATOR_CHASSIS = [
{
"Id": "Chassis",
"Name": "Chassis",
"UUID": "48295861-2522-3561-6729-621118518810"
}
]
By default a single chassis with be configured automatically.
Chassis will be revealed when querying the Chassis resource directly, as well as other resources they manage or have some other relations.
curl http://localhost:8000/redfish/v1/Chassis
{
"@odata.type": "#ChassisCollection.ChassisCollection",
"Name": "Chassis Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Chassis/48295861-2522-3561-6729-621118518810"
}
],
"@odata.context": "/redfish/v1/$metadata#ChassisCollection.ChassisCollection",
"@odata.id": "/redfish/v1/Chassis",
"@Redfish.Copyright": "Copyright 2014-2017 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
Indicator resource¶
IndicatorLED resource is emulated as a persistent emulator database record, observable and manageable by a Redfish client.
By default, Chassis and Systems resources have emulated IndicatorLED sub-resource attached and Lit.
Non-default initial indicator state can optionally be configured on a per-resource basis:
SUSHY_EMULATOR_INDICATOR_LEDS = {
"48295861-2522-3561-6729-621118518810": "Blinking"
}
Indicator LEDs will be revealed when querying any resource having IndicatorLED:
$ curl http://localhost:8000/redfish/v1/Chassis/48295861-2522-3561-6729-621118518810
{
"@odata.type": "#Chassis.v1_5_0.Chassis",
"Id": "48295861-2522-3561-6729-621118518810",
"Name": "Chassis",
"UUID": "48295861-2522-3561-6729-621118518810",
...
"IndicatorLED": "Lit",
...
}
Redfish client can turn IndicatorLED into a different state:
curl -d '{"IndicatorLED": "Blinking"}' \
-H "Content-Type: application/json" -X PATCH \
http://localhost:8000/redfish/v1/Chassis/48295861-2522-3561-6729-621118518810
Virtual media resource¶
Virtual Media resource is emulated as a persistent emulator database record, observable and manageable by a Redfish client.
By default, VirtualMedia resource includes two emulated removable devices: Cd and Floppy. Each Manager resource gets its own collection of virtual media devices as a VirtualMedia sub-resource.
If currently used Systems resource emulation driver supports setting boot image, VirtualMedia resource will apply inserted image onto all the systems being managed by this manager. Setting system boot source to Cd and boot mode to Uefi will cause the system to boot from virtual media image.
User can change virtual media devices and their properties through emulator configuration (except for the OpenStack driver which only supports Cd):
SUSHY_EMULATOR_VMEDIA_DEVICES = {
"Cd": {
"Name": "Virtual CD",
"MediaTypes": [
"CD",
"DVD"
]
},
"Floppy": {
"Name": "Virtual Removable Media",
"MediaTypes": [
"Floppy",
"USBStick"
]
}
}
Virtual Media resource will be revealed when querying System resource:
curl -L http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia
{
"@odata.type": "#VirtualMediaCollection.VirtualMediaCollection",
"Name": "Virtual Media Services",
"Description": "Redfish-BMC Virtual Media Service Settings",
"Members@odata.count": 2,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd"
},
{
"@odata.id": "/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Floppy"
}
],
"@odata.context": "/redfish/v1/$metadata#VirtualMediaCollection.VirtualMediaCollection",
"@odata.id": "/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia",
"@Redfish.Copyright": "Copyright 2014-2017 Distributed Management Task Force, Inc. (DMTF). For the full DMTF copyright policy, see http://www.dmtf.org/about/policies/copyright."
}
Redfish client can insert a HTTP-based image into the virtual device:
curl -d '{"Image": "http://localhost.localdomain/mini.iso", "Inserted": true}' \
-H "Content-Type: application/json" \
-X POST \
http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd/Actions/VirtualMedia.InsertMedia
On insert the OpenStack driver will:
Upload the image directly to glance from the URL (long running)
Store the URL, image ID and volume ID in server metadata properties sushy-tools-image-url, sushy-tools-import-image, sushy-tools-volume
Create and attach a new volume the same size as the root disk
Rebuild the server with the image, replacing the contents of the root disk
Delete the image
Redfish client can eject image from virtual media device:
curl -d '{}' \
-H "Content-Type: application/json" \
-X POST \
http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd/Actions/VirtualMedia.EjectMedia
On eject the OpenStack driver will:
Assume the attached volume has been rewritten with a new image (an ISO installer or IPA)
Detach the volume
Create an image from the volume (long running)
Store the volume image ID in server metadata property sushy-tools-volume-image
Rebuild the server with the new image
Delete the volume
Delete the image
Virtual media boot¶
To boot a system from a virtual media device the client first needs to figure out which manager is responsible for the system of interest:
$ curl http://localhost:8000/redfish/v1/Systems/281c2fc3-dd34-439a-9f0f-63df45e2c998
{
...
"Links": {
"Chassis": [
],
"ManagedBy": [
{
"@odata.id": "/redfish/v1/Managers/58893887-8974-2487-2389-841168418919"
}
]
},
...
Exploring the Redfish API links, the client can learn the virtual media devices being offered:
$ curl http://localhost:8000/redfish/v1/Systems/58893887-894-2487-2389-841168418919/VirtualMedia
...
"Members": [
{
"@odata.id": "/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd"
},
...
Knowing virtual media device name, the client can check out its present state:
$ curl http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd
{
...
"Name": "Virtual CD",
"MediaTypes": [
"CD",
"DVD"
],
"Image": "",
"ImageName": "",
"ConnectedVia": "URI",
"Inserted": false,
"WriteProtected": false,
...
Assuming http://localhost/var/tmp/mini.iso URL points to a bootable UEFI or hybrid ISO, the following Redfish REST API call will insert the image into the virtual CD drive:
$ curl -d \
'{"Image":"http:://localhost/var/tmp/mini.iso", "Inserted": true}' \
-H "Content-Type: application/json" \
-X POST \
http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd/Actions/VirtualMedia.InsertMedia
Querying again, the emulator should have it in the drive:
$ curl http://localhost:8000/redfish/v1/Systems/58893887-8974-2487-2389-841168418919/VirtualMedia/Cd
{
...
"Name": "Virtual CD",
"MediaTypes": [
"CD",
"DVD"
],
"Image": "http://localhost/var/tmp/mini.iso",
"ImageName": "mini.iso",
"ConnectedVia": "URI",
"Inserted": true,
"WriteProtected": true,
...
Next, the node needs to be configured to boot from its local CD drive over UEFI:
$ curl -X PATCH -H 'Content-Type: application/json' \
-d '{
"Boot": {
"BootSourceOverrideTarget": "Cd",
"BootSourceOverrideMode": "Uefi",
"BootSourceOverrideEnabled": "Continuous"
}
}' \
http://localhost:8000/redfish/v1/Systems/281c2fc3-dd34-439a-9f0f-63df45e2c998
Note
With the OpenStack driver the boot source is changed during insert and eject, so setting BootSourceOverrideTarget to Cd or Hdd has no effect.
By this point the system will boot off the virtual CD drive when powering it on:
curl -d '{"ResetType":"On"}' \
-H "Content-Type: application/json" -X POST \
http://localhost:8000/redfish/v1/Systems/281c2fc3-dd34-439a-9f0f-63df45e2c998/Actions/ComputerSystem.Reset
Note
ISO files to boot from must be UEFI-bootable, libvirtd should be running on the same machine with sushy-emulator.
Storage resource¶
For emulating Storage resource for a System of choice, the user can statically configure one or more imaginary storage instances along with the corresponding storage controllers which are also imaginary.
The IDs of the imaginary drives associated to a Storage resource can be provided as a list under Drives.
The Storage instances are keyed by the UUIDs of the System they belong to.
SUSHY_EMULATOR_STORAGE = {
"da69abcc-dae0-4913-9a7b-d344043097c0": [
{
"Id": "1",
"Name": "Local Storage Controller",
"StorageControllers": [
{
"MemberId": "0",
"Name": "Contoso Integrated RAID",
"SpeedGbps": 12
}
],
"Drives": [
"32ADF365C6C1B7BD"
]
}
]
}
The Storage resources can be revealed by querying Storage resource for the corresponding System directly.
curl http://localhost:8000/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage
{
"@odata.type": "#StorageCollection.StorageCollection",
"Name": "Storage Collection",
"Members@odata.count": 1,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1"
}
],
"Oem": {},
"@odata.context": "/redfish/v1/$metadata#StorageCollection.StorageCollection",
"@odata.id": "/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage"
}
Drive resource¶
For emulating the Drive resource, the user can statically configure one or more drives.
The Drive instances are keyed in a composite manner using (System_UUID, Storage_ID) where System_UUID is the UUID of the System and Storage_ID is the ID of the Storage resource to which that particular drive belongs.
SUSHY_EMULATOR_DRIVES = {
("da69abcc-dae0-4913-9a7b-d344043097c0", "1"): [
{
"Id": "32ADF365C6C1B7BD",
"Name": "Drive Sample",
"CapacityBytes": 899527000000,
"Protocol": "SAS"
}
]
}
The Drive resource can be revealed by querying it via the System and the Storage resource it belongs to.
curl http://localhost:8000/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Drives/32ADF365C6C1B7BD
{
...
"Id": "32ADF365C6C1B7BD",
"Name": "Drive Sample",
"Model": "C123",
"Revision": "100A",
"CapacityBytes": 899527000000,
"FailurePredicted": false,
"Protocol": "SAS",
"MediaType": "HDD",
"Manufacturer": "Contoso",
"SerialNumber": "1234570",
...
}
Storage Volume resource¶
The Volume resource is emulated as a persistent emulator database record, backed by the libvirt virtualization backend of the dynamic Redfish emulator.
Only the volumes specified in the config file or created via a POST request are allowed to be emulated upon by the emulator and appear as libvirt volumes in the libvirt virtualization backend. Volumes other than these can neither be listed nor deleted.
To allow libvirt volumes to be emulated upon, they need to be specified in the configuration file in the following format (keyed compositely by the System UUID and the Storage ID):
SUSHY_EMULATOR_VOLUMES = {
('da69abcc-dae0-4913-9a7b-d344043097c0', '1'): [
{
"libvirtPoolName": "sushyPool",
"libvirtVolName": "testVol",
"Id": "1",
"Name": "Sample Volume 1",
"VolumeType": "Mirrored",
"CapacityBytes": 23748
},
{
"libvirtPoolName": "sushyPool",
"libvirtVolName": "testVol1",
"Id": "2",
"Name": "Sample Volume 2",
"VolumeType": "StripedWithParity",
"CapacityBytes": 48395
}
]
}
The Volume resources can be revealed by querying Volumes resource for the corresponding System and the Storage.
curl http://localhost:8000/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Volumes
{
"@odata.type": "#VolumeCollection.VolumeCollection",
"Name": "Storage Volume Collection",
"Members@odata.count": 2,
"Members": [
{
"@odata.id": "/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Volumes/1"
},
{
"@odata.id": "/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Volumes/2"
}
],
"@odata.context": "/redfish/v1/$metadata#VolumeCollection.VolumeCollection",
"@odata.id": "/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Volumes",
}
A new volume can also be created in the libvirt backend via a POST request on a Volume Collection:
curl -d '{"Name": "SampleVol",\
"VolumeType": "Mirrored",\
"CapacityBytes": 74859}' \
-H "Content-Type: application/json" \
-X POST \
http://localhost:8000/redfish/v1/Systems/da69abcc-dae0-4913-9a7b-d344043097c0/Storage/1/Volumes