0

I've been trying to work out how to move a VM from one region (WestUS) in one resource group to another region in another resource gorup (WestEurope).

I'm trying to do it via the portal but I'm having problems at every turn.

I have created a backup and a snapshot. I have also captured the original VM (which renders it unusable - see https://stackoverflow.com/questions/63340139/why-does-capturing-an-image-of-a-vm-in-azure-prevent-the-vm-from-being-used).

When I try to create a VM from my snapshot I get:

"Creating a virtual machine from Marketplace image or a custom image sourced from a Marketplace image requires Plan information in the request"

The only link discussing this is https://negatblog.wordpress.com/2018/10/13/azure-os-images-what-is-a-plan/ which is not helpful.

My image is not a "marketplace" image. Why do I need a 'plan'? Where do I even put this configuration information?

More generally why is something so basic as duplicating a VM so horrendously complex to achieve in practice with Azure?

0

You can move an Azure VM to another region pretty easily using Azure Site Recovery, and there are details on how to do this here.

Unfortunately, if you've not already enabled replication of the VM in site recovery you don't have the option to do that, because you captured a VM image, so the machine is no longer working. Instead you will need to create a VM in your desired region from that image. The capture image process should have created a managed image object (assuming your VM used managed disks). You can use this image to create a new VM by following the steps in this article.

Edit

So this issue seems to be related to the fact that the image in use has a fee, so you need to select a plan when deploying it. You cannot do this through the portal, so you need to use CLI or PS to do this. To create a VM from an image, specifying a plan you can do:

az vm create --name <name of new VM to create> --location <location> --image <name of image to use> --admin-username <admin username> --admin-password <admin password> --plan-name centos-8-0 --plan-product centos-8-0 --plan-publisher skylarkcloud -g <resource group for new VM>

9
  • The article does not help. From the portal there is no "edit settings" and there is not setting to set the plan. There is also no 'plan' option listed for powershell command. – Bruce Adams Aug 10 '20 at 15:28
  • Which article are you referring to? Neither of the ones I linked mention "edit settings" – Sam Cogan Aug 10 '20 at 15:30
  • "Under Settings, make changes as necessary and select OK." There are things that I would call settings but there is nothing actually labelled "settings" anywhere. And nothing to do with a 'plan' whatever that is. – Bruce Adams Aug 10 '20 at 15:36
  • What image did you use to create the VM with in the first place, was it standard windows image, or did you use something else? – Sam Cogan Aug 10 '20 at 15:41
  • I am trying to use a snapshot created from a (CentOS8 Linux) VM. I have the same problem with a capture created from the same VM though. – Bruce Adams Aug 10 '20 at 15:51
1

Plan information is metadata Microsoft uses to track Marketplace offers. If you're being prompted for Plan, you have a Marketplace offer--even if it's free. Plan metadata has three parts--Publisher, Offer/Product, and Name/Sku. Depending on where you look, they're referenced differently.

Plan information never changes. It is tattooed into the vhd somehow--I have yet to find out how, but it must be on disk somewhere.

If you're building a VM in Powershell, you just use the Set-AzPlan cmdlet to include the plan data before you create the VM. I don't create a lot thru Powershell, but I've grown into it specifically for Marketplace images.

Undocumented feature--if your publisher pulls the offer that you're using, you will NEVER be able to create a VM with it again. Not from an ASR failover. Not from a backup. So keep an eye on your versions.

I just spent the last 10 hours trying every way I could to recover a VM because the publisher had removed all versions prior to 10.6 of their software. My customer, even tho they're on a fully supported 10.5.1 release, is now fairly hosed.

I even created a HyperV host, downloaded the VHDs and tried to ASR the VM back into Azure to fool it into thinking there was no way this could be a Marketplace image..... no joy.

Couple of very helpful Powershell tidbits for working with Plan: Get-AzVMImageOffer -PublisherName "PUBLISHER" -Location "EastUS" | Get-AzVMImageSku (Lists all SKU/Offer/Publisher combinations in the given region for the given publisher)

Get-AzMarketplaceTerms -Publisher $azureVmPublisherName -Product $azureVmOffer -Name $azureVmSkus | Set-AzMarketplaceTerms -Accept (If you're creating a new VM in Powershell and it's the first time you're deploying this Plan, you have to accept the Marketplace Terms)

Bottom line: Marketplace is great for appliances. We get their lifecycle. Avoid it like the plague for long(er)-term servers. Go to the Virtual Machines list, hit + Add, and pick an OS from the stock drop box they give you.

3
  • That is very nasty. Can you get Microsoft to intervene in this instance? I've linked your answer here – Bruce Adams Oct 23 '20 at 10:38
  • That's just it. Because the Marketplace is what it is, Microsoft is really off the hook. They'll say the problem lies with the publisher. And the publishers aren't Azure experts. I do not believe for a second that this publisher meant to create the kind of infrastructure problems they are. They're just trying to make sure folks buy the latest version of their stuff. But the trail of downstream consequences is unpleasant. – James Oct 23 '20 at 14:23
  • Bruce, saw your other thread about removing Plan info (I can't comment there, or I would, so adding it here). The Plan information is tattooed into the hard disk somewhere. I went so far as to export the VHD to a HyperV VM, replicate it back into Azure with ASR, and it still detected it as a Marketplace image. I spent a weekend digging around the disk's files, but couldn't find anything in the filesystem to indicate it. It has to be in the VHD metadata somehow, but I don't know a way to get at that to validate (or change) said metadata. – James Nov 10 '20 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.