[libvirt] esx: What does "No storage volume with key or path" mean?
We've had a report of a particular vCenter server (using VMware clustering, we think) where virStorageVolInfo of a guest volume fails with: Storage volume not found: No storage volume with key or path '[...] ...' The error comes from esxVI_LookupFileInfoByDatastorePath: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/esx/esx_vi.c;h=f7eeeb5c539914f1a0ba8d974b49e56ecf01e5fd;hb=HEAD#l3571 What does it mean? The reporter also said they could do some (frankly voodoo) moving guests around and then the error went away. We're not sure if that was just coincidence. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] Couple of patches to resolve recent Coverity issues
Recent changes have tripped my Coverity checker. John Ferlan (3): Use virGetLastErrorMessage to avoid Coverity message admin: Clean up error path in adminServerListClients conf: Fix error path in virNodeDevPCICapabilityParseXML daemon/admin_server.c | 3 +-- src/conf/node_device_conf.c | 5 - src/network/bridge_driver.c | 3 +-- src/node_device/node_device_hal.c | 3 +-- 4 files changed, 7 insertions(+), 7 deletions(-) -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] Use virGetLastErrorMessage to avoid Coverity message
Both instances use VIR_WARN() to print the error from a failed virDBusGetSystemBus() call. Rather than use the virGetLastError and need to check for valid return err pointer, just use the virGetLastErrorMessage. Signed-off-by: John Ferlan--- src/network/bridge_driver.c | 3 +-- src/node_device/node_device_hal.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index a34da2a..f406f04 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -695,9 +695,8 @@ networkStateInitialize(bool privileged, #ifdef HAVE_FIREWALLD if (!(sysbus = virDBusGetSystemBus())) { -virErrorPtr err = virGetLastError(); VIR_WARN("DBus not available, disabling firewalld support " - "in bridge_network_driver: %s", err->message); + "in bridge_network_driver: %s", virGetLastErrorMessage()); } else { /* add matches for * NameOwnerChanged on org.freedesktop.DBus for firewalld start/stop diff --git a/src/node_device/node_device_hal.c b/src/node_device/node_device_hal.c index 6d18a87..6ddfad0 100644 --- a/src/node_device/node_device_hal.c +++ b/src/node_device/node_device_hal.c @@ -641,9 +641,8 @@ nodeStateInitialize(bool privileged ATTRIBUTE_UNUSED, dbus_error_init(); if (!(sysbus = virDBusGetSystemBus())) { -virErrorPtr verr = virGetLastError(); VIR_ERROR(_("DBus not available, disabling HAL driver: %s"), -verr->message); +virGetLastErrorMessage()); ret = 0; goto failure; } -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] admin: Clean up error path in adminServerListClients
Coverity noted that in adminServerListClients if virNetServerGetClients returns a -1 into ret, then the call virObjectListFreeCount in cleanup will not be very happy. Adjust the code to skip the cleanup label and just return -1 if virNetServerGetClients fails. Signed-off-by: John Ferlan--- daemon/admin_server.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/daemon/admin_server.c b/daemon/admin_server.c index 2fc4675..41f6e82 100644 --- a/daemon/admin_server.c +++ b/daemon/admin_server.c @@ -191,14 +191,13 @@ adminServerListClients(virNetServerPtr srv, virCheckFlags(0, -1); if ((ret = virNetServerGetClients(srv, )) < 0) -goto cleanup; +return -1; if (clients) { *clients = clts; clts = NULL; } - cleanup: virObjectListFreeCount(clts, ret); return ret; } -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] conf: Fix error path in virNodeDevPCICapabilityParseXML
If the call to virXPathNodeSet to set naddresses fails, Coverity notes that the subsequent VIR_ALLOC_N cannot have a negative value (well it probably wouldn't be negative per se). Signed-off-by: John Ferlan--- src/conf/node_device_conf.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index a06e450..aed95d5 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -1305,7 +1305,10 @@ virNodeDevPCICapabilityParseXML(xmlXPathContextPtr ctxt, data->pci_dev.physical_function) < 0) goto out; } else if (STREQ(type, "virt_functions")) { -int naddresses = virXPathNodeSet("./address", ctxt, ); +int naddresses; + +if ((naddresses = virXPathNodeSet("./address", ctxt, )) < 0) +goto out; if (maxFuncsStr && virStrToLong_uip(maxFuncsStr, NULL, 10, -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] util: set vlan tag for macvtap passthrough mode on SRIOV VFs
On 05/05/2016 12:39 PM, Laine Stump wrote: > SRIOV VFs used in macvtap passthrough mode can take advantage of the > SRIOV card's transparent vlan tagging. All the code was there to set > the vlan tag, and it has been used for SRIOV VFs used for hostdev > interfaces for several years, but for some reason, the vlan tag for > macvtap passthrough devices was stubbed out with a -1. > > This patch moves a bit of common validation down to a lower level > (virNetDevReplaceNetConfig()) so it is shared by hostdev and macvtap > modes, and updates the macvtap caller to actually send the vlan config > instead of -1. > --- > > While adding the info to the docs, I got a bit carried away fixing up > the vlan-specific paragraphs. It someone really wants me to I can move > it into a separate patch, but it seemed like more trouble than it was > worth at the time... > > > docs/formatdomain.html.in | 61 > +++-- > src/lxc/lxc_process.c | 3 ++- > src/network/bridge_driver.c | 17 - > src/qemu/qemu_interface.c | 1 + > src/util/virhostdev.c | 23 ++--- > src/util/virnetdev.c| 29 + > src/util/virnetdev.h| 6 +++-- > src/util/virnetdevmacvlan.c | 4 ++- > src/util/virnetdevmacvlan.h | 2 ++ > 9 files changed, 86 insertions(+), 60 deletions(-) > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > index 97794b7..68f0295 100644 > --- a/docs/formatdomain.html.in > +++ b/docs/formatdomain.html.in > @@ -4032,7 +4032,7 @@ > >On Linux systems, the bridge device is normally a standard Linux >host bridge. On hosts that support Open vSwitch, it is also > - possible to connect to an open vSwitch bridge device by adding > + possible to connect to an Open vSwitch bridge device by adding >a virtualport type='openvswitch'/ to the >interface definition. (Since >0.9.11). The Open vSwitch type virtualport accepts two > @@ -4816,34 +4816,47 @@ qemu-kvm -net nic,model=? /dev/null > > >If (and only if) the network connection used by the guest > - supports vlan tagging transparent to the guest, an > + supports VLAN tagging transparent to the guest, an >optional vlan element can specify one or > - more vlan tags to apply to the guest's network > - traffic Since 0.10.0. (openvswitch ^ [1] note: Formerly the "open" parenthesis... > - and type='hostdev' SR-IOV interfaces do support transparent vlan > - tagging of guest traffic; everything else, including standard > + more VLAN tags to apply to the guest's network > + traffic Since 0.10.0. Network > + connections that support guest-transparent VLAN tagging include > + 1) type='bridge' interfaces connected to an Open vSwitch bridge > + Since 0.10.0, 2) SRIOV Virtual > + Functions (VF) used via type='hostdev' (direct device > + assignment) Since 0.10.0, and 3) > + SRIOV VFs used via type='direct' with mode='passthrough' > + (macvtap "passthru" mode) Since > + 1.3.4; all other connection types, including standard nit: "s/; all/. All/" (already a long enough). >linux bridges and libvirt's own virtual networks, do not >support it. 802.1Qbh (vn-link) and 802.1Qbg (VEPA) switches >provide their own way (outside of libvirt) to tag guest traffic > - onto specific vlans.) To allow for specification of multiple > - tags (in the case of vlan trunking), a > - subelement, tag, specifies which vlan tag > - to use (for example: tag id='42'/. If an > - interface has more than one vlan element > - defined, it is assumed that the user wants to do VLAN trunking > - using all the specified tags. In the case that vlan trunking > - with a single tag is desired, the optional > + onto specific vlans.) Each tag is given in a Should this be VLANs? or "onto a specific VLAN." ? [1] Don't need the close parentheis ')' since the open one was removed. > + separate tag subelement > + of vlan (for example: tag > + id='42'/). For VLAN trunking of multiple tags (which > + is supported only on Open vSwitch connections), > + multiple tag subelements can be specified, This reads strange... There's multiple multiples - one "multiple tags" and one "multiple subelements"... I guess it's right, just was a tough read the first time through! > + which implies that the user wants to do VLAN trunking on the > + interface for all the specified tags. In the case that VLAN > + trunking of a single tag is desired, the optional >attribute trunk='yes' can be added to the toplevel > - vlan element. > - > - > - > - For network connections using openvswitch it is possible to > - configure the 'native-tagged' and 'native-untagged' vlan modes > -
[libvirt] [PATCH 4/9] target-i386: List CPU models using subclass list
Instead of using the builtin_x86_defs array, use the QOM subclass list to list CPU models on "-cpu ?" and "query-cpu-definitions". Signed-off-by: Andreas Färber[ehabkost: copied code from a patch by Andreas: "target-i386: QOM'ify CPU", from March 2012] Signed-off-by: Eduardo Habkost --- target-i386/cpu-qom.h | 4 ++ target-i386/cpu.c | 111 +- 2 files changed, 86 insertions(+), 29 deletions(-) diff --git a/target-i386/cpu-qom.h b/target-i386/cpu-qom.h index cb75017..c23b634 100644 --- a/target-i386/cpu-qom.h +++ b/target-i386/cpu-qom.h @@ -64,6 +64,10 @@ typedef struct X86CPUClass { bool kvm_required; +/* Optional description of CPU model. + * If unavailable, cpu_def->model_id is used */ +const char *model_description; + DeviceRealize parent_realize; void (*parent_reset)(CPUState *cpu); } X86CPUClass; diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 26a5a6b..037b602 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -676,6 +676,14 @@ static ObjectClass *x86_cpu_class_by_name(const char *cpu_model) return oc; } +static char *x86_cpu_class_get_model_name(X86CPUClass *cc) +{ +const char *class_name = object_class_get_name(OBJECT_CLASS(cc)); +assert(g_str_has_suffix(class_name, X86_CPU_TYPE_SUFFIX)); +return g_strndup(class_name, + strlen(class_name) - strlen(X86_CPU_TYPE_SUFFIX)); +} + struct X86CPUDefinition { const char *name; uint32_t level; @@ -1484,6 +1492,9 @@ static void host_x86_cpu_class_init(ObjectClass *oc, void *data) cpu_x86_fill_model_id(host_cpudef.model_id); xcc->cpu_def = _cpudef; +xcc->model_description = +"KVM processor with all supported host features " +"(only available in KVM mode)"; /* level, xlevel, xlevel2, and the feature words are initialized on * instance_init, because they require KVM to be initialized. @@ -2009,23 +2020,62 @@ static void listflags(FILE *f, fprintf_function print, const char **featureset) } } -/* generate CPU information. */ +/* Sort alphabetically by type name, listing kvm_required models last. */ +static gint x86_cpu_list_compare(gconstpointer a, gconstpointer b) +{ +ObjectClass *class_a = (ObjectClass *)a; +ObjectClass *class_b = (ObjectClass *)b; +X86CPUClass *cc_a = X86_CPU_CLASS(class_a); +X86CPUClass *cc_b = X86_CPU_CLASS(class_b); +const char *name_a, *name_b; + +if (cc_a->kvm_required != cc_b->kvm_required) { +/* kvm_required items go last */ +return cc_a->kvm_required ? 1 : -1; +} else { +name_a = object_class_get_name(class_a); +name_b = object_class_get_name(class_b); +return strcmp(name_a, name_b); +} +} + +static GSList *get_sorted_cpu_model_list(void) +{ +GSList *list = object_class_get_list(TYPE_X86_CPU, false); +list = g_slist_sort(list, x86_cpu_list_compare); +return list; +} + +static void x86_cpu_list_entry(gpointer data, gpointer user_data) +{ +ObjectClass *oc = data; +X86CPUClass *cc = X86_CPU_CLASS(oc); +CPUListState *s = user_data; +char *name = x86_cpu_class_get_model_name(cc); +const char *desc = cc->model_description; +if (!desc) { +desc = cc->cpu_def->model_id; +} + +(*s->cpu_fprintf)(s->file, "x86 %16s %-48s\n", + name, desc); +g_free(name); +} + +/* list available CPU models and flags */ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf) { -X86CPUDefinition *def; -char buf[256]; int i; +CPUListState s = { +.file = f, +.cpu_fprintf = cpu_fprintf, +}; +GSList *list; -for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) { -def = _x86_defs[i]; -snprintf(buf, sizeof(buf), "%s", def->name); -(*cpu_fprintf)(f, "x86 %16s %-48s\n", buf, def->model_id); -} -#ifdef CONFIG_KVM -(*cpu_fprintf)(f, "x86 %16s %-48s\n", "host", - "KVM processor with all supported host features " - "(only available in KVM mode)"); -#endif +(*cpu_fprintf)(f, "Available CPUs:\n"); +list = get_sorted_cpu_model_list(); +g_slist_foreach(list, x86_cpu_list_entry, ); +g_slist_free(list); (*cpu_fprintf)(f, "\nRecognized CPUID flags:\n"); for (i = 0; i < ARRAY_SIZE(feature_word_info); i++) { @@ -2037,26 +2087,29 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf) } } -CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp) +static void x86_cpu_definition_entry(gpointer data, gpointer user_data) { -CpuDefinitionInfoList *cpu_list = NULL; -X86CPUDefinition *def; -int i; - -for (i = 0; i < ARRAY_SIZE(builtin_x86_defs); i++) { -CpuDefinitionInfoList *entry; -CpuDefinitionInfo *info; +ObjectClass *oc = data; +X86CPUClass *cc = X86_CPU_CLASS(oc); +CpuDefinitionInfoList
[libvirt] [PATCH 9/9] target-i386: Return runnability information on query-cpu-definitions
Fill the "runnable" and "unavailable-features" fields on the x86 implementation of query-cpu-definitions. Example command output: { "return": [ { "runnable": true, "name": "host"}, { "runnable": true, "name": "qemu64"}, { "runnable": true, "name": "qemu32"}, { "runnable": false, "name": "phenom", "unavailable-features": ["npt", "sse4a", "3dnow", "3dnowext", "fxsr-opt", "mmxext"] }, { "runnable": true, "name": "pentium3"}, { "runnable": true, "name": "pentium2"}, { "runnable": true, "name": "pentium"}, { "runnable": true, "name": "n270"}, { "runnable": true, "name": "kvm64"}, { "runnable": true, "name": "kvm32"}, { "runnable": true, "name": "coreduo"}, { "runnable": true, "name": "core2duo"}, { "runnable": false, "name": "athlon", "unavailable-features": ["3dnow", "3dnowext", "mmxext"] }, { "runnable": true, "name": "Westmere"}, { "runnable": true, "name": "SandyBridge"}, { "runnable": true, "name": "Penryn"}, { "runnable": false, "name": "Opteron_G5", "unavailable-features": ["tbm", "fma4", "xop", "3dnowprefetch", "misalignsse", "sse4a"] }, { "runnable": false, "name": "Opteron_G4", "unavailable-features": ["fma4", "xop", "3dnowprefetch", "misalignsse", "sse4a"] }, { "runnable": false, "name": "Opteron_G3", "unavailable-features": ["misalignsse", "sse4a"] }, { "runnable": true, "name": "Opteron_G2"}, { "runnable": true, "name": "Opteron_G1"}, { "runnable": true, "name": "Nehalem"}, { "runnable": true, "name": "IvyBridge"}, { "runnable": false, "name": "Haswell", "unavailable-features": ["rtm", "hle"] }, { "runnable": true, "name": "Haswell-noTSX"}, { "runnable": true, "name": "Conroe"}, { "runnable": false, "name": "Broadwell", "unavailable-features": ["3dnowprefetch", "smap", "adx", "rdseed", "rtm", "hle"] }, { "runnable": false, "name": "Broadwell-noTSX", "unavailable-features": ["3dnowprefetch", "smap", "adx", "rdseed"] }, { "runnable": true, "name": "486"} ] } Cc: Jiri DenemarkCc: libvir-list@redhat.com Signed-off-by: Eduardo Habkost --- target-i386/cpu.c | 40 1 file changed, 40 insertions(+) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index e7365d1..f6f0f83 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2041,6 +2041,41 @@ static void x86_cpu_report_filtered_features(X86CPU *cpu) } } +static bool x86_cpu_class_is_runnable(X86CPUClass *xcc, strList **missing_feats) +{ +X86CPU *xc; +bool r; +FeatureWord w; + +if (xcc->kvm_required && !kvm_enabled()) { +return false; +} + +xc = X86_CPU(object_new(object_class_get_name(OBJECT_CLASS(xcc; +r = !x86_cpu_filter_features(xc); +if (!r) { +for (w = 0; w < FEATURE_WORDS; w++) { +FeatureWordInfo *fi = _word_info[w]; +uint32_t filtered = xc->filtered_features[w]; +int i; +for (i = 0; i < 32; i++) { +if (filtered & (1UL << i)) { +char **parts = g_strsplit(fi->feat_names[i], "|", 2); +strList *new = g_new0(strList, 1); +new->value = g_strdup(parts[0]); +feat2prop(new->value); +new->next = *missing_feats; +*missing_feats = new; +g_strfreev(parts); +} +} +} +} + +object_unref(OBJECT(xc)); +return r; +} + /* Print all cpuid feature names in featureset */ static void listflags(FILE *f, fprintf_function print, const char **featureset) @@ -2133,6 +2168,11 @@ static void x86_cpu_definition_entry(gpointer data, gpointer user_data) info = g_malloc0(sizeof(*info)); info->name = x86_cpu_class_get_model_name(cc); +info->has_runnable = true; +info->runnable = x86_cpu_class_is_runnable(cc, >unavailable_features); +if (!info->runnable) { +info->has_unavailable_features = true; +} entry = g_malloc0(sizeof(*entry)); entry->value = info; -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 6/9] target-i386: Define CPUID filtering functions before x86_cpu_list()
Just move code to another place so the it can be reused by the query-cpu-definitions code. Signed-off-by: Eduardo Habkost--- target-i386/cpu.c | 68 +++ 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 465c125..309ef55 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2005,6 +2005,40 @@ static void x86_cpu_parse_featurestr(CPUState *cs, char *features, } } +/* + * Filters CPU feature words based on host availability of each feature. + * + * Returns: 0 if all flags are supported by the host, non-zero otherwise. + */ +static int x86_cpu_filter_features(X86CPU *cpu) +{ +CPUX86State *env = >env; +FeatureWord w; +int rv = 0; + +for (w = 0; w < FEATURE_WORDS; w++) { +uint32_t host_feat = +x86_cpu_get_supported_feature_word(w, cpu->migratable); +uint32_t requested_features = env->features[w]; +env->features[w] &= host_feat; +cpu->filtered_features[w] = requested_features & ~env->features[w]; +if (cpu->filtered_features[w]) { +rv = 1; +} +} + +return rv; +} + +static void x86_cpu_report_filtered_features(X86CPU *cpu) +{ +FeatureWord w; + +for (w = 0; w < FEATURE_WORDS; w++) { +report_unavailable_features(w, cpu->filtered_features[w]); +} +} + /* Print all cpuid feature names in featureset */ static void listflags(FILE *f, fprintf_function print, const char **featureset) @@ -2134,40 +2168,6 @@ static uint32_t x86_cpu_get_supported_feature_word(FeatureWord w, return r; } -/* - * Filters CPU feature words based on host availability of each feature. - * - * Returns: 0 if all flags are supported by the host, non-zero otherwise. - */ -static int x86_cpu_filter_features(X86CPU *cpu) -{ -CPUX86State *env = >env; -FeatureWord w; -int rv = 0; - -for (w = 0; w < FEATURE_WORDS; w++) { -uint32_t host_feat = -x86_cpu_get_supported_feature_word(w, cpu->migratable); -uint32_t requested_features = env->features[w]; -env->features[w] &= host_feat; -cpu->filtered_features[w] = requested_features & ~env->features[w]; -if (cpu->filtered_features[w]) { -rv = 1; -} -} - -return rv; -} - -static void x86_cpu_report_filtered_features(X86CPU *cpu) -{ -FeatureWord w; - -for (w = 0; w < FEATURE_WORDS; w++) { -report_unavailable_features(w, cpu->filtered_features[w]); -} -} - static void x86_cpu_apply_props(X86CPU *cpu, PropValue *props) { PropValue *pv; -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 8/9] target-i386: Use "-" instead of "_" on all feature names
This makes the feature name tables in feature_word_info all match the actual QOM property names we use. This will make the command-line interface more consistent, allowing the QOM property names to be used as "-cpu" arguments directly. Add extra feat2prop() calls to x86_cpu_parse_featurestr() to keep compatibility with the old that had underscores. Cc: Jiri DenemarkCc: libvir-list@redhat.com Signed-off-by: Eduardo Habkost --- target-i386/cpu.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 309ef55..e7365d1 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -187,7 +187,7 @@ static const char *feature_name[] = { }; static const char *ext_feature_name[] = { "pni|sse3" /* Intel,AMD sse3 */, "pclmulqdq|pclmuldq", "dtes64", "monitor", -"ds_cpl", "vmx", "smx", "est", +"ds-cpl", "vmx", "smx", "est", "tm2", "ssse3", "cid", NULL, "fma", "cx16", "xtpr", "pdcm", NULL, "pcid", "dca", "sse4.1|sse4_1", @@ -207,17 +207,17 @@ static const char *ext2_feature_name[] = { NULL /* mtrr */, NULL /* pge */, NULL /* mca */, NULL /* cmov */, NULL /* pat */, NULL /* pse36 */, NULL, NULL /* Linux mp */, "nx|xd", NULL, "mmxext", NULL /* mmx */, -NULL /* fxsr */, "fxsr_opt|ffxsr", "pdpe1gb" /* AMD Page1GB */, "rdtscp", +NULL /* fxsr */, "fxsr-opt|ffxsr", "pdpe1gb" /* AMD Page1GB */, "rdtscp", NULL, "lm|i64", "3dnowext", "3dnow", }; static const char *ext3_feature_name[] = { -"lahf_lm" /* AMD LahfSahf */, "cmp_legacy", "svm", "extapic" /* AMD ExtApicSpace */, +"lahf-lm" /* AMD LahfSahf */, "cmp-legacy", "svm", "extapic" /* AMD ExtApicSpace */, "cr8legacy" /* AMD AltMovCr8 */, "abm", "sse4a", "misalignsse", "3dnowprefetch", "osvw", "ibs", "xop", "skinit", "wdt", NULL, "lwp", -"fma4", "tce", NULL, "nodeid_msr", -NULL, "tbm", "topoext", "perfctr_core", -"perfctr_nb", NULL, NULL, NULL, +"fma4", "tce", NULL, "nodeid-msr", +NULL, "tbm", "topoext", "perfctr-core", +"perfctr-nb", NULL, NULL, NULL, NULL, NULL, NULL, NULL, }; @@ -233,8 +233,8 @@ static const char *ext4_feature_name[] = { }; static const char *kvm_feature_name[] = { -"kvmclock", "kvm_nopiodelay", "kvm_mmu", "kvmclock", -"kvm_asyncpf", "kvm_steal_time", "kvm_pv_eoi", "kvm_pv_unhalt", +"kvmclock", "kvm-nopiodelay", "kvm-mmu", "kvmclock", +"kvm-asyncpf", "kvm-steal-time", "kvm-pv-eoi", "kvm-pv-unhalt", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, @@ -244,9 +244,9 @@ static const char *kvm_feature_name[] = { }; static const char *svm_feature_name[] = { -"npt", "lbrv", "svm_lock", "nrip_save", -"tsc_scale", "vmcb_clean", "flushbyasid", "decodeassists", -NULL, NULL, "pause_filter", NULL, +"npt", "lbrv", "svm-lock", "nrip-save", +"tsc-scale", "vmcb-clean", "flushbyasid", "decodeassists", +NULL, NULL, "pause-filter", NULL, "pfthreshold", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, @@ -255,7 +255,7 @@ static const char *svm_feature_name[] = { }; static const char *cpuid_7_0_ebx_feature_name[] = { -"fsgsbase", "tsc_adjust", NULL, "bmi1", "hle", "avx2", NULL, "smep", +"fsgsbase", "tsc-adjust", NULL, "bmi1", "hle", "avx2", NULL, "smep", "bmi2", "erms", "invpcid", "rtm", NULL, NULL, "mpx", NULL, "avx512f", NULL, "rdseed", "adx", "smap", NULL, "pcommit", "clflushopt", "clwb", NULL, "avx512pf", "avx512er", "avx512cd", NULL, NULL, NULL, @@ -1894,8 +1894,8 @@ static PropertyInfo qdev_prop_spinlocks = { .set = x86_set_hv_spinlocks, }; -/* Convert all '_' in a feature string option name to '-', to make feature - * name conform to QOM property naming rule, which uses '-' instead of '_'. +/* Convert all '_' in a feature string option name to '-', to keep compatibility + * with old feature names that used "_" instead of "-". */ static inline void feat2prop(char *s) { @@ -1925,8 +1925,10 @@ static void x86_cpu_parse_featurestr(CPUState *cs, char *features, while (featurestr) { char *val; if (featurestr[0] == '+') { +feat2prop(featurestr); add_flagname_to_bitmaps(featurestr + 1, plus_features, _err); } else if (featurestr[0] == '-') { +feat2prop(featurestr); add_flagname_to_bitmaps(featurestr + 1, minus_features, _err); } else if ((val = strchr(featurestr, '='))) { *val = 0; val++; @@ -3137,11 +3139,9 @@ static void x86_cpu_register_feature_bit_props(X86CPU *cpu, names = g_strsplit(fi->feat_names[bitnr], "|", 0); -feat2prop(names[0]); x86_cpu_register_bit_prop(cpu, names[0], >env.features[w], bitnr); for (i = 1; names[i]; i++) { -feat2prop(names[i]); object_property_add_alias(obj, names[i], obj, names[0],
[libvirt] [PATCH 1/9] target-i386: Move TCG initialization check to tcg_x86_init()
Instead of requiring cpu.c to check if TCG was already initialized, simply let the function be called multiple times. Suggested-by: Igor MammedovSigned-off-by: Eduardo Habkost --- target-i386/cpu.c | 4 +--- target-i386/translate.c | 6 ++ 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 4856cd4..a689fec 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -3087,7 +3087,6 @@ static void x86_cpu_initfn(Object *obj) X86CPUClass *xcc = X86_CPU_GET_CLASS(obj); CPUX86State *env = >env; FeatureWord w; -static int inited; cs->env_ptr = env; cpu_exec_init(cs, _abort); @@ -3138,8 +3137,7 @@ static void x86_cpu_initfn(Object *obj) x86_cpu_load_def(cpu, xcc->cpu_def, _abort); /* init various static tables used in TCG mode */ -if (tcg_enabled() && !inited) { -inited = 1; +if (tcg_enabled()) { tcg_x86_init(); } } diff --git a/target-i386/translate.c b/target-i386/translate.c index 1a1214d..92570b4 100644 --- a/target-i386/translate.c +++ b/target-i386/translate.c @@ -8133,6 +8133,12 @@ void tcg_x86_init(void) "bnd0_ub", "bnd1_ub", "bnd2_ub", "bnd3_ub" }; int i; +static bool initialized = false; + +if (initialized) { +return; +} +initialized = true; cpu_env = tcg_global_reg_new_ptr(TCG_AREG0, "env"); cpu_cc_op = tcg_global_mem_new_i32(cpu_env, -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/9] target-i386: Move TCG initialization to realize time
QOM instance_init functions are not supposed to have any side-effects, as new objects may be created at any moment for querying property information (see qmp_device_list_properties()). Move TCG initialization to realize time so it won't be called when just doing object_new() on a X86CPU subclass. Signed-off-by: Eduardo Habkost--- Changes v1 -> v2: * Now the inited/tcg_initialized variable doesn't exist anymore * Move tcg_x86_init() call after basic parameter validation inside realizefn --- target-i386/cpu.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index a689fec..bde649a 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2901,6 +2901,10 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) } +if (tcg_enabled()) { +tcg_x86_init(); +} + #ifndef CONFIG_USER_ONLY qemu_register_reset(x86_cpu_machine_reset_cb, cpu); @@ -3135,11 +3139,6 @@ static void x86_cpu_initfn(Object *obj) } x86_cpu_load_def(cpu, xcc->cpu_def, _abort); - -/* init various static tables used in TCG mode */ -if (tcg_enabled()) { -tcg_x86_init(); -} } static int64_t x86_cpu_get_arch_id(CPUState *cs) -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 5/9] target-i386: Move warning code outside x86_cpu_filter_features()
x86_cpu_filter_features() will be reused by code that shouldn't print any warning. Move the warning code to a new x86_cpu_report_filtered_features() function, and call it from x86_cpu_realizefn(). Signed-off-by: Eduardo Habkost--- target-i386/cpu.c | 28 +++- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index 037b602..465c125 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2152,9 +2152,6 @@ static int x86_cpu_filter_features(X86CPU *cpu) env->features[w] &= host_feat; cpu->filtered_features[w] = requested_features & ~env->features[w]; if (cpu->filtered_features[w]) { -if (cpu->check_cpuid || cpu->enforce_cpuid) { -report_unavailable_features(w, cpu->filtered_features[w]); -} rv = 1; } } @@ -2162,6 +2159,15 @@ static int x86_cpu_filter_features(X86CPU *cpu) return rv; } +static void x86_cpu_report_filtered_features(X86CPU *cpu) +{ +FeatureWord w; + +for (w = 0; w < FEATURE_WORDS; w++) { +report_unavailable_features(w, cpu->filtered_features[w]); +} +} + static void x86_cpu_apply_props(X86CPU *cpu, PropValue *props) { PropValue *pv; @@ -2936,12 +2942,16 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) env->cpuid_level = 7; } -if (x86_cpu_filter_features(cpu) && cpu->enforce_cpuid) { -error_setg(_err, - kvm_enabled() ? - "Host doesn't support requested features" : - "TCG doesn't support requested features"); -goto out; +if (x86_cpu_filter_features(cpu) && +(cpu->check_cpuid || cpu->enforce_cpuid)) { +x86_cpu_report_filtered_features(cpu); +if (cpu->enforce_cpuid) { +error_setg(_err, + kvm_enabled() ? + "Host doesn't support requested features" : + "TCG doesn't support requested features"); +goto out; +} } /* On AMD CPUs, some CPUID[8000_0001].EDX bits must match the bits on -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions
Extend query-cpu-definitions schema to allow it to return two new optional fields: "runnable" and "unavailable-features". "runnable" will tell if the CPU model can be run in the current host. "unavailable-features" will contain a list of CPU properties that are preventing the CPU model from running in the current host. Cc: David HildenbrandCc: Michael Mueller Cc: Christian Borntraeger Cc: Cornelia Huck Cc: Jiri Denemark Cc: libvir-list@redhat.com Signed-off-by: Eduardo Habkost --- qapi-schema.json | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/qapi-schema.json b/qapi-schema.json index 54634c4..450e6e7 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -2948,11 +2948,19 @@ # Virtual CPU definition. # # @name: the name of the CPU definition +# @runnable: true if the CPU model is runnable using the current +#machine and accelerator. Optional. Since 2.6. +# @unavailable-features: List of properties that prevent the CPU +#model from running in the current host, +#if @runnable is false. Optional. +#Since 2.6. # # Since: 1.2.0 ## { 'struct': 'CpuDefinitionInfo', - 'data': { 'name': 'str' } } + 'data': { 'name': 'str', +'*runnable': 'bool', +'*unavailable-features': [ 'str' ] } } ## # @query-cpu-definitions: -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/9] target-i386: Call cpu_exec_init() on realize
QOM instance_init functions are not supposed to have any side-effects, as new objects may be created at any moment for querying property information (see qmp_device_list_properties()). Calling cpu_exec_init() also affects QEMU's ability to handle errors during CPU creation, as some actions done by cpu_exec_init() can't be reverted. Move cpu_exec_init() call to realize so a simple object_new() won't trigger it, and so that it is called after some basic validation of CPU parameters. Signed-off-by: Eduardo Habkost--- Changes v1 -> v2: * Call cpu_exec_init() after basic parameter validation --- target-i386/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target-i386/cpu.c b/target-i386/cpu.c index bde649a..26a5a6b 100644 --- a/target-i386/cpu.c +++ b/target-i386/cpu.c @@ -2901,6 +2901,8 @@ static void x86_cpu_realizefn(DeviceState *dev, Error **errp) } +cpu_exec_init(cs, _abort); + if (tcg_enabled()) { tcg_x86_init(); } @@ -3093,7 +3095,6 @@ static void x86_cpu_initfn(Object *obj) FeatureWord w; cs->env_ptr = env; -cpu_exec_init(cs, _abort); object_property_add(obj, "family", "int", x86_cpuid_version_get_family, -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/9] Add runnability info to query-cpu-definitions
This series extends query-cpu-definitions to include two extra fields: "runnable", and "unavailable-features". This will return information based on the current machine and accelerator only. In the future we may extend these mechanisms to allow querying other machines and other accelerators without restarting QEMU, but it will require some reorganization of QEMU's main code. This series is based on my 'x86-next' branch, at: git://github.com/ehabkost/qemu.git x86-next Cc: David HildenbrandCc: Michael Mueller Cc: Christian Borntraeger Cc: Cornelia Huck Cc: Jiri Denemark Cc: libvir-list@redhat.com Eduardo Habkost (9): target-i386: Move TCG initialization check to tcg_x86_init() target-i386: Move TCG initialization to realize time target-i386: Call cpu_exec_init() on realize target-i386: List CPU models using subclass list target-i386: Move warning code outside x86_cpu_filter_features() target-i386: Define CPUID filtering functions before x86_cpu_list() qmp: Add runnability information to query-cpu-definitions target-i386: Use "-" instead of "_" on all feature names target-i386: Return runnability information on query-cpu-definitions qapi-schema.json| 10 +- target-i386/cpu-qom.h | 4 + target-i386/cpu.c | 275 +--- target-i386/translate.c | 6 ++ 4 files changed, 207 insertions(+), 88 deletions(-) -- 2.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] qemu_monitor_json: Refactor even more
On 05/04/2016 08:33 AM, Michal Privoznik wrote: > All these patches will be squashed into one, but I've split them > into multiple because of easier review. > > Michal Privoznik (4): > qemu_monitor_json: Follow refactor > qemu_monitor_json: Follow refactor > qemu_monitor_json: Follow refactor > qemu_monitor_json: Follow refactor > > src/qemu/qemu_monitor_json.c | 673 > ++- > 1 file changed, 349 insertions(+), 324 deletions(-) > Not a deal breaker, but most code has: if (qemuMonitorJSONCheckError(cmd, reply) < 0) goto cleanup; ret = 0; cleanup: while a few instances [1] have: ret = qemuMonitorJSONCheckError(cmd, reply); cleanup: IDC either way since the result is the same, but I suppose they "could" be all done the same way. I'd probably lean towards the latter, but since you already went with the former in commit '7884d089' it's probably best to keep using that. [1] qemuMonitorJSONSetMigrationCompression qemuMonitorJSONBlockCommit qemuMonitorJSONInjectNMI [2] qemuMonitorJSONSendKey [2] qemuMonitorJSONSetMigrationCapability [2] both instances use the same HMP call attempt to return ret - they could follow the qemuMonitorJSONSetCPU model... Finally, I see the comments move 4 spaces to the right in qemuMonitorJSONSetObjectProperty? (patch 4)... Was that a remnant or expected? ACK series (your call if you want to adjust [2] now or in a followup patch. it's trivial enough as long as you remember to also remove the {} around what would become "one line" if then else statements). John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/17] genericxml2xml: add several graphics tests
On Fri, May 06, 2016 at 02:33:03PM +0200, Peter Krempa wrote: > On Thu, May 05, 2016 at 18:20:25 +0200, Pavel Hrdina wrote: > > Signed-off-by: Pavel Hrdina> > --- > > [...] > > > diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c > > index 70a5203..70ecd2d 100644 > > --- a/tests/genericxml2xmltest.c > > +++ b/tests/genericxml2xmltest.c > > @@ -77,9 +77,16 @@ mymain(void) > > > > DO_TEST_DIFFERENT("disk-virtio"); > > > > +DO_TEST_DIFFERENT("graphics-vnc-minimal"); > > +DO_TEST_DIFFERENT("graphics-vnc-manual-port"); > > +DO_TEST_DIFFERENT("graphics-vnc-socket"); > > +DO_TEST_DIFFERENT("graphics-vnc-socket-listen"); > > DO_TEST_DIFFERENT("graphics-listen-back-compat"); > > DO_TEST_FULL("graphics-listen-back-compat-mismatch", 0, false, > > TEST_COMPARE_DOM_XML2XML_RESULT_FAIL_PARSE); > > +DO_TEST_DIFFERENT("graphics-vnc-listen-attr-only"); > > +DO_TEST_DIFFERENT("graphics-vnc-listen-element-minimal"); > > +DO_TEST_DIFFERENT("graphics-vnc-listen-element-with-address"); > > I guess the test case names are self explanatory enough to require a > commit message describing the tests. > > ACK Thanks, I've pushed patches 1-6 except patch 4. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: domain: Don't treat unknown storage type as not having backing chain
On 05/06/2016 09:48 AM, Peter Krempa wrote: > qemuDomainCheckDiskPresence has short-circuit code to skip the > determination of the disk backing chain for storage formats that can't > have backing volumes. The code treats VIR_STORAGE_FILE_NONE as not > having backing chain and skips the call to qemuDomainDetermineDiskChain. > > This is wrong as qemuDomainDetermineDiskChain is responsible for storage > format detection and has logic to determine the default type if format > detection is disabled. > > This allows to storage passed via to circumvent the > enforcement to have correct storage format or that we shall default to > format='raw', since we don't set the default type via the post parse > callback for "volume" backed disks as the translation code could come up > with a better guess. > > This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1328003 > --- > src/qemu/qemu_domain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > ACK... John Do you believe it still would be worthwhile to add: if (virDomainDiskGetFormat(def) == VIR_STORAGE_FILE_NONE) virDomainDiskSetFormat(def, VIR_STORAGE_FILE_RAW); in virStorageTranslateDiskSourcePool in the ISCSI case for MODE_HOST? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 8/8] Revert "conf: Validate disk lun using correct types"
On 05/02/2016 10:32 AM, Peter Krempa wrote: > This reverts commit c79ebf53b5fe0a33bf407b3bcb49e3a27ec97eb4. > > We can't just add checks to the XML parser once we've accepted such > configuration in the past. > --- > src/conf/domain_conf.c | 22 -- > tests/qemuxml2argvtest.c | 3 +-- > 2 files changed, 1 insertion(+), 24 deletions(-) > There was a bz associated with that commit - that'll need to be addressed in some manner... While I understand your point here, the configuration didn't work - that is it couldn't be started anyway so there could not be a domain running with that configuration and thus it wouldn't disappear on a subsequent reload, hence why checking the config and rejecting "earlier" seemed proper even though we hadn't rejected such a config when the "mode='host'" was first implemented. Commit 'c79ebf53b' is a followup of sorts to commit '33188c9f'... For me it's a NACK, but someone else may feel differently John > diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c > index 48a220f..c4cbbff 100644 > --- a/src/conf/domain_conf.c > +++ b/src/conf/domain_conf.c > @@ -4181,28 +4181,6 @@ > virDomainDeviceDefPostParseInternal(virDomainDeviceDefPtr dev, > } > } > > -/* Validate LUN configuration > - * NOTE: virStorageTranslateDiskSourcePool is not run yet, so for > - * disk "volume"'s, the closest we can get at config time is > - * to ensure mode isn't direct since host/default will allow > - * lun/block usage. At run time if it's determined the wrong > - * voltype and pooltype values are set, then failure occurs > - */ > -if (disk->device == VIR_DOMAIN_DISK_DEVICE_LUN && > -!(disk->src->type == VIR_STORAGE_TYPE_BLOCK || > - (disk->src->type == VIR_STORAGE_TYPE_NETWORK && > - disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_ISCSI) || > - (disk->src->type == VIR_STORAGE_TYPE_VOLUME && > - disk->src->srcpool && > - disk->src->srcpool->mode != > - VIR_STORAGE_SOURCE_POOL_MODE_DIRECT))) { > -virReportError(VIR_ERR_CONFIG_UNSUPPORTED, > - _("disk '%s' improperly configured for a " > - "device='lun'"), > - disk->dst); > -return -1; > -} > - > if (disk->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE && > virDomainDiskDefAssignAddress(xmlopt, disk, def) < 0) > return -1; > diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c > index 8842b2f..4211e82 100644 > --- a/tests/qemuxml2argvtest.c > +++ b/tests/qemuxml2argvtest.c > @@ -780,8 +780,7 @@ mymain(void) > DO_TEST_FAILURE("disk-drive-network-rbd-no-colon", NONE); > DO_TEST("disk-drive-no-boot", > QEMU_CAPS_BOOTINDEX); > -DO_TEST_PARSE_ERROR("disk-device-lun-type-invalid", > -QEMU_CAPS_VIRTIO_SCSI); > +DO_TEST_FAILURE("disk-device-lun-type-invalid", QEMU_CAPS_VIRTIO_SCSI); > DO_TEST_FAILURE("disk-usb-nosupport", NONE); > DO_TEST("disk-usb-device", > QEMU_CAPS_DEVICE_USB_STORAGE, > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 7/8] qemu: Reject invalid block copy targets for
On 05/02/2016 10:32 AM, Peter Krempa wrote: > Extract the relevant parts of the existing checker and reuse them for > blockcopy since copying to a non-block device creates an invalid > configuration. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1209802 > --- > src/qemu/qemu_command.c | 14 +- > src/qemu/qemu_domain.c | 31 +++ > src/qemu/qemu_domain.h | 3 +++ > src/qemu/qemu_driver.c | 4 > 4 files changed, 39 insertions(+), 13 deletions(-) > ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 6/8] qemu: command: Remove unnecessary label in qemuCheckDiskConfig
On 05/02/2016 10:32 AM, Peter Krempa wrote: > --- > src/qemu/qemu_command.c | 18 -- > 1 file changed, 8 insertions(+), 10 deletions(-) > ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 5/8] conf: Kill now unused virDomainDiskSourceIsBlockType
On 05/02/2016 10:32 AM, Peter Krempa wrote: > --- > src/conf/domain_conf.c | 52 > > src/conf/domain_conf.h | 3 --- > src/libvirt_private.syms | 1 - > 3 files changed, 56 deletions(-) > ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/8] qemu: command: Use more appropriate checking function for block devices
On 05/02/2016 10:32 AM, Peter Krempa wrote: > In qemuCheckDiskConfig would now use virDomainDiskSourceIsBlockType just > as a glorified version of virStorageSourceIsBlockLocal that reports > error messages. Replace it with the latter including the message for > clarity. > --- > src/qemu/qemu_command.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Hmmm... I wonder if the previous commit should remove or at least reference the check in virDomainDiskSourceIsBlockType that neglected to consider the translation and actualtype... ACK for this - your call on whether to adjust the previous commit... John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/8] qemu: Support for iSCSI direct mapped volumes
On 05/02/2016 10:32 AM, Peter Krempa wrote: > Commit c820fbff9fbfe1f2549a5b60967496587f8d8bfc added support for iSCSI > disk as backing for . We would not use it for a disk > type="volume" with direct access mode which basically maps to direct > iSCSI usage. Fix it by adding the storage source type accessor that > resolves the volume type. > --- > src/qemu/qemu_command.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/8] lxc: Fix wrong error message on disk hotplug
On 05/02/2016 10:32 AM, Peter Krempa wrote: > Commit 36025c552 tried to improve error reporting for > but reused the code in LXC which doesn't care about the actual disk > type. The error messages would then contain a bogous hint that the > config for the 'lun' device is invalid which might not be the case. > > Re-do the relevant portion of the commit with the original message. > --- > src/lxc/lxc_driver.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c > index 1dfbde3..7b76daf 100644 > --- a/src/lxc/lxc_driver.c > +++ b/src/lxc/lxc_driver.c > @@ -4106,9 +4106,6 @@ lxcDomainAttachDeviceDiskLive(virLXCDriverPtr driver, > goto cleanup; > } > > -if (!virDomainDiskSourceIsBlockType(def->src, true)) > -goto cleanup; > - > src = virDomainDiskGetSource(def); > if (src == NULL) { > virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > @@ -4116,6 +4113,12 @@ lxcDomainAttachDeviceDiskLive(virLXCDriverPtr driver, > goto cleanup; > } > > +if (virStorageSourceIsBlockLocal(def->src)) { Shouldn't this be "if (!virStorageSourceIsBlockLocal(def->src)" ? ACK w/ the adjustment John > +virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > + _("Can't setup disk for non-block device")); > +goto cleanup; > +} > + FWIW: Prior to my commit referenced above the check was: if (!virDomainDiskSourceIsBlockType(def->src)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Can't setup disk for non-block device")); And yes, of course since virDomainDiskSourceIsBlockType checks "src->path" first (and provides a different message), moving this after that check seems right; otherwise, the error message is "source path not found for device='lun' using type='%d'" if (!src->path). All that commit did was try to have the lower layer generate the error message. Of course in this case erroneously swapping "Can't setup disk for non-block device" for "disk device='lun' is only valid for block type disk source". Still going back to 'a7785ccf' we see the call to "if (!virDomainDiskSourceIsBlockType(def)"... > if (virDomainDiskIndexByName(vm->def, def->dst, true) >= 0) { > virReportError(VIR_ERR_OPERATION_FAILED, > _("target %s already exists"), def->dst); > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/8] util: Replace virDomainDiskSourceIsBlockType with a new helper
On 05/02/2016 10:32 AM, Peter Krempa wrote: > For disks sources described by a libvirt volume we don't need to do a > complicated check since virStorageTranslateDiskSourcePool already > correctly determines the actual disk type. > > Replace the checks using a new accessor that does not open-code the > whole logic. > --- > src/libvirt_private.syms | 1 + > src/lxc/lxc_cgroup.c | 3 ++- > src/qemu/qemu_conf.c | 10 +++--- > src/util/virstoragefile.c | 16 +++- > src/util/virstoragefile.h | 3 ++- > 5 files changed, 27 insertions(+), 6 deletions(-) > > diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms > index 5030ec3..73c9fdb 100644 > --- a/src/libvirt_private.syms > +++ b/src/libvirt_private.syms > @@ -2277,6 +2277,7 @@ virStorageSourceFree; > virStorageSourceGetActualType; > virStorageSourceGetSecurityLabelDef; > virStorageSourceInitChainElement; > +virStorageSourceIsBlockLocal; > virStorageSourceIsEmpty; > virStorageSourceIsLocalStorage; > virStorageSourceNewFromBacking; > diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c > index 4afe7e2..ea86d36 100644 > --- a/src/lxc/lxc_cgroup.c > +++ b/src/lxc/lxc_cgroup.c > @@ -393,7 +393,8 @@ static int virLXCCgroupSetupDeviceACL(virDomainDefPtr def, > > VIR_DEBUG("Allowing any disk block devs"); > for (i = 0; i < def->ndisks; i++) { > -if (!virDomainDiskSourceIsBlockType(def->disks[i]->src, false)) > +if (virStorageSourceIsEmpty(def->disks[i]->src) || > +!virStorageSourceIsBlockLocal(def->disks[i]->src)) Could an LXC domain use a storage pool for a volume? If so, then somewhere in the LXC code wouldn't we need to translate the source pool in order to get "actualtype" and the volume check... > continue; > > if (virCgroupAllowDevicePath(cgroup, > diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c > index 5ed5776..e00ddca 100644 > --- a/src/qemu/qemu_conf.c > +++ b/src/qemu/qemu_conf.c > @@ -1243,7 +1243,9 @@ qemuAddSharedDisk(virQEMUDriverPtr driver, > char *key = NULL; > int ret = -1; > > -if (!disk->src->shared || !virDomainDiskSourceIsBlockType(disk->src, > false)) > +if (virStorageSourceIsEmpty(disk->src) || > +!disk->src->shared || > +!virStorageSourceIsBlockLocal(disk->src)) > return 0; > > qemuDriverLock(driver); > @@ -1388,7 +1390,9 @@ qemuRemoveSharedDisk(virQEMUDriverPtr driver, > char *key = NULL; > int ret = -1; > > -if (!disk->src->shared || !virDomainDiskSourceIsBlockType(disk->src, > false)) > +if (virStorageSourceIsEmpty(disk->src) || > +!disk->src->shared || > +!virStorageSourceIsBlockLocal(disk->src)) > return 0; > > qemuDriverLock(driver); > @@ -1476,7 +1480,7 @@ qemuSetUnprivSGIO(virDomainDeviceDefPtr dev) > disk = dev->data.disk; > > if (disk->device != VIR_DOMAIN_DISK_DEVICE_LUN || > -!virDomainDiskSourceIsBlockType(disk->src, false)) > +!virStorageSourceIsBlockLocal(disk->src)) > return 0; > > path = virDomainDiskGetSource(disk); > diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c > index 05ac254..4f44e05 100644 > --- a/src/util/virstoragefile.c > +++ b/src/util/virstoragefile.c > @@ -1955,7 +1955,7 @@ virStorageSourcePoolDefFree(virStorageSourcePoolDefPtr > def) > > > int > -virStorageSourceGetActualType(virStorageSourcePtr def) > +virStorageSourceGetActualType(const virStorageSource *def) > { > if (def->type == VIR_STORAGE_TYPE_VOLUME && def->srcpool) > return def->srcpool->actualtype; > @@ -2012,6 +2012,20 @@ virStorageSourceIsEmpty(virStorageSourcePtr src) > > > /** > + * virStorageSourceIsBlockLocal: > + * @src: disk source definition > + * > + * Returns true if @src describes a locally accessible block storage source. > + * This includes block devices and host-mapped iSCSI volumes. > + */ > +bool > +virStorageSourceIsBlockLocal(const virStorageSource *src) > +{ > +return virStorageSourceGetActualType(src) == VIR_STORAGE_TYPE_BLOCK; This assumes that virStorageTranslateDiskSourcePool has been run, which is true is for the non-LXC paths changed in this patch... So as long as you're comfortable with the LXC adjustment, then ACK - John > +} > + > + > +/** > * virStorageSourceBackingStoreClear: > * > * @src: disk source to clear > diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h > index b98fe25..17e1277 100644 > --- a/src/util/virstoragefile.h > +++ b/src/util/virstoragefile.h > @@ -357,9 +357,10 @@ int virStorageSourceInitChainElement(virStorageSourcePtr > newelem, > bool force); > void virStorageSourcePoolDefFree(virStorageSourcePoolDefPtr def); > void virStorageSourceClear(virStorageSourcePtr def); > -int virStorageSourceGetActualType(virStorageSourcePtr def); > +int virStorageSourceGetActualType(const virStorageSource *def); > bool
[libvirt] [PATCH] qemu: domain: Don't treat unknown storage type as not having backing chain
qemuDomainCheckDiskPresence has short-circuit code to skip the determination of the disk backing chain for storage formats that can't have backing volumes. The code treats VIR_STORAGE_FILE_NONE as not having backing chain and skips the call to qemuDomainDetermineDiskChain. This is wrong as qemuDomainDetermineDiskChain is responsible for storage format detection and has logic to determine the default type if format detection is disabled. This allows to storage passed via to circumvent the enforcement to have correct storage format or that we shall default to format='raw', since we don't set the default type via the post parse callback for "volume" backed disks as the translation code could come up with a better guess. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1328003 --- src/qemu/qemu_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index cae356c..78a717a 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -3817,7 +3817,7 @@ qemuDomainCheckDiskPresence(virQEMUDriverPtr driver, * without backing support, the fact that the file exists is * more than enough */ if (virStorageSourceIsLocalStorage(disk->src) && -format >= VIR_STORAGE_FILE_NONE && +format > VIR_STORAGE_FILE_NONE && format < VIR_STORAGE_FILE_BACKING && virFileExists(virDomainDiskGetSource(disk))) continue; -- 2.8.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/17] genericxml2xml: add several graphics tests
On 05/06/2016 09:21 AM, Pavel Hrdina wrote: > On Fri, May 06, 2016 at 08:43:25AM -0400, Cole Robinson wrote: >> On 05/05/2016 12:20 PM, Pavel Hrdina wrote: >>> Signed-off-by: Pavel Hrdina>>> --- >>> .../generic-graphics-vnc-listen-attr-only.xml | 28 >>> >>> ...generic-graphics-vnc-listen-element-minimal.xml | 30 >>> ++ >>> ...ic-graphics-vnc-listen-element-with-address.xml | 30 >>> ++ >>> .../generic-graphics-vnc-manual-port.xml | 28 >>> >>> .../generic-graphics-vnc-minimal.xml | 28 >>> >>> .../generic-graphics-vnc-socket-listen.xml | 30 >>> ++ >>> .../generic-graphics-vnc-socket.xml| 28 >>> >>> .../generic-graphics-vnc-listen-attr-only.xml | 30 >>> ++ >>> ...generic-graphics-vnc-listen-element-minimal.xml | 30 >>> ++ >>> ...ic-graphics-vnc-listen-element-with-address.xml | 30 >>> ++ >>> .../generic-graphics-vnc-manual-port.xml | 28 >>> >>> .../generic-graphics-vnc-minimal.xml | 28 >>> >>> .../generic-graphics-vnc-socket-listen.xml | 30 >>> ++ >>> .../generic-graphics-vnc-socket.xml| 28 >>> >>> tests/genericxml2xmltest.c | 7 + >> >> The generic XML parser doesn't have any restriction on duplicate > type='vnc'/>, so these could be combined to possibly one XML file. >> >> I know there really isn't much precedent for that at the moment, but given >> the >> massive size of our test suite and the fact that much of the time is spent on >> redundant parsing and XML formatting, personally I'd like to see things move >> in that direction. > > The idea itself isn't bad, but I think that it's better to have vnc and spice > in > separate XML to make it clear which test failed so you know that it's vnc > graphics or spice graphics directly only from the test name. > Yes, agreed with splitting on VNC vs spice at least. > I've tried this command on my desktop: > > "time ./run tests/.libs/qemuxml2xmltest" > > and considering that there are 837 test cases the output of time is: > > real0m0.821s > user0m0.746s > sys 0m0.034s > > So we don't spent that much time while parsing and formatting XML. > Fair enough, but truly the big time sink is domainschematest... - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/17] genericxml2xml: add several graphics tests
On Fri, May 06, 2016 at 08:43:25AM -0400, Cole Robinson wrote: > On 05/05/2016 12:20 PM, Pavel Hrdina wrote: > > Signed-off-by: Pavel Hrdina> > --- > > .../generic-graphics-vnc-listen-attr-only.xml | 28 > > > > ...generic-graphics-vnc-listen-element-minimal.xml | 30 > > ++ > > ...ic-graphics-vnc-listen-element-with-address.xml | 30 > > ++ > > .../generic-graphics-vnc-manual-port.xml | 28 > > > > .../generic-graphics-vnc-minimal.xml | 28 > > > > .../generic-graphics-vnc-socket-listen.xml | 30 > > ++ > > .../generic-graphics-vnc-socket.xml| 28 > > > > .../generic-graphics-vnc-listen-attr-only.xml | 30 > > ++ > > ...generic-graphics-vnc-listen-element-minimal.xml | 30 > > ++ > > ...ic-graphics-vnc-listen-element-with-address.xml | 30 > > ++ > > .../generic-graphics-vnc-manual-port.xml | 28 > > > > .../generic-graphics-vnc-minimal.xml | 28 > > > > .../generic-graphics-vnc-socket-listen.xml | 30 > > ++ > > .../generic-graphics-vnc-socket.xml| 28 > > > > tests/genericxml2xmltest.c | 7 + > > The generic XML parser doesn't have any restriction on duplicate type='vnc'/>, so these could be combined to possibly one XML file. > > I know there really isn't much precedent for that at the moment, but given the > massive size of our test suite and the fact that much of the time is spent on > redundant parsing and XML formatting, personally I'd like to see things move > in that direction. The idea itself isn't bad, but I think that it's better to have vnc and spice in separate XML to make it clear which test failed so you know that it's vnc graphics or spice graphics directly only from the test name. I've tried this command on my desktop: "time ./run tests/.libs/qemuxml2xmltest" and considering that there are 837 test cases the output of time is: real0m0.821s user0m0.746s sys 0m0.034s So we don't spent that much time while parsing and formatting XML. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 05/17] qemu_hotplug: cleanup qemuDomainChangeGraphics
On Fri, May 06, 2016 at 02:30:35PM +0200, Peter Krempa wrote: > On Thu, May 05, 2016 at 18:20:24 +0200, Pavel Hrdina wrote: > > In subject: This mostly improves error messages, so cleanup is not > really a spot-on description of this patch. Not exactly, the error messages are the same, but to make the subject better I'll change it to "cleanup error messages in qemuDomainChangeGraphics". Thanks -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/17] qemu_process: move listen code out of qemuProcessSetupGraphics
On Fri, May 06, 2016 at 14:52:02 +0200, Pavel Hrdina wrote: > On Fri, May 06, 2016 at 02:10:10PM +0200, Peter Krempa wrote: > > On Thu, May 05, 2016 at 18:20:21 +0200, Pavel Hrdina wrote: > > > Move adding the config listen type=address if there is none in > > > qemuProcessPrepareDomain and move check for multiple listens to > > > qemuProcessStartValidate. > > > > > > Signed-off-by: Pavel Hrdina> > > --- > > > src/qemu/qemu_process.c | 75 > > > - > > > 1 file changed, 55 insertions(+), 20 deletions(-) > > > > > > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c > > > index 348b392..17fd566 100644 > > > --- a/src/qemu/qemu_process.c > > > +++ b/src/qemu/qemu_process.c > > > > > @@ -5138,6 +5143,35 @@ qemuProcessPrepareDomain(virConnectPtr conn, > > > if (qemuAssignDeviceAliases(vm->def, priv->qemuCaps) < 0) > > > goto cleanup; > > > > > > +/* Fill in run-time values for graphics devices. */ > > > +for (i = 0; i < vm->def->ngraphics; i++) { > > > +virDomainGraphicsDefPtr graphics = vm->def->graphics[i]; > > > +char *listenAddr = NULL; > > > + > > > +switch (graphics->type) { > > > +case VIR_DOMAIN_GRAPHICS_TYPE_VNC: > > > +listenAddr = cfg->vncListen; > > > +case VIR_DOMAIN_GRAPHICS_TYPE_SPICE: > > > +if (!listenAddr) > > > > This fallthrough case with checking whether this was set is weird. > > Looking at the caps code it looks like its guaranteed that both > > vncListen and spiceListen are always allocated, but still it looks like > > both types should either have individual calls to > > virDomainGraphicsListenAppendAddress or the call should happen after the > > switch so that we don't obscure it using the fallthrough case. > > Right, it can be easily updated that the listenAddr is set only for vnc or > spice > and the virDomainGraphicsListenAppendAddress could be moved out of the switch > with this condition: if (graphics->nListens == 0 && listeAddr). Do you > require > v2 for this? Not really. This is what I'd do. ACK using that approach signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/17] qemu_process: move listen code out of qemuProcessSetupGraphics
On Fri, May 06, 2016 at 02:10:10PM +0200, Peter Krempa wrote: > On Thu, May 05, 2016 at 18:20:21 +0200, Pavel Hrdina wrote: > > Move adding the config listen type=address if there is none in > > qemuProcessPrepareDomain and move check for multiple listens to > > qemuProcessStartValidate. > > > > Signed-off-by: Pavel Hrdina> > --- > > src/qemu/qemu_process.c | 75 > > - > > 1 file changed, 55 insertions(+), 20 deletions(-) > > > > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c > > index 348b392..17fd566 100644 > > --- a/src/qemu/qemu_process.c > > +++ b/src/qemu/qemu_process.c > > > @@ -5138,6 +5143,35 @@ qemuProcessPrepareDomain(virConnectPtr conn, > > if (qemuAssignDeviceAliases(vm->def, priv->qemuCaps) < 0) > > goto cleanup; > > > > +/* Fill in run-time values for graphics devices. */ > > +for (i = 0; i < vm->def->ngraphics; i++) { > > +virDomainGraphicsDefPtr graphics = vm->def->graphics[i]; > > +char *listenAddr = NULL; > > + > > +switch (graphics->type) { > > +case VIR_DOMAIN_GRAPHICS_TYPE_VNC: > > +listenAddr = cfg->vncListen; > > +case VIR_DOMAIN_GRAPHICS_TYPE_SPICE: > > +if (!listenAddr) > > This fallthrough case with checking whether this was set is weird. > Looking at the caps code it looks like its guaranteed that both > vncListen and spiceListen are always allocated, but still it looks like > both types should either have individual calls to > virDomainGraphicsListenAppendAddress or the call should happen after the > switch so that we don't obscure it using the fallthrough case. Right, it can be easily updated that the listenAddr is set only for vnc or spice and the virDomainGraphicsListenAppendAddress could be moved out of the switch with this condition: if (graphics->nListens == 0 && listeAddr). Do you require v2 for this? > > > +listenAddr = cfg->spiceListen; > > + > > +if (graphics->nListens == 0) { > > +if (virDomainGraphicsListenAppendAddress(graphics, > > + listenAddr) < 0) > > +goto cleanup; > > + > > +graphics->listens[0].fromConfig = true; > > +} > > +break; > > + > > +case VIR_DOMAIN_GRAPHICS_TYPE_SDL: > > +case VIR_DOMAIN_GRAPHICS_TYPE_RDP: > > +case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: > > +case VIR_DOMAIN_GRAPHICS_TYPE_LAST: > > +break; > > +} > > +} > > + > > /* "volume" type disk's source must be translated before > > * cgroup and security setting. > > */ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 4/4] qemu: command: Use -name guest= if available
On 05/06/2016 07:54 AM, John Ferlan wrote: > > > On 05/04/2016 10:56 AM, Cole Robinson wrote: >> -name guest= is the explicit parameter for passing a VM name. Using >> it is required to allow a VM with an '=' in the name >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1276485 >> --- >> src/qemu/qemu_capabilities.c | 2 ++ >> src/qemu/qemu_capabilities.h | 1 + >> src/qemu/qemu_command.c | 4 >> tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + >> tests/qemuxml2argvdata/qemuxml2argv-name-escape.args | 8 >> tests/qemuxml2argvdata/qemuxml2argv-name-escape.xml | 2 +- >> tests/qemuxml2argvtest.c | 2 +- >> 10 files changed, 17 insertions(+), 6 deletions(-) >> > > You're overloading the name-escape test with the "guest=" option which > I'm never quite sure how others feel about. I would think you'd want a > separate test that just adds the "guest=". > That's generally the pattern, to add a new XML file for every qemu addition, but that's overkill IMO > I also see this biting us at some point in the future in some test when > 'guest=' becomes the default and all the test outputs have to change to > add that. > That's not really any different than the unconditional -name debug-threads=on option we add for qemu 2.5 and later, or secrets initializing, etc - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/17] genericxml2xml: add several graphics tests
On 05/05/2016 12:20 PM, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina> --- > .../generic-graphics-vnc-listen-attr-only.xml | 28 > ...generic-graphics-vnc-listen-element-minimal.xml | 30 > ++ > ...ic-graphics-vnc-listen-element-with-address.xml | 30 > ++ > .../generic-graphics-vnc-manual-port.xml | 28 > .../generic-graphics-vnc-minimal.xml | 28 > .../generic-graphics-vnc-socket-listen.xml | 30 > ++ > .../generic-graphics-vnc-socket.xml| 28 > .../generic-graphics-vnc-listen-attr-only.xml | 30 > ++ > ...generic-graphics-vnc-listen-element-minimal.xml | 30 > ++ > ...ic-graphics-vnc-listen-element-with-address.xml | 30 > ++ > .../generic-graphics-vnc-manual-port.xml | 28 > .../generic-graphics-vnc-minimal.xml | 28 > .../generic-graphics-vnc-socket-listen.xml | 30 > ++ > .../generic-graphics-vnc-socket.xml| 28 > tests/genericxml2xmltest.c | 7 + The generic XML parser doesn't have any restriction on duplicate , so these could be combined to possibly one XML file. I know there really isn't much precedent for that at the moment, but given the massive size of our test suite and the fact that much of the time is spent on redundant parsing and XML formatting, personally I'd like to see things move in that direction. - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: fix migration/managedsave with usb keyboad
On Fri, May 06, 2016 at 14:19:39 +0200, Pavel Hrdina wrote: > Commint 36785c7e refactored the code for input devices but introduced a commit > bug that we removed all keyboard from migratable XML. We have to remove bug where > only implicit keyboards like PS2 or XEN. > > Signed-off-by: Pavel Hrdina> --- > src/conf/domain_conf.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) ACK and I think this might be worth backporting to the appropriate maint branches if they were created. Peter signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/17] genericxml2xml: add several graphics tests
On Thu, May 05, 2016 at 18:20:25 +0200, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina> --- [...] > diff --git a/tests/genericxml2xmltest.c b/tests/genericxml2xmltest.c > index 70a5203..70ecd2d 100644 > --- a/tests/genericxml2xmltest.c > +++ b/tests/genericxml2xmltest.c > @@ -77,9 +77,16 @@ mymain(void) > > DO_TEST_DIFFERENT("disk-virtio"); > > +DO_TEST_DIFFERENT("graphics-vnc-minimal"); > +DO_TEST_DIFFERENT("graphics-vnc-manual-port"); > +DO_TEST_DIFFERENT("graphics-vnc-socket"); > +DO_TEST_DIFFERENT("graphics-vnc-socket-listen"); > DO_TEST_DIFFERENT("graphics-listen-back-compat"); > DO_TEST_FULL("graphics-listen-back-compat-mismatch", 0, false, > TEST_COMPARE_DOM_XML2XML_RESULT_FAIL_PARSE); > +DO_TEST_DIFFERENT("graphics-vnc-listen-attr-only"); > +DO_TEST_DIFFERENT("graphics-vnc-listen-element-minimal"); > +DO_TEST_DIFFERENT("graphics-vnc-listen-element-with-address"); I guess the test case names are self explanatory enough to require a commit message describing the tests. ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 05/17] qemu_hotplug: cleanup qemuDomainChangeGraphics
On Thu, May 05, 2016 at 18:20:24 +0200, Pavel Hrdina wrote: In subject: This mostly improves error messages, so cleanup is not really a spot-on description of this patch. > Signed-off-by: Pavel Hrdina> --- > src/qemu/qemu_hotplug.c | 33 + > 1 file changed, 17 insertions(+), 16 deletions(-) > > diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c > index 03e5309..97f4152 100644 > --- a/src/qemu/qemu_hotplug.c > +++ b/src/qemu/qemu_hotplug.c > @@ -2618,8 +2619,9 @@ qemuDomainChangeGraphics(virQEMUDriverPtr driver, > } > > if (dev->nListens != olddev->nListens) { > -virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", > - _("cannot change the number of listen addresses")); > +virReportError(VIR_ERR_OPERATION_UNSUPPORTED, > + _("cannot change the number of listen addresses " > + "on '%s' graphics"), type); I'm not quite sure whether the 'on' preposition is correct in this context, but I don't have a better suggestion. > goto cleanup; > } > > @@ -2628,30 +2630,30 @@ qemuDomainChangeGraphics(virQEMUDriverPtr driver, > virDomainGraphicsListenDefPtr oldlisten = >listens[i]; > > if (newlisten->type != oldlisten->type) { > -virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", > - _("cannot change the type of listen address")); > +virReportError(VIR_ERR_OPERATION_UNSUPPORTED, > + _("cannot change the type of listen address " > + "on '%s' graphics"), type); > goto cleanup; > } > > switch ((virDomainGraphicsListenType) newlisten->type) { > case VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_ADDRESS: > if (STRNEQ_NULLABLE(newlisten->address, oldlisten->address)) { > -virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", > - dev->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC ? > - _("cannot change listen address setting on > vnc graphics") : > - _("cannot change listen address setting on > spice graphics")); > +virReportError(VIR_ERR_OPERATION_UNSUPPORTED, > + _("cannot change listen address setting " > + "on '%s' graphics"), type); > goto cleanup; > } > -break; > > +break; > case VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NETWORK: I prefer the empty line before the next 'case' statement. > if (STRNEQ_NULLABLE(newlisten->network, oldlisten->network)) { > -virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", > - dev->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC ? > - _("cannot change listen network setting on vnc > graphics") : > - _("cannot change listen network setting on spice > graphics")); ... ah so it was pre-existing. I don't care about it then :) > +virReportError(VIR_ERR_OPERATION_UNSUPPORTED, > + _("cannot change listen address setting " > + "on '%s' graphics"), type); > goto cleanup; > } > + > break; > > case VIR_DOMAIN_GRAPHICS_LISTEN_TYPE_NONE: ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 04/17] graphics: generate fake ports also for tests
On Thu, May 05, 2016 at 18:20:23 +0200, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina> --- > src/qemu/qemu_driver.c | 12 > src/qemu/qemu_process.c | 13 > + > tests/qemuxml2argvdata/qemuxml2argv-controller-order.args | 2 +- > tests/qemuxml2argvdata/qemuxml2argv-hugepages-numa.args | 2 +- > .../qemuxml2argv-video-device-pciaddr-default.args | 2 +- > 5 files changed, 16 insertions(+), 15 deletions(-) While I'm okay by this change itself I don't really see a reason why qemuProcessSPICEAllocatePorts and qemuProcessVNCAllocatePorts should be called in two distinct places. With the new helpers I think we have the facility to select the @alloc parameter according to the VIR_QEMU_PROCESS_START_PRETEND flag and call it just once. signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] domain_conf: fix migration/managedsave with usb keyboad
Commint 36785c7e refactored the code for input devices but introduced a bug that we removed all keyboard from migratable XML. We have to remove only implicit keyboards like PS2 or XEN. Signed-off-by: Pavel Hrdina--- 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 2c97bc1..b90c2b6 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -21193,8 +21193,10 @@ virDomainInputDefFormat(virBufferPtr buf, const char *bus = virDomainInputBusTypeToString(def->bus); /* don't format keyboard into migratable XML for backward compatibility */ -if (def->type == VIR_DOMAIN_INPUT_TYPE_KBD && -flags & VIR_DOMAIN_DEF_FORMAT_MIGRATABLE) +if (flags & VIR_DOMAIN_DEF_FORMAT_MIGRATABLE && +def->type == VIR_DOMAIN_INPUT_TYPE_KBD && +(def->bus == VIR_DOMAIN_INPUT_BUS_PS2 || + def->bus == VIR_DOMAIN_INPUT_BUS_XEN)) return 0; if (!type) { -- 2.8.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 03/17] qemu_process: handle port allocation for VNC the same way as for Spice
On Thu, May 05, 2016 at 18:20:22 +0200, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina> --- > src/qemu/qemu_driver.c | 6 +++--- > src/qemu/qemu_process.c | 29 - > src/qemu/qemu_process.h | 3 +++ > 3 files changed, 30 insertions(+), 8 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/4] qemu: handle ',' and '=' in VM name
On 05/06/2016 07:54 AM, John Ferlan wrote: > > > On 05/04/2016 10:56 AM, Cole Robinson wrote: >> This series adds qemu cli comma escaping to several places that >> are dependent on the VM name, to enable names with embedded commas. >> >> Patch 4 makes use of qemu -name guest=X value to allow names with >> '=' in them. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=639926 >> https://bugzilla.redhat.com/show_bug.cgi?id=1276485 >> >> Note: There's likely other places that are VM name dependent that need >> comma escaping too, but this hits the mandatory ones. I've listed some >> more on the BiteSizedTasks page: >> >> http://wiki.libvirt.org/page/BiteSizedTasks#qemu:_Use_comma_escaping_for_more_command_line_values >> >> v2: >> Rebase to master >> >> Cole Robinson (4): >> qemu: command: escape commas in VM name >> qemu: command: escape commas in secret master path >> qemu: command: escape commas in chardev socket path >> qemu: command: Use -name guest= if available >> >> src/qemu/qemu_capabilities.c | 2 ++ >> src/qemu/qemu_capabilities.h | 1 + >> src/qemu/qemu_command.c| 22 >> tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + >> tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + >> .../qemuxml2argvdata/qemuxml2argv-name-escape.args | 24 >> ++ >> .../qemuxml2argvdata/qemuxml2argv-name-escape.xml | 18 >> tests/qemuxml2argvtest.c | 2 ++ >> 10 files changed, 65 insertions(+), 8 deletions(-) >> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-name-escape.args >> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-name-escape.xml >> > > ewww again ;-) > > While I cannot imagine a reason for someone (other than testing perhaps) > to want a "," or an "=" in a vm name, I suppose since it's possible to > handle by qemu, then we should 'handle' it. > > Sorry I dropped the ball after my initial pass - I guess I was wondering > if there were any other (similar) feelings! > No worries > After reading the bz, I see why you've gone with double commas, although > it wasn't apparent without that read... So maybe each commit that adds > that double comma escape could explain why the double comma works (or > even at points in the code where it occurs?). > Yeah the double comma is the qemu convention. I'll add an explicit function like qemuBufEscapeCommas or something to make this a bit more obvious > Searching qemu_command.c for domainChannelTargetDir and it's seems > things are covered (good)... Searching for domainLibDir and I think > there's one usage not covered - qemuBuildGraphicsVNCCommandLine uses it > to build "$path_with_domainLibDir/vnc.sock". > Okay, I'll add that. > Of course finding these "one off" type issues makes me think at some > point in the future one of those will be used for "something" and the > double comma will be missed. So should we generate a local "escaped" > names for domainLibDir and domainChannelTargetDir that would include the > double comma and that would be passed to the corresponding users? > TBH I don't really think this is important enough to try and come up with a safe generalized solution at this point. I think it will largely work itself out if I add the explicit escaping function, and there's enough usages in qemu_command.c that they will get cargoculted around when new code is added. > I think as long as you cover the VNC case and add a few more words why > the ",," can be used on the command line, then the series seems > reasonable to me, although you may want to wait a bit to push to see if > anyone else has angst over the two changes, especially now having > "guest=$name" be the default for anyone using qemu 2.1 or later. > I'll send a v3 anyways so we can see if anyone cares - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 3/4] qemu: command: escape commas in chardev socket path
On 05/06/2016 07:54 AM, John Ferlan wrote: > > > On 05/04/2016 10:56 AM, Cole Robinson wrote: >> After this, a default virt-manager VM will startup with a comma >> in the VM name: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=639926 >> --- >> src/qemu/qemu_command.c | 9 - >> tests/qemuxml2argvdata/qemuxml2argv-name-escape.args | 2 +- >> 2 files changed, 5 insertions(+), 6 deletions(-) >> > > FWIW: > w/r/t my comment in your v1 about vmagent... It's the "guest_agent" I > was thinking about. In any case, I see it uses the chardev path > generation code, so I think that's covered by your patch 3. > > >> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c >> index d54d0d1..c2f55b5 100644 >> --- a/src/qemu/qemu_command.c >> +++ b/src/qemu/qemu_command.c >> @@ -4833,11 +4833,10 @@ qemuBuildChrChardevStr(virLogManagerPtr logManager, >> break; >> >> case VIR_DOMAIN_CHR_TYPE_UNIX: >> -virBufferAsprintf(, >> - "socket,id=char%s,path=%s%s", >> - alias, >> - dev->data.nix.path, >> - dev->data.nix.listen ? ",server,nowait" : ""); >> +virBufferAsprintf(, "socket,id=char%s,path=", alias); >> +virBufferEscape(, ',', ",", "%s", dev->data.nix.path); > > Unless you know/see that the data.nix.path is built using > domainChannelTargetDir during qemuBuildChannelsCommandLine it may not be > "intuitively obvious" why doing the escape here is necessary... > It's not specific to the autocreated socket path based on domainChannelTargetDir, the user could have passed in a manual path with a comma in it The rule is that any time a user specified string is passed to the qemu command line, we should be escaping commas. happens to trickle out into several other places, but doing this for the unix path is still beneficial regardless of the focus of this series - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/17] qemu_process: move listen code out of qemuProcessSetupGraphics
On Thu, May 05, 2016 at 18:20:21 +0200, Pavel Hrdina wrote: > Move adding the config listen type=address if there is none in > qemuProcessPrepareDomain and move check for multiple listens to > qemuProcessStartValidate. > > Signed-off-by: Pavel Hrdina> --- > src/qemu/qemu_process.c | 75 > - > 1 file changed, 55 insertions(+), 20 deletions(-) > > diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c > index 348b392..17fd566 100644 > --- a/src/qemu/qemu_process.c > +++ b/src/qemu/qemu_process.c > @@ -5138,6 +5143,35 @@ qemuProcessPrepareDomain(virConnectPtr conn, > if (qemuAssignDeviceAliases(vm->def, priv->qemuCaps) < 0) > goto cleanup; > > +/* Fill in run-time values for graphics devices. */ > +for (i = 0; i < vm->def->ngraphics; i++) { > +virDomainGraphicsDefPtr graphics = vm->def->graphics[i]; > +char *listenAddr = NULL; > + > +switch (graphics->type) { > +case VIR_DOMAIN_GRAPHICS_TYPE_VNC: > +listenAddr = cfg->vncListen; > +case VIR_DOMAIN_GRAPHICS_TYPE_SPICE: > +if (!listenAddr) This fallthrough case with checking whether this was set is weird. Looking at the caps code it looks like its guaranteed that both vncListen and spiceListen are always allocated, but still it looks like both types should either have individual calls to virDomainGraphicsListenAppendAddress or the call should happen after the switch so that we don't obscure it using the fallthrough case. > +listenAddr = cfg->spiceListen; > + > +if (graphics->nListens == 0) { > +if (virDomainGraphicsListenAppendAddress(graphics, > + listenAddr) < 0) > +goto cleanup; > + > +graphics->listens[0].fromConfig = true; > +} > +break; > + > +case VIR_DOMAIN_GRAPHICS_TYPE_SDL: > +case VIR_DOMAIN_GRAPHICS_TYPE_RDP: > +case VIR_DOMAIN_GRAPHICS_TYPE_DESKTOP: > +case VIR_DOMAIN_GRAPHICS_TYPE_LAST: > +break; > +} > +} > + > /* "volume" type disk's source must be translated before > * cgroup and security setting. > */ signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virCgroupValidateMachineGroup: Reflect change in CGroup struct naming
On 05/05/2016 11:56 AM, Michal Privoznik wrote: > Fron c3bd0019c0e on instead of creating the following path for > cgroups: > > /sys/fs/cgroupX/$name.libvirt-$driver > > we generate rather more verbose one: > > /sys/fs/cgroupX/$driver-$id-$name.libvirt-$driver > > where $name is optional and included iff contains allowed chars. > See original commit for more reasoning. Now, problem with the > original commit is that we are unable to start any LXC domain > after it. Because when starting LXC container, the CGroup layout > is created by our lxc_controller process and then detected and > validated by libvirtd. The validation is done by trying to match > detected layout against all the possible patterns for cgroup > paths that we've ever had. And the commit in question forgot to > update this part of the code. > > Signed-off-by: Michal Privoznik> --- > > I am really surprised how long this bug went unnoticed. Is > anybody using LXC? When pushed, it should be backported to > 1.3.2+. FWIW libvirt.git without this patch (and with f24 libvirt 1.3.2 package) my containers start fine, and as part of the upstream bug cleanup I did a handful of lxc testing. So I don't think the failure is quite as unconditional as you suggest - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 3/4] qemu: command: escape commas in chardev socket path
On 05/04/2016 10:56 AM, Cole Robinson wrote: > After this, a default virt-manager VM will startup with a comma > in the VM name: > > https://bugzilla.redhat.com/show_bug.cgi?id=639926 > --- > src/qemu/qemu_command.c | 9 - > tests/qemuxml2argvdata/qemuxml2argv-name-escape.args | 2 +- > 2 files changed, 5 insertions(+), 6 deletions(-) > FWIW: w/r/t my comment in your v1 about vmagent... It's the "guest_agent" I was thinking about. In any case, I see it uses the chardev path generation code, so I think that's covered by your patch 3. > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > index d54d0d1..c2f55b5 100644 > --- a/src/qemu/qemu_command.c > +++ b/src/qemu/qemu_command.c > @@ -4833,11 +4833,10 @@ qemuBuildChrChardevStr(virLogManagerPtr logManager, > break; > > case VIR_DOMAIN_CHR_TYPE_UNIX: > -virBufferAsprintf(, > - "socket,id=char%s,path=%s%s", > - alias, > - dev->data.nix.path, > - dev->data.nix.listen ? ",server,nowait" : ""); > +virBufferAsprintf(, "socket,id=char%s,path=", alias); > +virBufferEscape(, ',', ",", "%s", dev->data.nix.path); Unless you know/see that the data.nix.path is built using domainChannelTargetDir during qemuBuildChannelsCommandLine it may not be "intuitively obvious" why doing the escape here is necessary... John > +if (dev->data.nix.listen) > +virBufferAddLit(, ",server,nowait"); > break; > > case VIR_DOMAIN_CHR_TYPE_SPICEVMC: > diff --git a/tests/qemuxml2argvdata/qemuxml2argv-name-escape.args > b/tests/qemuxml2argvdata/qemuxml2argv-name-escape.args > index a5e35b8..772d94f 100644 > --- a/tests/qemuxml2argvdata/qemuxml2argv-name-escape.args > +++ b/tests/qemuxml2argvdata/qemuxml2argv-name-escape.args > @@ -15,7 +15,7 @@ bar/master-key.aes \ > -uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ > -nographic \ > -nodefaults \ > --chardev socket,id=charmonitor,path=/tmp/lib/domain--1-foo,bar/monitor.sock,\ > +-chardev > socket,id=charmonitor,path=/tmp/lib/domain--1-foo,,bar/monitor.sock,\ > server,nowait \ > -mon chardev=charmonitor,id=monitor,mode=readline \ > -no-acpi \ > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/4] qemu: handle ',' and '=' in VM name
On 05/04/2016 10:56 AM, Cole Robinson wrote: > This series adds qemu cli comma escaping to several places that > are dependent on the VM name, to enable names with embedded commas. > > Patch 4 makes use of qemu -name guest=X value to allow names with > '=' in them. > > https://bugzilla.redhat.com/show_bug.cgi?id=639926 > https://bugzilla.redhat.com/show_bug.cgi?id=1276485 > > Note: There's likely other places that are VM name dependent that need > comma escaping too, but this hits the mandatory ones. I've listed some > more on the BiteSizedTasks page: > > http://wiki.libvirt.org/page/BiteSizedTasks#qemu:_Use_comma_escaping_for_more_command_line_values > > v2: > Rebase to master > > Cole Robinson (4): > qemu: command: escape commas in VM name > qemu: command: escape commas in secret master path > qemu: command: escape commas in chardev socket path > qemu: command: Use -name guest= if available > > src/qemu/qemu_capabilities.c | 2 ++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c| 22 > tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + > .../qemuxml2argvdata/qemuxml2argv-name-escape.args | 24 > ++ > .../qemuxml2argvdata/qemuxml2argv-name-escape.xml | 18 > tests/qemuxml2argvtest.c | 2 ++ > 10 files changed, 65 insertions(+), 8 deletions(-) > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-name-escape.args > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-name-escape.xml > ewww again ;-) While I cannot imagine a reason for someone (other than testing perhaps) to want a "," or an "=" in a vm name, I suppose since it's possible to handle by qemu, then we should 'handle' it. Sorry I dropped the ball after my initial pass - I guess I was wondering if there were any other (similar) feelings! After reading the bz, I see why you've gone with double commas, although it wasn't apparent without that read... So maybe each commit that adds that double comma escape could explain why the double comma works (or even at points in the code where it occurs?). Searching qemu_command.c for domainChannelTargetDir and it's seems things are covered (good)... Searching for domainLibDir and I think there's one usage not covered - qemuBuildGraphicsVNCCommandLine uses it to build "$path_with_domainLibDir/vnc.sock". Of course finding these "one off" type issues makes me think at some point in the future one of those will be used for "something" and the double comma will be missed. So should we generate a local "escaped" names for domainLibDir and domainChannelTargetDir that would include the double comma and that would be passed to the corresponding users? I think as long as you cover the VNC case and add a few more words why the ",," can be used on the command line, then the series seems reasonable to me, although you may want to wait a bit to push to see if anyone else has angst over the two changes, especially now having "guest=$name" be the default for anyone using qemu 2.1 or later. John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 4/4] qemu: command: Use -name guest= if available
On 05/04/2016 10:56 AM, Cole Robinson wrote: > -name guest= is the explicit parameter for passing a VM name. Using > it is required to allow a VM with an '=' in the name > > https://bugzilla.redhat.com/show_bug.cgi?id=1276485 > --- > src/qemu/qemu_capabilities.c | 2 ++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 4 > tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 + > tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 1 + > tests/qemuxml2argvdata/qemuxml2argv-name-escape.args | 8 > tests/qemuxml2argvdata/qemuxml2argv-name-escape.xml | 2 +- > tests/qemuxml2argvtest.c | 2 +- > 10 files changed, 17 insertions(+), 6 deletions(-) > You're overloading the name-escape test with the "guest=" option which I'm never quite sure how others feel about. I would think you'd want a separate test that just adds the "guest=". I also see this biting us at some point in the future in some test when 'guest=' becomes the default and all the test outputs have to change to add that. I'm sure it seems you're chasing a moving target with changes to the *.caps files... Recent changes in that space will cause more adjustments here . > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index 65c3d69..da47759 100644 > --- a/src/qemu/qemu_capabilities.c > +++ b/src/qemu/qemu_capabilities.c > @@ -328,6 +328,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, >"device-tray-moved-event", >"nec-usb-xhci-ports", >"virtio-scsi-pci.iothread", > + "name-guest", > ); > > > @@ -2666,6 +2667,7 @@ static struct virQEMUCapsCommandLineProps > virQEMUCapsCommandLine[] = { > { "spice", "gl", QEMU_CAPS_SPICE_GL }, > { "chardev", "logfile", QEMU_CAPS_CHARDEV_LOGFILE }, > { "name", "debug-threads", QEMU_CAPS_NAME_DEBUG_THREADS }, > +{ "name", "guest", QEMU_CAPS_NAME_GUEST }, > }; > > static int > diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h > index e7d0a60..9145f2d 100644 > --- a/src/qemu/qemu_capabilities.h > +++ b/src/qemu/qemu_capabilities.h > @@ -359,6 +359,7 @@ typedef enum { > QEMU_CAPS_DEVICE_TRAY_MOVED, /* DEVICE_TRAY_MOVED event */ > QEMU_CAPS_NEC_USB_XHCI_PORTS, /* -device nec-usb-xhci.p3 ports setting */ > QEMU_CAPS_VIRTIO_SCSI_IOTHREAD, /* virtio-scsi-{pci,ccw}.iothread */ > +QEMU_CAPS_NAME_GUEST, /* -name guest= */ > > QEMU_CAPS_LAST /* this must always be the last item */ > } virQEMUCapsFlags; > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c > index c2f55b5..570566c 100644 > --- a/src/qemu/qemu_command.c > +++ b/src/qemu/qemu_command.c > @@ -6790,6 +6790,10 @@ qemuBuildNameCommandLine(virCommandPtr cmd, > > virCommandAddArg(cmd, "-name"); > > +/* The 'guest' option let's us handle a name with '=' embedded in it */ > +if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NAME_GUEST)) > +virBufferAddLit(, "guest="); > + So, any domain that has qemu 2.1 or later will use the "-name guest=$name..." naming scheme rather than just "-name $name..." (regardless of whether there's a '=' in $name or not). I don't necessarily mind using the guest=$name syntax; however, it could be quite a surprise to anything that searches on/for "-name $name" rather than "-name guest=$name" in/for the running qemu John > virBufferEscape(, ',', ",", "%s", def->name); > > if (cfg->setProcessName && > diff --git a/tests/qemucapabilitiesdata/caps_2.1.1-1.caps > b/tests/qemucapabilitiesdata/caps_2.1.1-1.caps > index 729000f..29214bb 100644 > --- a/tests/qemucapabilitiesdata/caps_2.1.1-1.caps > +++ b/tests/qemucapabilitiesdata/caps_2.1.1-1.caps > @@ -164,4 +164,5 @@ > > > > + > > diff --git a/tests/qemucapabilitiesdata/caps_2.4.0-1.caps > b/tests/qemucapabilitiesdata/caps_2.4.0-1.caps > index 8009b8f..7b1de29 100644 > --- a/tests/qemucapabilitiesdata/caps_2.4.0-1.caps > +++ b/tests/qemucapabilitiesdata/caps_2.4.0-1.caps > @@ -177,4 +177,5 @@ > > > > + > > diff --git a/tests/qemucapabilitiesdata/caps_2.5.0-1.caps > b/tests/qemucapabilitiesdata/caps_2.5.0-1.caps > index e139455..19192da 100644 > --- a/tests/qemucapabilitiesdata/caps_2.5.0-1.caps > +++ b/tests/qemucapabilitiesdata/caps_2.5.0-1.caps > @@ -178,4 +178,5 @@ > > > > + > > diff --git a/tests/qemucapabilitiesdata/caps_2.6.0-1.caps > b/tests/qemucapabilitiesdata/caps_2.6.0-1.caps > index ec5bfcc..59f637f 100644 > --- a/tests/qemucapabilitiesdata/caps_2.6.0-1.caps > +++ b/tests/qemucapabilitiesdata/caps_2.6.0-1.caps > @@ -183,4 +183,5 @@ > > > > + > > diff --git a/tests/qemuxml2argvdata/qemuxml2argv-name-escape.args
Re: [libvirt] [PATCH v5 0/2] qemu: Support for QXL heads
On Fri, May 06, 2016 at 01:27:15PM +0200, Pavel Hrdina wrote: > On Thu, May 05, 2016 at 07:18:51PM -0400, John Ferlan wrote: > > [...] > > > Been sitting on list for a while > > > > Obviously I think you know you have to update to top of tree > > > > Would be nice to perhaps add a few intro comments to > > qemuMigratePrepareDomain at least with respect to what the purpose is > > and what "could" be done in the future in the code. Looks like to me > > it's now a shim to qemuProcessPrepareDomain to take care of any of those > > "inconsistencies" between what can be supported in/on the new system > > (perhaps could work in the opposite direction too ;-))... When I'm > > reading code, I'm not necessarily looking at the commit message that > > added which may have that information. > > > > I think you could also update the commit message to point at the > > previous code that was reverted to help understand the history. > > > > ACK for the concept - looks like things are OK to me. > > > > John > > The only issue with this patch is that it breaks migration back to older > libvirt. We generally try to not break migration to old libvirt if you > migrate > from new libvirt to old libvirt with the same XML that would be also valid for > the old libvirt. Since there is no change in the XML and we start using the > 'heads' attribute and we now pass that value to qemu you cannot migrate back > to > some older libvirt. > > NACK, we need to figure this out. Yep, the major use of QXL is RHEV/oVirt and they explicitly require libvirt to support migration to old versions. So we need to figure this out. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v5 0/2] qemu: Support for QXL heads
On Thu, May 05, 2016 at 07:18:51PM -0400, John Ferlan wrote: [...] > Been sitting on list for a while > > Obviously I think you know you have to update to top of tree > > Would be nice to perhaps add a few intro comments to > qemuMigratePrepareDomain at least with respect to what the purpose is > and what "could" be done in the future in the code. Looks like to me > it's now a shim to qemuProcessPrepareDomain to take care of any of those > "inconsistencies" between what can be supported in/on the new system > (perhaps could work in the opposite direction too ;-))... When I'm > reading code, I'm not necessarily looking at the commit message that > added which may have that information. > > I think you could also update the commit message to point at the > previous code that was reverted to help understand the history. > > ACK for the concept - looks like things are OK to me. > > John The only issue with this patch is that it breaks migration back to older libvirt. We generally try to not break migration to old libvirt if you migrate from new libvirt to old libvirt with the same XML that would be also valid for the old libvirt. Since there is no change in the XML and we start using the 'heads' attribute and we now pass that value to qemu you cannot migrate back to some older libvirt. NACK, we need to figure this out. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On Fri, May 06, 2016 at 12:29:34 +0200, Peter Krempa wrote: > On Fri, May 06, 2016 at 12:23:04 +0200, Jiri Denemark wrote: > > On Fri, May 06, 2016 at 10:02:12 +0200, Peter Krempa wrote: > > > On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: > > > > Signed-off-by: Jiri Denemark> > > > > > Please explain the difference between caps_2.6.0-1.aarch64.replies > > > caps_2.6.0-2.aarch64.replies. At least the difference how they were > > > obtained. > > > > Well, I asked Andrea to provide me some data from aarch64 and ppc64le > > hosts :-) The difference is in GIC version supported on a two different > > hosts. > > Well I kind of implied that you should put it into the commit message > for further reference. I don't really care at this point about the > difference but somebody might care in the future when touching the > tests. Yeah, sorry about that. It wasn't obvious to me that you wanted me to update the commit message. Try to be explicit next time :-) Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On Fri, May 06, 2016 at 06:39:15 -0400, John Ferlan wrote: > > > On 05/06/2016 06:29 AM, Peter Krempa wrote: > > On Fri, May 06, 2016 at 12:23:04 +0200, Jiri Denemark wrote: > >> On Fri, May 06, 2016 at 10:02:12 +0200, Peter Krempa wrote: > >>> On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> >>> > >>> Please explain the difference between caps_2.6.0-1.aarch64.replies > >>> caps_2.6.0-2.aarch64.replies. At least the difference how they were > >>> obtained. > >> > >> Well, I asked Andrea to provide me some data from aarch64 and ppc64le > >> hosts :-) The difference is in GIC version supported on a two different > >> hosts. > > > > Well I kind of implied that you should put it into the commit message > > for further reference. I don't really care at this point about the > > difference but somebody might care in the future when touching the > > tests. > > > > > > FWIW: For example, is there a process or script (or something) somewhere > that you use in order to generate the files? Yes, "tests/qemucapsprobe /path/to/binary >caps.replies". It's mainly useful for adding data files. It can be used for updating existing ones in case you still have the binary and can just re-probe it. If you want to add staff to existing files manually, qemucapsprobe won't help you. But, Peter is planning to enhance the fake monitor and *.replies data format so that you don't have to care about ids or order (to some extent) in which you add the new replies. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpu: add ABM to Haswell* and Broadwell* CPU models
On Fri, May 06, 2016 at 17:53:04 +0800, Eli Qiao wrote: > Corresponding QEMU commits: > becb66673ec30cb604926d247ab9449a60ad8b11 > > Signed-off-by: Eli Qiao> --- > src/cpu/cpu_map.xml | 4 > 1 file changed, 4 insertions(+) NACK. We don't add features to models since it could break existing setups. In any case, presence of any flag in CPU models does not really influence whether that flag is going to be provided to a guest. That part is driven by QEMU. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On 05/06/2016 06:29 AM, Peter Krempa wrote: > On Fri, May 06, 2016 at 12:23:04 +0200, Jiri Denemark wrote: >> On Fri, May 06, 2016 at 10:02:12 +0200, Peter Krempa wrote: >>> On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: Signed-off-by: Jiri Denemark>>> >>> Please explain the difference between caps_2.6.0-1.aarch64.replies >>> caps_2.6.0-2.aarch64.replies. At least the difference how they were >>> obtained. >> >> Well, I asked Andrea to provide me some data from aarch64 and ppc64le >> hosts :-) The difference is in GIC version supported on a two different >> hosts. > > Well I kind of implied that you should put it into the commit message > for further reference. I don't really care at this point about the > difference but somebody might care in the future when touching the > tests. > > FWIW: For example, is there a process or script (or something) somewhere that you use in order to generate the files? I know when I recently touched these to add something for virtio-scsi-{pci,ccw} - it took me a bit to recall "how" to get the information necessary. Then as Cole pointed out during review - inserting a new "id" really doesn't require one to adjust all the following id's, but since it was done before. John (I know - patches welcome, right? ;-)) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On Fri, May 06, 2016 at 12:23:04 +0200, Jiri Denemark wrote: > On Fri, May 06, 2016 at 10:02:12 +0200, Peter Krempa wrote: > > On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: > > > Signed-off-by: Jiri Denemark> > > > Please explain the difference between caps_2.6.0-1.aarch64.replies > > caps_2.6.0-2.aarch64.replies. At least the difference how they were > > obtained. > > Well, I asked Andrea to provide me some data from aarch64 and ppc64le > hosts :-) The difference is in GIC version supported on a two different > hosts. Well I kind of implied that you should put it into the commit message for further reference. I don't really care at this point about the difference but somebody might care in the future when touching the tests. signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On Fri, May 06, 2016 at 10:02:12 +0200, Peter Krempa wrote: > On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: > > Signed-off-by: Jiri Denemark> > Please explain the difference between caps_2.6.0-1.aarch64.replies > caps_2.6.0-2.aarch64.replies. At least the difference how they were > obtained. Well, I asked Andrea to provide me some data from aarch64 and ppc64le hosts :-) The difference is in GIC version supported on a two different hosts. > ACK Thanks for the review. I implemented the changes you suggested and pushed this series. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] cpu: add ABM to Haswell* and Broadwell* CPU models
Corresponding QEMU commits: becb66673ec30cb604926d247ab9449a60ad8b11 Signed-off-by: Eli Qiao--- src/cpu/cpu_map.xml | 4 1 file changed, 4 insertions(+) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 0b6d424..d9eb729 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -919,6 +919,7 @@ + @@ -971,6 +972,7 @@ + @@ -1026,6 +1028,7 @@ + @@ -1082,6 +1085,7 @@ + -- 1.9.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 01/17] graphics: use enums instead of int
On Thu, May 05, 2016 at 18:20:20 +0200, Pavel Hrdina wrote: > Signed-off-by: Pavel Hrdina> --- > src/conf/domain_conf.c | 2 ++ > src/conf/domain_conf.h | 14 +++--- > src/libxl/libxl_conf.c | 8 > src/qemu/qemu_command.c | 14 +- > 4 files changed, 30 insertions(+), 8 deletions(-) > > diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h > index b7b099c..b825477 100644 > --- a/src/conf/domain_conf.h > +++ b/src/conf/domain_conf.h > @@ -1552,7 +1552,7 @@ typedef enum { > typedef struct _virDomainGraphicsListenDef virDomainGraphicsListenDef; > typedef virDomainGraphicsListenDef *virDomainGraphicsListenDefPtr; > struct _virDomainGraphicsListenDef { > -int type; /* enum virDomainGraphicsListenType */ > +virDomainGraphicsListenType type; Same as below. Assigned in virDomainGraphicsListenDefParseXML. > char *address; > char *network; > bool fromConfig;/* true if the @address is config file originated */ > @@ -1564,7 +1564,7 @@ struct _virDomainGraphicsDef { > * Value 0 means port wasn't specified in XML at all. > * Positive value is actual port number given in XML. > */ > -int type; > +virDomainGraphicsType type; In virDomainGraphicsDefParseXML this struct member is directly assigned without a temp variable so virDomainGraphicsTypeFromString won't be able to return error as enum types are unsigned . > union { > struct { > int port; ACK with a temp variable added. Peter signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 12/12] domaincapstest: Add tests for QEMU 2.6
On Thu, May 05, 2016 at 18:42:14 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> --- > .../domaincaps-qemu_2.6.0-1.xml| 63 > .../domaincaps-qemu_2.6.0-2.xml| 63 > .../domaincaps-qemu_2.6.0-3.xml| 67 > ++ > .../domaincaps-qemu_2.6.0-4.xml| 67 > ++ > .../domaincaps-qemu_2.6.0-5.xml| 61 > tests/domaincapstest.c | 20 +++ > 6 files changed, 341 insertions(+) > create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_2.6.0-1.xml > create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_2.6.0-2.xml > create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_2.6.0-3.xml > create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_2.6.0-4.xml > create mode 100644 tests/domaincapsschemadata/domaincaps-qemu_2.6.0-5.xml ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/12] qemucapabilitiestest: Add tests for aarch64 and ppc64le
On Thu, May 05, 2016 at 18:42:13 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri DenemarkPlease explain the difference between caps_2.6.0-1.aarch64.replies caps_2.6.0-2.aarch64.replies. At least the difference how they were obtained. > --- > .../caps_2.6.0-1.aarch64.replies | 4940 > .../qemucapabilitiesdata/caps_2.6.0-1.aarch64.xml | 238 + > .../caps_2.6.0-1.ppc64le.replies | 6163 > > .../qemucapabilitiesdata/caps_2.6.0-1.ppc64le.xml | 604 ++ > .../caps_2.6.0-2.aarch64.replies | 4940 > .../qemucapabilitiesdata/caps_2.6.0-2.aarch64.xml | 238 + > tests/qemucapabilitiestest.c |3 + > 7 files changed, 17126 insertions(+) > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.aarch64.replies > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.aarch64.xml > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.ppc64le.replies > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.ppc64le.xml > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-2.aarch64.replies > create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-2.aarch64.xml ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 10/12] domaincapstest: Use default machine type
On Thu, May 05, 2016 at 18:42:12 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri DenemarkA little bit of explanation would be preferred. > --- > tests/domaincapsschemadata/domaincaps-qemu_1.6.50-1.xml | 2 +- > tests/domaincapstest.c | 17 > ++--- > 2 files changed, 15 insertions(+), 4 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 09/12] qemucapabilitiestest: Rename *.caps to *.xml
On Thu, May 05, 2016 at 18:42:11 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> --- ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 08/12] qemucapabilitiestest: Test all capabilities
On Thu, May 05, 2016 at 18:42:10 +0200, Jiri Denemark wrote: > Enhance the test to cover all capabilities we probe for rather than > testing the flags only. > > Signed-off-by: Jiri Denemark> --- [...] > diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c > index 80f3cd8..1f2d5d7 100644 > --- a/tests/qemucapabilitiestest.c > +++ b/tests/qemucapabilitiestest.c [...] > @@ -134,17 +137,19 @@ testQemuCaps(const void *opaque) > if (!(mon = testQemuFeedMonitor(replies, data->xmlopt))) > goto cleanup; > > -if (!(capsExpected = qemuTestParseCapabilities(capsFile))) > -goto cleanup; > - > -if (!(capsActual = virQEMUCapsNew())) > -goto cleanup; > - > -if (virQEMUCapsInitQMPMonitor(capsActual, > +if (!(capsActual = virQEMUCapsNew()) || > +virQEMUCapsInitQMPMonitor(capsActual, >qemuMonitorTestGetMonitor(mon)) < 0) > goto cleanup; > > -if (testQemuCapsCompare(capsExpected, capsActual) < 0) > +if ((capsExpected = qemuTestParseCapabilities(capsFile)) && > +testQemuCapsFlagsCompare(capsExpected, capsActual) < 0) So here you compare the flags only ... > +goto cleanup; > + > +if (!(actual = virQEMUCapsFormatCache(capsActual, 0, 0))) > +goto cleanup; > + > +if (virtTestCompareToFile(actual, capsFile) < 0) and here you compare them again with the rest of the file. > goto cleanup; > > ret = 0; I think the first comparison can be dropped. This would require to fix the flags first and then in a second run fix all the rest. The second check should do the trick by itself. ACK with the first check dropped signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 07/12] qemucapabilitiestest: Reorder flags in caps files
On Thu, May 05, 2016 at 18:42:09 +0200, Jiri Denemark wrote: > The flags should follow the order in which they are defined in > virQEMUCaps enum. > > Signed-off-by: Jiri Denemark> --- > tests/qemucapabilitiesdata/caps_1.5.3-1.x86_64.caps | 2 +- > tests/qemucapabilitiesdata/caps_1.6.0-1.x86_64.caps | 2 +- > tests/qemucapabilitiesdata/caps_1.6.50-1.x86_64.caps | 2 +- > tests/qemucapabilitiesdata/caps_2.1.1-1.x86_64.caps | 4 ++-- > tests/qemucapabilitiesdata/caps_2.4.0-1.x86_64.caps | 6 +++--- > tests/qemucapabilitiesdata/caps_2.5.0-1.x86_64.caps | 6 +++--- > tests/qemucapabilitiesdata/caps_2.6.0-1.x86_64.caps | 6 +++--- > 7 files changed, 14 insertions(+), 14 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 06/12] qemucapabilitiestest: Reindent *.caps files
On Thu, May 05, 2016 at 18:42:08 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> --- ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 05/12] qemucapabilitiestest: Uses consistent names
On Thu, May 05, 2016 at 18:42:07 +0200, Jiri Denemark wrote: > In other tests we use "expected" and "actual" to refer to the expected > outcome of the tested API and the result we got, respectively. > > Signed-off-by: Jiri Denemark> --- > tests/qemucapabilitiestest.c | 31 --- > 1 file changed, 16 insertions(+), 15 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 04/12] qemu: Export caps cache APIs for tests
On Thu, May 05, 2016 at 18:42:06 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> --- > src/qemu/qemu_capabilities.c | 4 ++-- > src/qemu/qemu_capspriv.h | 9 + > 2 files changed, 11 insertions(+), 2 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 03/12] qemu: Separate formatting from saving into caps cache
On Thu, May 05, 2016 at 18:42:05 +0200, Jiri Denemark wrote: > We will need to use the formatter directly for testing QEMU capabilities > code. > > Signed-off-by: Jiri Denemark> --- > src/qemu/qemu_capabilities.c | 32 ++-- > 1 file changed, 22 insertions(+), 10 deletions(-) > > diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c > index c2ba69d..862aed0 100644 > --- a/src/qemu/qemu_capabilities.c > +++ b/src/qemu/qemu_capabilities.c [...] > @@ -3094,10 +3095,21 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const > char *filename) > virBufferAdjustIndent(, -2); > virBufferAddLit(, "\n"); > > -if (virBufferCheckError() < 0) > -goto cleanup; > +if (virBufferCheckError() == 0) > +ret = virBufferContentAndReset(); > > -xml = virBufferContentAndReset(); > +return ret; > +} > + Two newlines to separate functions. > +static int > +virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char *filename) > +{ > +char *xml = NULL; > +int ret = -1; > + > +xml = virQEMUCapsFormatCache(qemuCaps, > + virGetSelfLastChanged(), > + LIBVIR_VERSION_NUMBER); > > if (virFileWriteStr(filename, xml, 0600) < 0) { > virReportSystemError(errno, ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/12] qemucapabilitiestest: Prepare for testing non-x86_64 archs
On Thu, May 05, 2016 at 18:42:04 +0200, Jiri Denemark wrote: > Signed-off-by: Jiri Denemark> --- ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 01/12] tests: Refactor domaincapstest
On Thu, May 05, 2016 at 18:42:03 +0200, Jiri Denemark wrote: > The test was just a big mess passing callbacks and their data through > data for another callback. > > Signed-off-by: Jiri Denemark> --- > tests/domaincapstest.c | 176 > ++--- > 1 file changed, 93 insertions(+), 83 deletions(-) ACK signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virCgroupValidateMachineGroup: Reflect change in CGroup struct naming
On Thu, May 05, 2016 at 05:56:55PM +0200, Michal Privoznik wrote: > Fron c3bd0019c0e on instead of creating the following path for > cgroups: > > /sys/fs/cgroupX/$name.libvirt-$driver > > we generate rather more verbose one: > > /sys/fs/cgroupX/$driver-$id-$name.libvirt-$driver > > where $name is optional and included iff contains allowed chars. > See original commit for more reasoning. Now, problem with the > original commit is that we are unable to start any LXC domain > after it. Because when starting LXC container, the CGroup layout > is created by our lxc_controller process and then detected and > validated by libvirtd. The validation is done by trying to match > detected layout against all the possible patterns for cgroup > paths that we've ever had. And the commit in question forgot to > update this part of the code. > > Signed-off-by: Michal Privoznik> --- > > I am really surprised how long this bug went unnoticed. Is > anybody using LXC? When pushed, it should be backported to > 1.3.2+. > > src/util/vircgroup.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c > index da5ccff..add6c5f 100644 > --- a/src/util/vircgroup.c > +++ b/src/util/vircgroup.c > @@ -261,12 +261,17 @@ virCgroupValidateMachineGroup(virCgroupPtr group, > char *scopename_new = NULL; > char *machinename = virSystemdMakeMachineName(drivername, id, >name, privileged); > +char *partmachinename = NULL; > > if (virAsprintf(, "%s.libvirt-%s", > -name, drivername) < 0) > +name, drivername) < 0 || > +(machinename && > + virAsprintf(, "%s.libvirt-%s", > + machinename, drivername) < 0)) > goto cleanup; > > -if (virCgroupPartitionEscape() < 0) > +if (virCgroupPartitionEscape() < 0 || > +(machinename && virCgroupPartitionEscape() < 0)) > goto cleanup; Instead of those composite conditions I would rather make something like this: if (machinename) { create partmachinename; run virCgroupPartitionEscape(); } It's the same but for me more readable and cleaner code. ACK with or without the change. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list