Comment 1 for bug 862653

Okay. Spent a good bit of time tinkering w/ this issue this afternoon. The VDI resize code added in bf181c2 is absolutely the problem. If I comment it out I'm able to boot instances fine.

I'm using XenServer 5.6 SP2:

[root@xen1 ~]# cat /etc/*release
XenServer release 5.6.100-46766p (xenenterprise)

This isn't an out of space issue for my SR. The same thing appears to happen on multiple Xen Servers. The SR's are pretty big and I can boot an instance normally. Furthermore I'm also able to do instances resizes and just about anything else on these machines which are all Dell R710's.

When the instance fails to boot I can go to the machine and reproduce this manually with the following command:

[root@xen1 ~]# xe vdi-resize uuid=b8714fde-9741-4ea0-b460-15c4e8b444df disk-size=20GiB
Error code: SR_BACKEND_FAILURE_110
Error parameters: , VDI resize failed [opterr=Command ['/usr/sbin/vhd-util', 'revert', '--debug', '-n', '/var/run/sr-mount/934ab597-ff32-94f6-c1da-9213c7f02a65/b8714fde-9741-4ea0-b460-15c4e8b444df.vhd', '-j', '.journal-b8714fde-9741-4ea0-b460-15c4e8b444df'] failed (2): ],

---

Also. If I comment out this code I can boot instances fine:

- for vdi in vdis:
- if vdi["vdi_type"] == "os":
- self.resize_instance(instance, vdi["vdi_uuid"])

Furthermore. I've verified that I can resize VDI's just fine for an instance once I've started and stopped the instance. So for example if I:

1) boot an instance
2) shut it down
3) I can then resize the VDI on the command line just fine with 'xe vdi-resize' to sizes much large than 20 Gigs.

So what I'm saying is that VDI resizes appear to fail before we've spawned the instance at least once. Once we've spawned it we can shut it down and perform whatever resize we want.

---

So as far as I can tell booting instances on stock XenServer 5.6 SP2 breaks w/ this commit. Is this a XenServer issue that I need a patch to fix or something?