On 01/23/2014 08:45 PM, Adam Walters wrote:
This patch fixes the secret type checking done in the
virDomainDiskDefParseXML function. Previously, it would not allow any
volumes that utilized a secret. This patch is a simple bypass of the
checking code for volumes.
Signed-off-by: Adam Walters <adam(a)pandorasboxen.com>
---
src/conf/domain_conf.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 28e24f9..773dc26 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -5418,7 +5418,8 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt,
cur = cur->next;
}
- if (auth_secret_usage != -1 && auth_secret_usage != expected_secret_usage)
{
+ if (auth_secret_usage != -1 && auth_secret_usage != expected_secret_usage
&&
+ def->type != VIR_DOMAIN_DISK_TYPE_VOLUME) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("invalid secret type '%s'"),
virSecretUsageTypeTypeToString(auth_secret_usage));
So an rbd volume can have a secret when the pool has auth set to none?
Otherwise it seems the volume's secret data might get overwritten by
qemuTranslateDiskSourcePoolAuth.
And this could also be added to qemuxml2argvtest.
@@ -18214,7 +18215,8 @@
virDomainDiskDefForeachPath(virDomainDiskDefPtr disk,
if (!disk->src || disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK ||
(disk->type == VIR_DOMAIN_DISK_TYPE_VOLUME &&
disk->srcpool &&
- disk->srcpool->mode == VIR_DOMAIN_DISK_SOURCE_POOL_MODE_DIRECT))
+ (disk->srcpool->mode == VIR_DOMAIN_DISK_SOURCE_POOL_MODE_DIRECT ||
+ disk->srcpool->mode == VIR_DOMAIN_DISK_TYPE_NETWORK)))
What is the purpose of this? You are comparing the source pool mode against a
disk type constant. It seems this can never be true in this case.
Jan