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@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