Comment 16 for bug 1251590

Revision history for this message
Nikola Đipanov (ndipanov) wrote : Re: Live migration can leak root disk into ephemeral storage

>I'm a bit confused on the multiple ephemeral disk code. It appears that regardless of the number of disks created, the backing file is the same. ie fname = "ephemeral_%s_%s" % (eph['size'], os_type_with_default) is not dependent on idx. So I'm wondering if only ephemeral0 will be used in the backing file and the rest used in the qcow2 layers. If that's the case we hardcoding 'ephemeral0' for fs_label won't break anything.

so - we go back to the size issue - each ephemeral drive will have a backing file (assuming qcow Images are used by Nova) that is named
  fname = "ephemeral_%s_%s" % (eph['size'], os_type_with_default)
the sizes however can vary from device to device, so if we have for example an instances that allows ephemeral to be 100G we could have a disk of 50 and two disks of 25 - this will result in two backing files ephemeral_25_blah and ephemeral_50_blah and 3 qcow overlays - two that have the 25 one as base and one that has 50.

The fs_label is applied to the original file when created and it makes no sense for it to be ephemeral0,1 etc... or we should be formatting the newly created overlay which kind of defeats the purpose of having backing files. I will likely file a separate bug for this

Also Tom is right wrt size. The thing is - we will not be getting the real size here, as the user could have overriden it through block device mapping, and we do not save that in the xml.

In the long run - we should really be using the db data to do this and not only the xml, but that is definitely outside of the scope of the bugfix - so as soon as you fix the swap issue - I am +2 on this.