This works fine on Fedora 17:

$ virt-alignment-scan -a test.img 
/dev/sda1        65536           64K   ok

libguestfs-1.17.32-1.fc17.x86_64
parted-3.0-7.fc17.x86_64

The two commands that run in RHEL 6 are:

  parted -s -m /dev/null
  parted -m -- /dev/vda unit b print

The first command is used to test whether the -m option
works in this version of parted.  The output on RHEL 6 is:

  $ parted -s -m /dev/null
  Error: The device /dev/null has zero length, and can't possibly store a file system or partition table.  Perhaps you selected the wrong device?
  Warning: Error fsyncing/closing /dev/null: Invalid argument

(ie. -m is supported).  The second command is used to fetch
the partition table.  /dev/vda there refers to the device containing
'test.img'.  Running the same command in virt-rescue gives:

  ><rescue> parted -m -- /dev/vda unit b print
  Error: Can't have the end before the start! (start sector=16065 length=-7873)
  BYT;
  /dev/vda:4194304B:virtblk:512:512:msdos:Virtio Block Device;
  1:65536B:4194303B:4128768B:::;

(Note that the error message goes to stdout, FFS).

So that reveals why we can't parse the output.

Note there is no error when the same command is run on the same
image on Fedora 17.

I had a long comment written here about how this was a bug in sfdisk
but I noticed I can reproduce exactly the same problem using parted
alone:

$ rm -f test2.img ; truncate -s 4M test2.img
$ parted -s -- test2.img mklabel msdos
$ parted -s -- test2.img mkpart primary 1s -1s
Warning: The resulting partition is not properly aligned for best performance.
$ virt-alignment-scan -a test2.img 
libguestfs: error: part_list: could not parse row from output of parted print command: /dev/vda:4194304B:virtblk:512:512:msdos:Virtio Block Device;

It's very hard to reproduce this bug in a standalone
test of parted, because it is triggered by the geometry
returned by the virtio-block device.  You can't reproduce
it using a simple file or a non-virtio partition.

I think the quickest way to fix this is going to
be to fix the gerrit test.  If you use a sufficiently
large file, say 1G, then you won't hit this bug at all:

$ rm -f test2.img ; truncate -s 1G test2.img
$ parted -s -- test2.img mklabel msdos

then either:

$ parted -s -- test2.img mkpart primary 1s -1s
Warning: The resulting partition is not properly aligned for best performance.

or:

$ parted -s -- test2.img mkpart primary 128s -1s
Warning: The resulting partition is not properly aligned for best performance.

then:

$ virt-alignment-scan -a test2.img 

As general advice: don't use sfdisk for anything, ever.

Moving to 6.4, on the basis that:

(a) Does affect a customer.
(b) Can be worked around easily by making a small change to gerrit test.
(c) "Hot" partitioning code path.
(d) Late in RHEL 6.3 for an invasive change.
(e) Doesn't affect upstream code.

(In reply to comment #5)
> (a) Does affect a customer.

Ummm .. Does NOT affect a customer!

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Moving to 6.5, for the same reasons as outlined
in comment 5.

Note that this is really a bug in parted, not in
libguestfs.  If parted sent error messages to stderr
then we wouldn't have so much trouble parsing the
output.

I already sent a patch upstream (to parted) to fix
the generic parted problems without stdout vs stderr:

http://lists.alioth.debian.org/pipermail/parted-devel/2011-October/003944.html

Since we're probably not going to fix this in RHEL 6, and it
works in RHEL 7, I'm closing this bug.  See comment 5 for further
details.