OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
e688df6bc4
qemu-e2k/tests/qemu-iotests/146.out

71 lines
1.9 KiB
Plaintext
Raw Normal View History

block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
QA output created by 146
=== Testing VPC Autodetect ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
126.998 GiB (0x1fbfe04000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing VPC with current_size force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
127 GiB (0x1fc0000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing VPC with chs force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
126.998 GiB (0x1fbfe04000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing Hyper-V Autodetect ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
127 GiB (0x1fc0000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing Hyper-V with current_size force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
127 GiB (0x1fc0000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing Hyper-V with chs force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
126.998 GiB (0x1fbfe04000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing d2v Autodetect ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
251.250 MiB (0xfb40000) bytes allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing d2v with current_size force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
251.250 MiB (0xfb40000) bytes allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
=== Testing d2v with chs force ===
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
251.250 MiB (0xfb40000) bytes allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Testing Image create, default ===
Formatting 'TEST_DIR/IMGFMT-create-test.IMGFMT', fmt=IMGFMT size=4294967296
=== Read created image, default opts ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x10007a000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Read created image, force_size_calc=chs ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x10007a000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Read created image, force_size_calc=current_size ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x10007a000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Testing Image create, force_size ===
Formatting 'TEST_DIR/IMGFMT-create-test.IMGFMT', fmt=IMGFMT size=4294967296 force_size=on
=== Read created image, default opts ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x100000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Read created image, force_size_calc=chs ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x100000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: add tests for image creation force_size parameter Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:30 +01:00
=== Read created image, force_size_calc=current_size ====
qemu-io: Switch 'map' output to byte-based reporting Mixing byte offset and sector allocation counts is a bit confusing. Also, reporting n/m sectors, where m decreases according to the remaining size of the file, isn't really adding any useful information; and reporting an offset at both the front and end of the line, with large amounts of whitespace, is pointless. Update the output to use byte counts and shorter lines, then adjust the affected tests (./check -qcow2 102, ./check -vpc 146). Note that 'qemu-io map' is MUCH weaker than 'qemu-img map'; the former only shows which regions of the active layer are allocated, without regards to where the allocation comes from or whether the allocated portion is known to read as zero (because it is using the weaker bdrv_is_allocated()); while the latter (especially in --output=json mode) reports more details from bdrv_get_block_status(). Signed-off-by: Eric Blake <eblake@redhat.com> Message-id: 20170429191419.30051-4-eblake@redhat.com Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-04-29 21:14:13 +02:00
4 GiB (0x100000000) bytes not allocated at offset 0 bytes (0x0)
block/vpc: tests for auto-detecting VPC and Hyper-V VHD images This tests auto-detection, and overrides, of VHD image sizes created by Virtual PC, Hyper-V, and Disk2vhd. This adds three sample images: hyperv2012r2-dynamic.vhd.bz2 - dynamic VHD image created with Hyper-V virtualpc-dynamic.vhd.bz2 - dynamic VHD image created with Virtual PC d2v-zerofilled.vhd.bz2 - dynamic VHD image created with Disk2vhd Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2016-02-25 18:27:28 +01:00
*** done
Reference in New Issue Copy Permalink