The below was a test of the Storage Performance Development Kit (SPDK) on a Fedora 35 VM, presenting an NVMeoTCP (NVMeoF/TCP, NVMe/TCP) LUN to a vSphere ESXI 7.0u3d host.
The Fedora 35 VM has a Paravirtual boot disk, and a 100 GB virtual NVMe drive. Both of the VMDKs that make up these two drives are actually on an iSCSI datastore on the ESXi Host with a single TCP path, no MPIO/RR, over a 40 GBps network.
Hypervisor: VMware ESXi, 7.0.3, 19482537
Model: PowerEdge R730xd (Maximum Performance Profile)
HBA: Dell HBA330 Mini (Embedded, Firmware: 16.17.01.00) - Passed Through to VM
Enclosure: BP13G+EXP 0:1 (No "Split Mode" Backplane)
Processor Type: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
Logical Processors: 88
Drives: 24x SAMSUNG MZILS1T9HEJH0D3
Drive Size: 1788.50 GB
Block Size: 512 bytes
Bus Protocol: SAS
import asyncio
import json
import os
from autobahn.asyncio.wamp import ApplicationSession, ApplicationRunner
from collections import OrderedDict
from custom_encoder import CustomEncoder
from datetime import datetime, timedelta
from db import DB
Other helpful Links:
https://kubevirt.io/user-guide/operations/virtctl_client_tool/
https://kubevirt.io/user-guide/virtual_machines/service_objects/
https://www.opensourcerers.org/2020/11/30/first-steps-with-openshift-virtualization/
NOTE: Depending on access needed, use EITHER ClusterIP or NodePort, not BOTH as NodePort will allow for internal AND external communication; whereas ClusterIP in internal only.
Helpful Links:
https://github.com/kubevirt/containerized-data-importer/blob/main/doc/datavolumes.md
https://docs.openshift.com/container-platform/4.11/virt/virtual_machines/cloning_vms/virt-cloning-vm-disk-into-new-datavolume.html
https://cloud.redhat.com/blog/creating-default-os-images-to-auto-clone-in-openshift-virtualization
https://kubevirt.io/user-guide/virtual_machines/disks_and_volumes/
Create DataVolume NFS:
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
The below Windows 10 VM is migrated from a vanilla Windows 10 VM creaed in ESXi/vSphere and migrated to OpenShift via the Migration Toolkit for Virtualization (MTV). Pre-migration, there were NO vmware tools installed in the VM.
One strange behavior witnessed is: Do VirtIO drivers automatically get installed post MTV migration? Last night I set up a fresh Windows 10 VM and migrated it and it installed VirtIO drivers on it's own and rebooted! Where did the drivers come from? The VM should have had no knowledge of VirtIO devices, and the only thing I can think of is these are avilable in Windows update?
Additionally, I do wonder if https://github.com/kubev2v/forklift-controller/issues/468 is related as upon migration, secure boot is improperly flagged on the VM, and upon successful migration into OpenShift, Secure Boot must be manually disabled in UEFI BIOS at least one time to get the VM to boot. Upon successful boot, upon reboot, Secure Boot is re-enabled on it's own (In UEFI BIOS, but not YAML configurat
Here is the order of operations I followed (All as root):
This is the python 3.6 document to reference (Changing the applicable commands for rh-python38 instead of 36):
https://developers.redhat.com/blog/2018/08/13/install-python3-rhel#installation_prerequisites
Optional (For GCC, make, and git): $ yum install @development
This installs python 3.8 into /opt/rh/:
$ yum clean all
Disable Default Nvidia Device Plugin in Nvidia GPU Operator ClusterPolicy:
devicePlugin:
config:
default: ''
name: ''
enabled: false
imagePullPolicy: Always
https://www.youtube.com/watch?v=lud0C-K3ya0
https://kubevirt.io/user-guide/virtual_machines/host-devices/
There is this too, but I haven't tried it: