ISO Image storage location

[jayst136]

I'm trying to understand the .ISO file storage location logic when using only GFS2 Storage.

I've got a 3-node cluster with VME manager running and i'd like to save my .ISO file for OS installs on the GFS2 datastore.
GFS2 datastore has "image target" enabled. 
I unchecked "active" for the other (local datastores) listed.
i went ahead and created a nieuw virtual image and uploaded the ISO. 
It seems to go to this location on the VME manager:
/var/opt/morpheus/morpheus-ui/vms/morpheus-images/morpheus-virtual-images/17/ubuntu-24.04.4-live-server-amd64.iso

Why that location? How do i change that from happending? i want it on the GFS2 storage.

[abedard]

Having the same issue

Our storage doesn't support NFS, how can we make an ISO image repository on GFS2 so it's accessible to all the hosts?

[KoreyG]

There are two concepts to differentiate:

1. Virtual Image storage by the manager
2. Virtual Image storage by the cluster

The manager storage currently does not support GFS2 as a storage location for images, as GFS2 is designed for clustered systems and the manager would need to be part of the cluster in this case (using the same location) or a standalong single node using a different location.  As noted, the default location for virtual images will send to the local disk of the manger /var/opt/morpheus/morpheus-ui/vms/morpheus-images/morpheus-virtual-images/  This can can mean that the local disk of the manager may need to be increased or monitored to not run out of space.  These are the options available in this case:

1. Continue as stated above and use the local disk, increase and monitor it as needed
2. Use a supported bucket or file share for the virtual image

To use a supported bucket or file share, navigate to Infrastructure > Storage  Here are links to the Supported Bucket Types and Supported File Share Types , which you can find the one that might fit your use case and the instructions to add it.  When creating one of these, you can set it to be the Default Virtual Image Store, for example on adding a CIFS File Share:

Alternatively, you do not need to set a default if you don't want either.  When adding a Virtual Image, you can choose a Bucket or Fire Share prior to uploading the ISO/image:

In the above, the ISO/image will be stored on the Bucket/Share and this will offload the storage of the ISO/image for the manager.

For the Virtual Image store on the cluster, as noted, you can set the Image Target on a GFS2 (and other datastores) that have been added to the cluster.  This is the location that the manager will transfer a copy of the ISO/image to by default, then Instances/VMs are created from this image.  Once stored on the cluster in the Image Target, the manager won't need to transfer this file again for future deployments, since it will already be on the Image Target in the cluster.  At this point, all hosts in the cluster will have access to this ISO/image as well.

Here is more information on HVM Cluster Storage

Hope that helps!

[Arnout_Verbeken]

https://community.hpe.com/t5/hpe-morpheus-vm-essentials/disk-space-filling-up-on-host-where-vmessentails-console-is/m-p/7252607#M513

should help you understand the different "file locations" in VM Essentials

[jayst136]

Hi Arnout,

Thanks alot for this explanation. 

However, it's quite alot of mechanics to accomplish something very simple. Especially coming from VMware offcourse. i just want to create a proper simple storage location for .ISO files used to deploy different solutions within VMs.

But let's see if we can get consensus on the best practice for the scenario where we have only block storage. So FC or iSCSI arrays. It's just not practical to implement file-based storage or other type of storage for just .ISO storage. So what's the second best (?) option here?
Should we attach another disk to the manager? manually? format it with a filesystem (which one?) , mount it and specify that path as the target? 

i'm pretty sure the avarage VMware sysadmin looking to migrate ( in the blockonly scenario ) can be helped a bit better, as it is one of the first things they run into deploying VME.

[lsantiagos01]

Hi,

The ISO location is not necessarily the cluster datastore. In HPE VM Essentials, the image is added under Library > Virtual Images, and in the Add ISO workflow it is stored in the location defined in the Bucket field. If no Bucket or File Share is configured, the documentation states that the image is stored on the VM Essentials Manager itself. HPE also indicates that the actual location can be verified in the Virtual Images library by enabling the store column.

The technical documentation also clearly distinguishes:

Data Store = storage for VM disks

Buckets / File Shares = storage that can also be used for virtual image storage

Virtual Image Store = storage containing VM images and ISOs

[Arnout_Verbeken]

jayst136 , 

We use indeed a different concept compared to Vmware since the whole "design" is made from a "cloud concept".  The whole goal of the Virtual Image Store (for your ISO"s) is to have one location that can be used for all your clouds (in Morpheus Enterprise).  So it has to be "something not living in a cloud" since other clouds you might have will also use that store.

In Vmware, you only have "Vmware" so there you can just use the datastores in your Vmware environment.

So just actually need just one extra location for the ISO's, compared to Vmware.

My goto is indeed to add a 2nd disk to the VM Essentials Manager VM (which will than actually live on your real datastore). (VM - Reconfigure - add disk)

partition, format, mount, automount (fstab) this 2nd disk in the OS.  I still tend to use simple ext4 as filesystem.
Now make a new Virtual Image Repo from this "local" disk and set it as the default Repo.
The procedure is here: https://support.hpe.com/hpesc/public/docDisplay?docId=sd00007370en_us&page=GUID-953F9E2E-D9DD-4469-96EE-A288371FE36E.html

Hope this helps.

[jayst136]

ok thanks. I think that's the best option to proceed with then. Although far from ideal compared to where alot of us are coming from. Things like this need less friction. 

[abedard]

Frankly that is a lot of complicated steps to be able to perform one of the most basic functions in a hypervisor.

This sounds like one of many pretty big architectural oversites for something that should be a basic fundamental feature of the product.

With my admitedly limited exposure with VME I can't help but feel like this product is being developed backwards. The orchestration engine (Morpheus) down, instead of VM Essentials up. You should start by making a robust standalone hypervisor FIRST, not try to reverse engineer basic functionallity into what is admitedly an already bloated orchestration product (Morpheus) that the average customer will use less than 10% of throughout it's entire lifespan.

The most damning thing for me is that VME itself doesn't have a GUI. The hypervisor is cmdline only, and relies on the orchestration engine to perform GUI level tasks. So many basic functions and tasks remain cmdline only.

You have to understand that many of us VMware + Hyper-V guys we are Windows admins, not Linux admins. So having to look up Linux commands to perform basic functions like expanding disks, creating mountpoints, or changing IPs is akin to learning Chinese. Which is making learning and implementing this product unecessarily difficult, especially since the architecture is so fundamentally different to Hyper-V and VMware.

VMware and Hyper-V also have cmdline available, but at a basic operational level it's extremely rare you have to go under the hood to do anything. All of the basic fundamental tasks and configuration can be done from the GUI in a matter of minutes.

With my experience I can spin up an operational VMware host in about an hour, and a Hyper-V host in 2. I'm presently 2 weeks into this VME deployment and we haven't even been able to spin up 1 operational VM yet and have had to make 3 support calls to get to this point.

Spinning up VMs and images is one of the most basic things we need to do in VME, and this process seems to assume that we will a have large enterprise infrastructure in place already, not a bare metal deployment for 2-3 hosts. Let alone all of the complicated steps to be able to do this.

Coming from the VMware and Hyper-V world, to provision a VM you click to select a bootable ISO stored as a file in any repo you want. Typically in block storage which is accessible to all of the hosts.

Most HPE storage arrays in the lower to mid range (suitable for 3 hosts like Nimble, Alletra, and MSA) don't support NFS storage at all. So adding NFS storage for something basic like ISO storage is out of the question.

Storing ISOs and images within the Morpheus VM itself sounds like a quick way to run out of space and makes it painfully difficult to manage.

We should be able to store this data on block GFS2, and we should be able to open it like a fileshare to upload and manage or ISOs library on demand. Not having to use 3rd party tools like WinSCP either.

[jayst136]

wel to be fair, Morpheus software is not new and started different. HPE aquisition, HPE strategy for VME and current market conditions are developing some expectations from the folks coming from VMware/Hyper-V.
I don't think Morpheus Essentials is bloated (yet), not any more bloated compared to vCenter for example. I can't speak for Morpheus Enterprise, as it's out  of my interest (as i'd expect it is out of interest for most customers looking to migrate to VME).
I'm currently seeing too much things that are not intuitive for simple things like creating VMs and this ISO thing. It's just not acceptable in a block storage only environment to talk about file based storage for ISOs. Adding a disk to the manager feels dirty, as it would compare to adding a disk to vCenter for the same purpose (and you'd never do that).

[abedard]

Agreed

Enough of the big key functionality like Live Migration and Clustering exists to fill out a marketing slide deck, but there hasn't been nearly enough attention on the basic functionality that we actually need to actually operate this thing.