Taking a snapshot increases the number of blocks on the guest harddrive => fixed in svn

[rshaw]

This seems to be applicable to iSCSI backed mediums:

Expected results: Taking a snapshot does not alter drive block count

Observed results: Taking a snapshot increases the number of blocks the drive reports to have

Steps to reproduce (These steps assume a linux host which has tgtadm installed):

1. Create a dd file with known number of blocks

dd if=/dev/zero of=bug_demo.dd count=10000

2. Create loopback block device for iSCSI target

sudo losetup /dev/loop0 bug_demo.dd

3. Verify number of blocks in block device

sudo blockdev --getsize /dev/loop0 
10000

4. Use iSCSI software to expose block device as target

sudo tgt-setup-lun -d /dev/loop0 -n bug_demo

5. Verify target

ryan@TehDualLinux:~/bug$ sudo tgtadm --lld iscsi --mode target --op showTarget 1: iqn.2001-04.com.TehDualLinux-bug_demo
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
            Size: 0 MB, Block size: 1
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: null
            Backing store path: None
            Backing store flags: 
        LUN: 1
            Type: disk
            SCSI ID: IET     00010001
            SCSI SN: beaf11
            Size: 5 MB, Block size: 512
            Online: Yes
            Removable media: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /dev/loop0
            Backing store flags: 
    Account information:
    ACL information:
        ALL

6. Attach iSCSI target to a virtual machine of choice (note, I used an IDE controller).

VBoxManage storageattach "Ubuntu" --storagectl "IDE" --port 0 --device 1 --type hdd --medium iscsi --server localhost --target "iqn.2001-04.com.TehDualLinux-bug_demo" --lun 1 --tport 3260 --mtype normal

7. Attach a CD in order to bootup VM inside of a live linux distro. From within the guest, verify size of added disk

sudo blockdev --getsize /dev/sda 
10000

8. Shutdown VM, take an offline snapshot, and power back on into previous live linux enviornment. Verify size of disk.

sudo blockdev --getsize /dev/sda 
10240

9. Disk has grown by 240 blocks. Open up wireshark, filter on the iSCSI protocol. Observe how when reading past the end of the drive (LBA 9999), VBox actually begins issuing iSCSI commands to read the beginning of the drive (acccessing LBA 0,1, etc).

10. Open up log file for machine. You will find errors such as:

00:00:09.073586 PIIX3 ATA: LUN#1: disk read error (rc=VERR_INVALID_PARAMETER iSector=0x2780 cSectors=0x8)

10. Note the sector value in the above errors when converted to decimal are all past the valid number of blocks the drive should have.

[rshaw]

Additional notes - the wrap around as mentioned in step 9 occurs when using a SATA interface, it gets an IO error when using IDE.

The block count difference seems to be a characteristic of VBox due to a megabyte alignment requirement. If using an image that is generated on megabyte alignment (2^20 bytes) this problem does not present itself. If it is not generated on this alignment, the image will pad itself until it is megabyte aligned, but only after a snapshot has been taken.

[aeichner]

Thanks for the report! This bug will be fixed in the next maintenance release.

[Frank Mehnert]

Fix is contained in VBox 4.2.12.