OpenStack Compute (nova)

windows image boot failed: "a disk read error occured"

Bug #911616 reported by tungvs
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
High
Unassigned

Bug Description

I'm using Diablo. I've created a windows 2003 RAW image, published it to glance and started to create instances from it successfully. It works fine with m1.tiny template, but does not work with others (like m1.small). When launching from m1.small template, I've got an "a disk read error occur" error message.

So I think of a chance that the storage which is attached in the m1.small template has interfered with the disk order from windows image.

Linux images work fine.

Revision history for this message
tungvs (j-mailer-regs) wrote :

Edit:

Seem like any other templates failed with my windows 2003 image, same error message "a disk read error occur". I even created new templates which are the same as m1.tiny by nova-manage but the error persists. I can run Linux instances (ubuntu+centos) with these templates.

tungvs (j-mailer-regs)
summary: - windows image cannot start from template with storage
+ windows image boot failed: "a disk read error occured"
Revision history for this message
Vish Ishaya (vishvananda) wrote :

can you try commenting out the following:

105 utils.execute('e2fsck', '-fp', image, check_exit_code=False)
106 utils.execute('resize2fs', image, check_exit_code=False)

from nova/virt/disk/api.py (in the extend method)

it attempts to resize the base drive on non m1.tiny images, so I'm wondering if it is somehow corrupting the disk. The other possibility is as you say that the drives are attaching in the wrong order. could you attach the libvirt.xml from the instances directory from one of the failing instances?
usually in something like /var/nova/instances/instance-xxxxx/libvirt.xml

Changed in nova:
status: New → Triaged
importance: Undecided → High
Revision history for this message
tungvs (j-mailer-regs) wrote :

I'm trying some other software now, so lack of servers to try this. Hope others could test this bug.

Revision history for this message
livemoon (mwjpiero) wrote :

e2fsck error occurs when I resize my image in other flavor, If I use "e2fsck" check the image, it show:

root@controller:/data/stack/glance/images# e2fsck -fp bfd0d705-281c-4ee1-a896-bf4c0d6c1f94
e2fsck: Bad magic number in super-block while trying to open bfd0d705-281c-4ee1-a896-bf4c0d6c1f94
 bfd0d705-281c-4ee1-a896-bf4c0d6c1f94:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
 is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

So I cannot use flavor that need resize disk in essex4

Monsyne Dragon (mdragon)
Changed in nova:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.