should not provide /etc/cloud/cloud.cfg.d/91_walinuxagent.cfg

On which releases ds-identify is enabled by default? E.g. do we need to keep that snippet for e.g. xenial/yakkety?

cloud-init uses ds-identify on yakkety+ at this point.
xenial is still in reporting only mode.

Perhaps we should hold this fix in xenial until the point in which cloud-init enables ds-identify there.
That said, its not strictly necessary as the shortened list doesn't really do much except for stop some other datasources from doing their quick check.

This bug prevents me from using NoCloud datasource with http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.vhd.zip and Hyper-V on Windows Server 2012r2.

Cloud-init will not load settings from nocloud.iso attached to vm unless I delete /etc/cloud/cloud.cfg.d/91_walinuxagent.cfg file.

Snippet from the logs:

Before removing:

2018-01-17 00:43:43,241 - __init__.py[DEBUG]: Looking for for data source in: ['Azure'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
2018-01-17 00:43:43,297 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceAzure']
2018-01-17 00:43:44,481 - __init__.py[DEBUG]: Looking for for data source in: ['Azure'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM', 'NETWORK']
2018-01-17 00:43:44,503 - __init__.py[DEBUG]: Searching for network data source in: []
cloudinit.sources.DataSourceNotFoundException: Did not find any data source, searched classes: ()

After removing the file:

2018-01-17 01:03:02,335 - __init__.py[DEBUG]: Looking for for data source in: ['NoCloud', 'ConfigDrive', 'OpenNebula', 'DigitalOcean', 'Azure', 'AltCloud', 'OVF', 'MAAS', 'GCE', 'OpenStack', 'CloudSigma', 'SmartOS', 'Bigstep', 'Scaleway',
'AliYun', 'Ec2', 'CloudStack', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM']
2018-01-17 01:03:02,480 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud', 'DataSourceConfigDrive', 'DataSourceOpenNebula', 'DataSourceDigitalOcean', 'DataSourceAzure', 'DataSourceOVF', 'DataSourceCloudSigma',
'DataSourceSmartOS', 'DataSourceEc2Local']

Kryzsztof,

I'm curious why you would use the .vhd file. Is there something specific that you wanted from it *other* than the format of the disk image?

If not, then you most likely can just grab the .img file (qcow2) and use qemu-img to convert it to vhd.

I do realize that converting a disk image is a pain, and sometimes more painful than it should be.
And in the past I know I had to employ vboxconvert (from virtualbox) to get something that windows was happy with. https://gist.github.com/smoser/5364534 might be of assistance, but I failed to document it well enough and a lot of context is since left my head.

On Wed, Jan 17, 2018 at 03:32:32PM -0000, Scott Moser wrote:
> I'm curious why you would use the .vhd file. Is there something
> specific that you wanted from it *other* than the format of the disk
> image?

The VHD contains Hyper-V-specific customisations (such as the
linux-azure kernel), so there is a compelling reason to want to use it.

This bug was fixed in the package walinuxagent - 2.2.21+really2.2.20-0ubuntu2

---------------
walinuxagent (2.2.21+really2.2.20-0ubuntu2) bionic; urgency=medium

  * Do not provide config to cloud-init specifying datasource_list.
    (LP: #1700769)

 -- Scott Moser <email address hidden> Fri, 23 Feb 2018 13:17:20 -0500