cloud-init does not recognize (and mount) ephemeral partition on KVM

When a KVM-based cloud instance is launched with ephemeral volume or swap space on a partition of the root disk (e.g., /dev/vda2 and /dev/vda3), the partition is ignored and remains unmounted. In the log this looks as follows:

Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Attempting to determine the real name of ephemeral0
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] DataSourceEc2.py[DEBUG]: Remapped device name /dev/sda2 => /dev/vda2
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Mapped metadata name ephemeral0 to /dev/vda2
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: did not find entry for vda2 in /sys/block
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Ignoring nonexistant default named mount ephemeral0
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Attempting to determine the real name of swap
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] DataSourceEc2.py[DEBUG]: Remapped device name /dev/sda3 => /dev/vda3
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Mapped metadata name swap to /dev/vda3
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: did not find entry for vda3 in /sys/block
Aug 12 19:29:45 euca-172-28-165-121 [CLOUDINIT] cc_mounts.py[DEBUG]: Ignoring nonexistant default named mount swap

Earlier versions of cloud-init (e.g., one in Ubuntu 12.04) were able to use such partitions, but latter versions (e.g., one in Ubuntu 14.04) are not. It appears that a check for the block device's presence in /sys/block was added between those two versions and it is causing the failure.

This check succeeds on AWS with paravirtualized instances, where what look like partitions (/dev/xvda1, /dev/xvda2, /dev/xvda3) of a disk (/dev/xvda), are actually separate, unrelated Xen-provided block devices, each with its own entry in /sys/block. When root, ephemeral, and swap block devices are actually partitions of one KVM disk (/dev/vda), they do not end up in /sys/block.

This was discovered in a Eucalyptus installation: https://eucalyptus.atlassian.net/browse/EUCA-9251