Conversation
LVM volumes do not have a volume type and after a reload the value is set to nil. 0277e9b introduced that reload after saving. The mock driver doesn't properly show this behavior, which is why it was missed. A test is added to simulate the real world behavior. Fixes: 0277e9b ("Correctly load volumes after creation and cloning") Link: https://libvirt.org/formatstorage.html#storage-volume-target-elements Link: https://libvirt.org/storage.html#valid-logical-volume-format-types
|
@nofaralfasi mind taking a look? I take https://community.theforeman.org/t/invalid-libvirt-xml-unknown-driver-format-value/43081/10 as a confirmation that it works. |
|
With this reproducer, the output does not change: Gemfile: Changing the Gemfile back to 0.12.0, it works: |
|
Handling a nil volume_type when creating the server might fix the issue with Foreman though, but it's IMO more of a workaround. |
|
@mxey as indicated in the linked resources, this is mirroring what libvirt internally does. LVM doesn't have a format type so pretending it does doesn't make sense. |
OK, then the default |
|
I debated dropping the default of raw. Might still revisit that |
LVM volumes do not have a volume type and after a reload the value is set to nil. 0277e9b introduced that reload after saving. The mock driver doesn't properly show this behavior, which is why it was missed. A test is added to simulate the real world behavior.
Fixes: 0277e9b ("Correctly load volumes after creation and cloning")
Link: https://libvirt.org/formatstorage.html#storage-volume-target-elements
Link: https://libvirt.org/storage.html#valid-logical-volume-format-types
Fixes #169