Now that I think again, I am not sure if the below is really needed ?
<driver... being an optional sub-element, it should be ok for it not
to be present in the returned XML, which means the consumer
should make appropriate checks and handle the presence/absence
of <driver....> accordingly.... I think that is correct.
On 12/21/2011 11:17 AM, Deepak C Shetty wrote:
While adding support for fs driver sub-element in virt-manager
(vmm) it throws a python exception/error when one tries to list
fs device (in details window) that has default driver selected.
Root causing that leads to libvirt not setting the default
driver when the input xml does not carry one, which is the case
when user selects default driver in vmm. As part of vmm's
add new fs device flow, libvirt's DefineXML gets called which
does not add the<driver...> sub-element in case of default
fs driver selected in vmm. This patch fixes that.
Signed-off-by: Deepak C Shetty<deepakcs@xxxxxxxxxxxxxxxxxx>
---
src/conf/domain_conf.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 4be8fe0..8b89a0b 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3318,6 +3318,8 @@ virDomainFSDefParseXML(xmlNodePtr node,
_("unknown fs driver type '%s'"), fsdriver);
goto error;
}
+ } else {
+ def->fsdriver = VIR_DOMAIN_FS_DRIVER_TYPE_PATH;
}
if (source == NULL) {
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list