Azure Rocky image on marketplace

I was able to download then upload this image. It boots within Azure - as I can see from the serial console, and I can also connect to it by IP and get an SSH prompt. However, I’m unable to determine how to login or otherwise set an initial username and password. I tried with and without following the cloud-init steps as documented at Use cloud-init to add a user to a Linux VM on Azure - Azure Virtual Machines | Microsoft Docs . The VM also reports that the “virtual machine agent status is not ready”, which then prevents me from being able to use Azure’s VMAccessForLinux extension to reset credentials.

I’m not sure I’m posting in the correct location but the perfect is the enemy of the good.

CIQ recently published Rocky 8.6 and 9.0 images in Azure in both “community” and “supported” variants. The supported variants have CSP enabled. I have successfully started 8.6 and 9.0 azure vm’s from these images using the azure azureuser convention for the initial user (which also allows sudo).

If there’s a better place to announce these sorts of things, please direct me to the proper place, ty.

3 Likes

@neil - Calling attention back to this again, please? The CIQ images here look very compelling! (At least some of the organizations I work with will be nervous about using 3rd-party images.) Just hoping we can promptly see the same directly from the Rocky Linux Foundation here. Note also my above reply, where I wasn’t otherwise able to get the VHD you provided working.

1 Like

Yessir. I apologize for the delay–i have been busy with work and personal life items as of late and this fell on the backburner.

There were some validation issues with the image, as you’ve seen, but I have resolved them and uploaded a new version that I’ve re-kicked the publishing process on now.

Best,
Neil

2 Likes

Sorry to bother, but any further updates or progress here? Thanks!

Hi folks - We don’t have the new publisher ID yet. I am planning to release the 9.1 and 8.7 images in November (or so) with the new publisher ID.

The 9.0 image should be available here: https://azuremarketplace.microsoft.com/en-us/marketplace/apps/erockyenterprisesoftwarefoundationinc1653071250513.rockylinux-9?tab=Overview – but it may take a bit after I post this for it to show up.

I will also be writing up some docs soon (really simple ones for now) on the image, what it provides, how it’s built, and importantly how it’s organized on the marketplace. I would value everyone’s input on that once I start putting it together. I know there have been a lot of comments on this thread with great suggestions of how to organize the offers, and want to make sure we can integrate whatever makes sense for ease of use for the users, balanced with simplicity for administration.

Thank you again for your patience, and please look forward to this process being automated very soon :slight_smile:

1 Like

Hi Neil, I was wondering if you had any update? As this is blocking our migration to Rocky 9 as we don’t have a non payment plan image we can migrate to. We are still using our Rocky migrated CentOS 8 image. Thanks in advance and I hope you are having a nice Christmas.

Hi, hi,

I was checking our recent invoices and saw that using managed disks is adding up. Is it possible to remove the requirement to use managed disks?

Thanks for all the work getting Rocky on Azure! :slight_smile:

For even just my own future reference, I’m still finding too many limitations on the current marketplace offerings - at the moment, including not having a 9.x release available in Azure Government (at least).

I found a list of images at Index of /pub/rocky/9/images/x86_64/ (rockylinux.org) . Is there a further README or any other details on these images? I.E., it appears that these are all currently identical - sharing the same size and checksum:

Rocky-9-Azure-Base.latest.x86_64.vhd
Rocky-9-Azure-LVM-9.2-20230513.0.x86_64.vhd
Rocky-9-Azure-LVM.latest.x86_64.vhd
Rocky-9-Azure.latest.x86_64.vhd

I’m about to try to deploy a new VM from here, will plan to update with any further challenges or findings.

The sizes are the same because that’s how they’re generated (and that’s how they have to be as far as I know). The checksums are not the same though. You can verify the checksums either in the directory you linked to or here. The current wiki is a bit limited on what’s going on there, but the cloud sig wiki may have a more detailed explanation in the future. What I can say is the “base” image is exactly how it sounds, and the LVM variant are versions of the images but with LVM partitions.

# Rocky-9-Azure-Base-9.2-20230513.0.x86_64.vhd: 10737418752 bytes
SHA256 (Rocky-9-Azure-Base-9.2-20230513.0.x86_64.vhd) = 6a84465db4768e71407102da4c172d9f4de11c378255f5f266f2b3d912e86c4c
# Rocky-9-Azure-Base.latest.x86_64.vhd: 10737418752 bytes
SHA256 (Rocky-9-Azure-Base.latest.x86_64.vhd) = 6a84465db4768e71407102da4c172d9f4de11c378255f5f266f2b3d912e86c4c
# Rocky-9-Azure.latest.x86_64.vhd: 10737418752 bytes
SHA256 (Rocky-9-Azure.latest.x86_64.vhd) = 6a84465db4768e71407102da4c172d9f4de11c378255f5f266f2b3d912e86c4c
# Rocky-9-Azure-LVM-9.2-20230513.0.x86_64.vhd: 10737418752 bytes
SHA256 (Rocky-9-Azure-LVM-9.2-20230513.0.x86_64.vhd) = 83e8650dfe5920fa1f9f9ce869d7b4ada26dfb796fb60c1863a018fe16ae20ce
# Rocky-9-Azure-LVM.latest.x86_64.vhd: 10737418752 bytes
SHA256 (Rocky-9-Azure-LVM.latest.x86_64.vhd) = 83e8650dfe5920fa1f9f9ce869d7b4ada26dfb796fb60c1863a018fe16ae20ce

With that said though, I would recommend checking out the Shared Compute Gallery rocky-dc1c6aa6-905b-4d9c-9577-63ccc28c482a. When @neil is available (he maintains the cloud images we build), he can add more info here if I’ve missed something.

Thanks. Sorry, I was a little lazy - there are effectively 2 images here - LVM and not - for a total of 2 distinct checksums at present. :slight_smile:

Thank you for the additional links!

1 Like

Just following-up: Creating the VM from the above VHDs was largely painless. There is no default user created (appropriate for security). Either direct it’s creation using cloud-init during provisioning from the VM - or wait until the VM comes up, and then use the Azure “Reset Password” function to reset it (preferably, by providing an SSH public key) through the VMAccessForLinux extension.

The worst of this was, there is no way to copy the VHD directly from the HTTP source and have it end up where it needs to be as a Page Blob (instead of the incorrect and unusable Block Blob type) - without first downloading and then re-uploading the VHD. This is a limitation in what Azure provides, not any shortcoming of what Rocky provided here.

Best would be to use the Shared Compute Gallery, as you mentioned. This is a relatively new Azure feature - still in preview - and thank you for calling out attention that you’re already publishing to / through it. Unfortunately, it isn’t available in Azure Government yet - so I still had to resort to the above.

Hello, any update on this?

I see no offers in the MSFT Catalog. This is problematic for me as we use PowerShell to deploy our systems for governance, automation, naming, and so on.

PS C:\WINDOWS\system32> Get-AzVMImagePublisher -Location Southcentralus | where{$_.PublisherName -like “erockyenterprisesoftwarefoundationinc1653071250513”} | Select Offer

Offer

PublisherName
Offer
SKUs
Version

Windows Example:
$locName=“southcentralus”
Get-AzVMImagePublisher -Location $locName | Select PublisherName

$pubName=“MicrosoftWindowsServer”
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer

$offerName=“WindowsServer”
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus

$skuName=“2022-Datacenter”
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Sku $skuName | Select Version

Is there any documentation around the lifecycle of the versions offered? The versions available today are 8.6, 8.7, 9.0 and 9.1. That doesn’t match up to the Release Guide. We use Rocky in our on-prem environments, but want to start offering it in Azure, but are hesitant without knowing when a particular version will appear or disappear from Azure.

While it’s true that those versions are no longer supported (from a rocky linux point of view), as far as I know I don’t think we remove the older versions from any of the cloud providers. dnf install/update will always pull from the latest and we’ll always recommend updating to full when possible.

@neil would have to look into why you are unable to find 8.8 or 9.2. It may be in a different part of azure.

Thanks @nazunalika. @neil, please let me know if you’re able to look into this.

@neil @nazunalika , just to give you a little context, I work with ryan.shaut for a large ISV and we’d like to be able to use Rocky for regression testing and customer support. We certify releases of our software on various distributions of Linux, including CentOS. When we release software we confirm our release works on version X of the distribution. We support that release of our software for a couple of years after the initial release date, so if a customer reports a problem we may need to go back to the original certified OS release to make sure we’re not investigating a regression caused by a subsequent update.

What we’d like to do is get access to all the releases of Rocky in the same way we can for CentOS, Ubuntu, RHEL, etc. It’s not about getting the current updates, it’s about getting the same version of Rocky as we may have used a couple of years ago. For Azure, we’d like to be able to select 8.4 to 8.8 inclusive, and ensure that the point releases are consistent with the day of release and also consistent with the equivalent RHEL release. So if RHEL 8.6 has version X.Y.Z of a package on the day of release, Rocky 8.6 should also have version X.Y.Z, and not X.Y.Z+n, where n represents the increment in the package version that may have occured between 8.6 and 8.7. Ideally the point releases would be identical to the contents of the equivalent ISO, allowing for any changes needed to optimise the release for the cloud hypervisor.

Hope that helps clarify. Thanks!

1 Like

Firstly, thank you for providing the image in the Azure Marketplace, it’s really helpful. I do want to chime in with the “plan required” observation as well. If we query the Rocky image, we can see that it has a “plan” assigned:

az vm image show --urn erockyenterprisesoftwarefoundationinc1653071250513:rockylinux:free:latest --query “plan”

{
“name”: “free”,
“product”: “rockylinux”,
“publisher”: “erockyenterprisesoftwarefoundationinc1653071250513”
}

Compared to this image, the Alma Linux, or the old CentOS, or even the Ubuntu image - none of them have a plan associated:

az vm image show --urn almalinux:almalinux-x86_64:8-gen2:latest --query “plan”
az vm image show --urn OpenLogic:CentOS:7_9:latest --query “plan”
az vm image show --urn Canonical:0001-com-ubuntu-server-jammy:22_04-lts:latest

All of the above commands return empty i.e. no plan is associated with the image.

Requiring a plan for an image, implies the image’s terms and conditions have to be explicitly accepted by the user. This can be done on the Azure portal, or programmatically. While that might be okay for the more experienced user, for the average user who’s not aware of the nuances, or the implications of, these plans, it would cause them to think twice and likely not use the image.

It would be great if this plan can be removed from the image, assuming your intent is to always keep the image free.

Thank you again for your great work so far. Hoping this plan thing can be improved.

Hi,

Thank you for the reply here. I apologize for not getting back to this sooner.

From what I can tell, there is no way to not have a plan for a marketplace image. If you can provide any additional information, I would very much appreciate it. I will also try reaching out to our contacts in Azure to see if they have any ideas:

I created a new offer to see what is possible, and, well, I don’t see how to avoid this.

Best,
Neil

I’ve taken a deeper dive, and I believe I’ve figured out what’s going on. It has to do with the license of the Plan, not the “Plan” itself.

I will get new images published under our new Publisher account early this week.