Re: [libvirt] [Xen-devel] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.
On 12/14/2015 04:37 AM, Ian Campbell wrote: > On Mon, 2015-12-14 at 11:15 +, Daniel P. Berrange wrote: >> On Thu, Dec 10, 2015 at 11:38:36AM +, Ian Campbell wrote: >>> Upstream Xen is in the process of splitting the (stable API) xtl_* >>> interfaces out from the (unstable API) libxenctrl library and into a >>> new (stable API) libxentoollog. >>> >>> In order to be compatible with Xen both before and after this >>> transition check for xtl_createlogger_stdiostream in a libxentoollog >>> library and use it if present. If it is not present assume it is in >>> libxenctrl. >> Ok, so there's no API changes, just move stuf from one to the other. > Indeed, it should really have been a separate library all along and the API > already setup that way. > > I'm working on some other library splits, which will involve API changes, > but AFAIK they are all isolated from libvirt via the use of libxl, so there > should be no churn for you guys other than this one patch. > >>> It might be nice to get this into 1.3.0 so that supports Xen 4.7 out >>> of the box? Not sure what the libvirt stable backport policy is but it >>> might also be good to eventually consider it for that? >> We've missed 1.3.0 release, but I'd be ok with adding it to the >> stable branch if that's going to be useful. > I think it would, to allow things to build with Xen 4.7 (when it is > released). I'm not sure it is necessary. libvirt is released monthly, so there will be several releases before Xen 4.7 is released. > [...] > >> Looks, fine from me but will let Jim push it. I've pushed the patch to master, but not the 1.3.0 maint branch. It will be included in the 1.3.1 release planned for mid January. Ian, do you think that is sufficient? Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v8 2/5] virstoragefile: Add helper to set storage source backingStore
From: Matthias Gatto
Add a new helper - virStorageSourceSetBackingStore - to set the storage
source backingStore pointer in order to make it easier to change the
future format of the data.
A future patch will adjust the backingStore pointer to become a table or
array of backingStorePtr's accessible by the argument 'pos'.
For now, if 'pos' > 0, the code will return NULL as if the backingStore
pointer couldn't be set. All callers in subsequent patches will start by
passing a 0 as the parameter.
Signed-off-by: Matthias Gatto
Signed-off-by: John Ferlan
---
src/libvirt_private.syms | 1 +
src/util/virstoragefile.c | 26 ++
src/util/virstoragefile.h | 4
3 files changed, 31 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 1c55370..509fbae 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2206,6 +2206,7 @@ virStorageSourceParseRBDColonString;
virStorageSourcePoolDefFree;
virStorageSourcePoolModeTypeFromString;
virStorageSourcePoolModeTypeToString;
+virStorageSourceSetBackingStore;
virStorageSourceUpdateBlockPhysicalSize;
virStorageTypeFromString;
virStorageTypeToString;
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 2771c95..43a7137 100644
--- a/src/util/virstoragefile.c
+++ b/src/util/virstoragefile.c
@@ -1833,6 +1833,32 @@ virStorageSourceGetBackingStore(const virStorageSource
*src,
/**
+ * virStorageSourceSetBackingStore:
+ * @src: virStorageSourcePtr to hold @backingStore
+ * @backingStore - Pointer to the backingStore to store
+ * @pos - presently unused
+ *
+ * Set @backingStore in @src at @pos in src->backingStore. For now, pos
+ * is expected to be 0. A future patch will use pos as the position in
+ * the array of storage backingStore pointers
+ *
+ * Returns:
+ * 0 on success, -1 on failure
+ */
+int
+virStorageSourceSetBackingStore(virStorageSourcePtr src,
+virStorageSourcePtr backingStore,
+size_t pos)
+{
+if (pos > 0)
+return -1;
+
+src->backingStore = backingStore;
+return 0;
+}
+
+
+/**
* virStorageSourcePtr:
*
* Deep-copies a virStorageSource structure. If @backing chain is true
diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h
index 8cd4854..ce1cb5d 100644
--- a/src/util/virstoragefile.h
+++ b/src/util/virstoragefile.h
@@ -289,6 +289,10 @@ struct _virStorageSource {
# define DEV_BSIZE 512
# endif
+int virStorageSourceSetBackingStore(virStorageSourcePtr src,
+virStorageSourcePtr backingStore,
+size_t pos);
+
virStorageSourcePtr virStorageSourceGetBackingStore(const virStorageSource
*src,
size_t pos);
--
2.5.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v8 5/5] virstoragefile: Convert storage source backingStore into backingStores
From: Matthias Gatto
Convert the storage source backingStore pointer into an array of
virStorageSourcePtr.
This patch will rename src->backingStore to src->backingStores, add an
nbackingStores, and adjust the code Get and Set functions to handle the
the array.
virStorageSourceSetBackingStore can expand the size of src->backingStores.
Signed-off-by: Matthias Gatto
Signed-off-by: John Ferlan
---
src/util/virstoragefile.c | 61 ++-
src/util/virstoragefile.h | 3 ++-
2 files changed, 41 insertions(+), 23 deletions(-)
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 1d96d7a..b917eb6 100644
--- a/src/util/virstoragefile.c
+++ b/src/util/virstoragefile.c
@@ -1813,11 +1813,10 @@ virStorageSourcePoolDefCopy(const
virStorageSourcePoolDef *src)
/**
* virStorageSourceGetBackingStore:
* @src: virStorageSourcePtr containing the backing stores
- * @pos: presently unused
+ * @pos: position of the backing store to get
*
- * Return the @src backingStore pointer at @pos. For now, @pos is
- * expected to be 0. A future patch will use @pos index into an array
- * of storage backingStore pointers
+ * Return the @src backingStore pointer at @pos in the array of
+ * storage backingStores pointers
*
* Returns:
* A pointer to the storage source backingStore @pos or
@@ -1827,9 +1826,9 @@ virStorageSourcePtr
virStorageSourceGetBackingStore(const virStorageSource *src,
size_t pos)
{
-if (!src || pos > 0)
+if (!src || !src->backingStores || pos >= src->nBackingStores)
return NULL;
-return src->backingStore;
+return src->backingStores[pos];
}
@@ -1837,11 +1836,12 @@ virStorageSourceGetBackingStore(const virStorageSource
*src,
* virStorageSourceSetBackingStore:
* @src: virStorageSourcePtr to hold @backingStore
* @backingStore - Pointer to the backingStore to store
- * @pos - presently unused
+ * @pos: position of the backing store to store
*
- * Set @backingStore in @src at @pos in src->backingStore. For now, pos
- * is expected to be 0. A future patch will use pos as the position in
- * the array of storage backingStore pointers
+ * Set @backingStore in @src at @pos in src->backingStores. If the
+ * backingStores array does not have the space to contain @backingStore,
+ * expand src->backingStores. If the entry at @pos already exists, then
+ * free it first before replacing with the new @backingStore.
*
* Returns:
* 0 on success, -1 on failure
@@ -1851,10 +1851,18 @@ virStorageSourceSetBackingStore(virStorageSourcePtr src,
virStorageSourcePtr backingStore,
size_t pos)
{
-if (pos > 0)
+if (!src)
return -1;
-src->backingStore = backingStore;
+if (pos >= src->nBackingStores) {
+int nbr = pos - src->nBackingStores + 1;
+if (VIR_EXPAND_N(src->backingStores, src->nBackingStores, nbr) < 0)
+return -1;
+}
+
+if (src->backingStores[pos])
+virStorageSourceFree(src->backingStores[pos]);
+src->backingStores[pos] = backingStore;
return 0;
}
@@ -1873,6 +1881,7 @@ virStorageSourceCopy(const virStorageSource *src,
bool backingChain)
{
virStorageSourcePtr ret = NULL;
+size_t i;
if (VIR_ALLOC(ret) < 0)
return NULL;
@@ -1885,6 +1894,7 @@ virStorageSourceCopy(const virStorageSource *src,
ret->physical = src->physical;
ret->readonly = src->readonly;
ret->shared = src->shared;
+ret->nBackingStores = src->nBackingStores;
/* storage driver metadata are not copied */
ret->drv = NULL;
@@ -1933,15 +1943,17 @@ virStorageSourceCopy(const virStorageSource *src,
!(ret->auth = virStorageAuthDefCopy(src->auth)))
goto error;
-if (backingChain) {
-virStorageSourcePtr backingStore =
-virStorageSourceGetBackingStore(src, 0);
-virStorageSourcePtr backingStoreCopy =
-virStorageSourceCopy(backingStore, true);
+for (i = 0; i < src->nBackingStores; i++) {
+if (backingChain) {
+virStorageSourcePtr backingStore =
+virStorageSourceGetBackingStore(src, i);
+virStorageSourcePtr backingStoreCopy =
+virStorageSourceCopy(backingStore, true);
-if (!backingStoreCopy ||
-virStorageSourceSetBackingStore(ret, backingStoreCopy, 0) < 0)
-goto error;
+if (!backingStoreCopy ||
+virStorageSourceSetBackingStore(ret, backingStoreCopy, i) < 0)
+goto error;
+}
}
return ret;
@@ -2073,6 +2085,8 @@ virStorageSourceIsEmpty(virStorageSourcePtr src)
void
virStorageSourceBackingStoreClear(virStorageSourcePtr def)
{
+size_t i;
+
if (!def)
return;
@@ -2080,8 +2094,11 @@ virStorageSourceBackingStoreClear(virStorageSourcePtr
def)
VIR_FREE(def->backingStoreRaw);
[libvirt] [PATCH v8 0/5] Partial posting of updates to Add quorum to libvirt
I took a few cycles to reformat the initial 5 patches of the add quorum support posted as a v7 here: http://www.redhat.com/archives/libvir-list/2015-December/msg00119.html These patches are easily separable from the rest of the series. Rather than see things linger for months on end, trying to make small leaps. Changes in the series are to reorder things slightly, follow some of the review comments from previous series, and a few other things along the way. I've looked at this way too long to - hopefully I haven't missed anything. Most I forget... One I do remember is the virStorageSourceCopy changes in patch 5 where I believe the "Get" and "Set" wanted to use the 'i' index rather than having the "Get" use the 'i' and the "Set" always use '0'. Matthias Gatto (5): virstoragefile: Add helper to get storage source backingStore virstoragefile: Add helper to set storage source backingStore virstoragefile: Use helper to get storage source backing store virstoragefile: Use helper to set storage source backing store virstoragefile: Convert storage source backingStore into backingStores src/conf/domain_conf.c| 25 + src/conf/storage_conf.c | 29 ++- src/libvirt_private.syms | 2 + src/qemu/qemu_cgroup.c| 6 ++- src/qemu/qemu_domain.c| 2 +- src/qemu/qemu_driver.c| 35 - src/qemu/qemu_monitor_json.c | 4 +- src/security/security_dac.c | 3 +- src/security/security_selinux.c | 5 +- src/security/virt-aa-helper.c | 2 +- src/storage/storage_backend.c | 34 +++- src/storage/storage_backend_fs.c | 46 +--- src/storage/storage_backend_gluster.c | 11 ++-- src/storage/storage_backend_logical.c | 15 -- src/storage/storage_driver.c | 3 +- src/util/virstoragefile.c | 98 ++- src/util/virstoragefile.h | 10 +++- tests/virstoragetest.c| 18 +++ 18 files changed, 243 insertions(+), 105 deletions(-) -- 2.5.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v8 1/5] virstoragefile: Add helper to get storage source backingStore
From: Matthias Gatto
Add a new helper - virStorageSourceGetBackingStore - to fetch the storage
source backingStore pointer in order to make it easier to change the
future format of the data.
A future patch will adjust the backingStore pointer to become a table or
array of backingStorePtr's accessible by the argument 'pos'.
For now, if 'pos' > 0, the code will return NULL as if the backingStore
pointer didn't exist. All callers in subsequent patches will start by
passing a 0 as the parameter.
Signed-off-by: Matthias Gatto
Signed-off-by: John Ferlan
---
src/libvirt_private.syms | 1 +
src/util/virstoragefile.c | 23 +++
src/util/virstoragefile.h | 3 +++
3 files changed, 27 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 55822ae..1c55370 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -2196,6 +2196,7 @@ virStorageSourceClear;
virStorageSourceCopy;
virStorageSourceFree;
virStorageSourceGetActualType;
+virStorageSourceGetBackingStore;
virStorageSourceGetSecurityLabelDef;
virStorageSourceInitChainElement;
virStorageSourceIsEmpty;
diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
index 2aa1d90..2771c95 100644
--- a/src/util/virstoragefile.c
+++ b/src/util/virstoragefile.c
@@ -1810,6 +1810,29 @@ virStorageSourcePoolDefCopy(const
virStorageSourcePoolDef *src)
/**
+ * virStorageSourceGetBackingStore:
+ * @src: virStorageSourcePtr containing the backing stores
+ * @pos: presently unused
+ *
+ * Return the @src backingStore pointer at @pos. For now, @pos is
+ * expected to be 0. A future patch will use @pos index into an array
+ * of storage backingStore pointers
+ *
+ * Returns:
+ * A pointer to the storage source backingStore @pos or
+ * NULL if the backingStore pointer cannot be found
+ */
+virStorageSourcePtr
+virStorageSourceGetBackingStore(const virStorageSource *src,
+size_t pos)
+{
+if (!src || pos > 0)
+return NULL;
+return src->backingStore;
+}
+
+
+/**
* virStorageSourcePtr:
*
* Deep-copies a virStorageSource structure. If @backing chain is true
diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h
index b98fe25..8cd4854 100644
--- a/src/util/virstoragefile.h
+++ b/src/util/virstoragefile.h
@@ -289,6 +289,9 @@ struct _virStorageSource {
# define DEV_BSIZE 512
# endif
+virStorageSourcePtr virStorageSourceGetBackingStore(const virStorageSource
*src,
+size_t pos);
+
int virStorageFileProbeFormat(const char *path, uid_t uid, gid_t gid);
int virStorageFileProbeFormatFromBuf(const char *path,
char *buf,
--
2.5.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v8 4/5] virstoragefile: Use helper to set storage source backing store
From: Matthias Gatto
Convert all ->backingStore stores into a virStorageSourceSetBackingStore
call using 0 as the pos in order to store.
Signed-off-by: Matthias Gatto
Signed-off-by: John Ferlan
---
src/conf/domain_conf.c| 3 ++-
src/conf/storage_conf.c | 17 ++---
src/qemu/qemu_driver.c| 15 +++
src/storage/storage_backend_fs.c | 9 ++---
src/storage/storage_backend_gluster.c | 5 +++--
src/storage/storage_backend_logical.c | 15 +++
src/storage/storage_driver.c | 3 ++-
src/util/virstoragefile.c | 8 ++--
tests/virstoragetest.c| 4 ++--
9 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index d60feeb..2341ee2 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6465,7 +6465,8 @@ virDomainDiskBackingStoreParse(xmlXPathContextPtr ctxt,
virDomainDiskBackingStoreParse(ctxt, backingStore) < 0)
goto cleanup;
-src->backingStore = backingStore;
+if (virStorageSourceSetBackingStore(src, backingStore, 0) < 0)
+goto cleanup;
ret = 0;
cleanup:
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index fb2ace5..564af8a 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -1259,6 +1259,7 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
char *capacity = NULL;
char *unit = NULL;
char *backingStore = NULL;
+virStorageSourcePtr backingStorePtr;
xmlNodePtr node;
xmlNodePtr *nodes = NULL;
size_t i;
@@ -1295,20 +1296,22 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
}
if ((backingStore = virXPathString("string(./backingStore/path)", ctxt))) {
-if (VIR_ALLOC(ret->target.backingStore) < 0)
+if (VIR_ALLOC(backingStorePtr) < 0)
goto error;
-ret->target.backingStore->path = backingStore;
+if (virStorageSourceSetBackingStore(&ret->target, backingStorePtr, 0)
< 0)
+goto error;
+backingStorePtr->path = backingStore;
backingStore = NULL;
if (options->formatFromString) {
char *format =
virXPathString("string(./backingStore/format/@type)", ctxt);
if (format == NULL)
-ret->target.backingStore->format = options->defaultFormat;
+backingStorePtr->format = options->defaultFormat;
else
-ret->target.backingStore->format =
(options->formatFromString)(format);
+backingStorePtr->format = (options->formatFromString)(format);
-if (ret->target.backingStore->format < 0) {
+if (backingStorePtr->format < 0) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
_("unknown volume format type %s"), format);
VIR_FREE(format);
@@ -1317,9 +1320,9 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
VIR_FREE(format);
}
-if (VIR_ALLOC(ret->target.backingStore->perms) < 0)
+if (VIR_ALLOC(backingStorePtr->perms) < 0)
goto error;
-if (virStorageDefParsePerms(ctxt, ret->target.backingStore->perms,
+if (virStorageDefParsePerms(ctxt, backingStorePtr->perms,
"./backingStore/permissions") < 0)
goto error;
}
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index a129f22..e023b85 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -14283,12 +14283,19 @@
qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
/* Update vm in place to match changes. */
need_unlink = false;
-newDiskSrc->backingStore = disk->src;
+if (virStorageSourceSetBackingStore(newDiskSrc, disk->src, 0) < 0) {
+ret = -1;
+goto cleanup;
+}
disk->src = newDiskSrc;
newDiskSrc = NULL;
if (persistDisk) {
-persistDiskSrc->backingStore = persistDisk->src;
+if (virStorageSourceSetBackingStore(persistDiskSrc,
+persistDisk->src, 0) < 0) {
+ret = -1;
+goto cleanup;
+}
persistDisk->src = persistDiskSrc;
persistDiskSrc = NULL;
}
@@ -14332,13 +14339,13 @@
qemuDomainSnapshotUndoSingleDiskActive(virQEMUDriverPtr driver,
/* Update vm in place to match changes. */
tmp = disk->src;
disk->src = virStorageSourceGetBackingStore(tmp, 0);
-tmp->backingStore = NULL;
+ignore_value(virStorageSourceSetBackingStore(tmp, NULL, 0));
virStorageSourceFree(tmp);
if (persistDisk) {
tmp = persistDisk->src;
persistDisk->src = virStorageSourceGetBackingStore(tmp, 0);
-tmp->backingStore = NULL;
+ignore_value(virStorageSourceSetBackingStore(tmp, NULL, 0));
virStorageSourceFree(tmp);
}
}
diff --git a/src/stora
[libvirt] [PATCH v8 3/5] virstoragefile: Use helper to get storage source backing store
From: Matthias Gatto
Convert all ->backingStore fetches into a virStorageSourceGetBackingStore
call using 0 as the pos in order to fetch.
Signed-off-by: Matthias Gatto
Signed-off-by: John Ferlan
---
src/conf/domain_conf.c| 22 ---
src/conf/storage_conf.c | 12 +-
src/qemu/qemu_cgroup.c| 6 +++--
src/qemu/qemu_domain.c| 2 +-
src/qemu/qemu_driver.c| 20 +
src/qemu/qemu_monitor_json.c | 4 +++-
src/security/security_dac.c | 3 ++-
src/security/security_selinux.c | 5 +++--
src/security/virt-aa-helper.c | 2 +-
src/storage/storage_backend.c | 34 +++--
src/storage/storage_backend_fs.c | 41 ---
src/storage/storage_backend_gluster.c | 8 ---
src/storage/storage_backend_logical.c | 18 ++-
src/util/virstoragefile.c | 24 ++--
tests/virstoragetest.c| 14 ++--
15 files changed, 129 insertions(+), 86 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 5200c27..d60feeb 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18730,6 +18730,7 @@ virDomainDiskBackingStoreFormat(virBufferPtr buf,
{
const char *type;
const char *format;
+virStorageSourcePtr backingStorePtr;
if (!backingStore) {
if (!backingStoreRaw)
@@ -18759,9 +18760,11 @@ virDomainDiskBackingStoreFormat(virBufferPtr buf,
virBufferAsprintf(buf, "\n", format);
/* We currently don't output seclabels for backing chain element */
-if (virDomainDiskSourceFormatInternal(buf, backingStore, 0, 0, true) < 0 ||
-virDomainDiskBackingStoreFormat(buf,
-backingStore->backingStore,
+if (virDomainDiskSourceFormatInternal(buf, backingStore, 0, 0, true) < 0)
+return -1;
+
+backingStorePtr = virStorageSourceGetBackingStore(backingStore, 0);
+if (virDomainDiskBackingStoreFormat(buf, backingStorePtr,
backingStore->backingStoreRaw,
idx + 1) < 0)
return -1;
@@ -18881,10 +18884,13 @@ virDomainDiskDefFormat(virBufferPtr buf,
/* Don't format backingStore to inactive XMLs until the code for
* persistent storage of backing chains is ready. */
-if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE) &&
-virDomainDiskBackingStoreFormat(buf, def->src->backingStore,
-def->src->backingStoreRaw, 1) < 0)
-return -1;
+if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) {
+virStorageSourcePtr backingStore =
+virStorageSourceGetBackingStore(def->src, 0);
+if (virDomainDiskBackingStoreFormat(buf, backingStore,
+def->src->backingStoreRaw, 1) < 0)
+return -1;
+}
virBufferEscapeString(buf, "\n",
def->domain_name);
@@ -22850,7 +22856,7 @@ virDomainDiskDefForeachPath(virDomainDiskDefPtr disk,
}
}
-for (tmp = disk->src; tmp; tmp = tmp->backingStore) {
+for (tmp = disk->src; tmp; tmp = virStorageSourceGetBackingStore(tmp, 0)) {
int actualType = virStorageSourceGetActualType(tmp);
/* execute the callback only for local storage */
if (actualType != VIR_STORAGE_TYPE_NETWORK &&
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index 9b8abea..fb2ace5 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -1330,7 +1330,8 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
if (virStorageSize(unit, capacity, &ret->target.capacity) < 0)
goto error;
} else if (!(flags & VIR_VOL_XML_PARSE_NO_CAPACITY) &&
- !((flags & VIR_VOL_XML_PARSE_OPT_CAPACITY) &&
ret->target.backingStore)) {
+ !((flags & VIR_VOL_XML_PARSE_OPT_CAPACITY) &&
+ virStorageSourceGetBackingStore(&ret->target, 0))) {
virReportError(VIR_ERR_XML_ERROR, "%s", _("missing capacity element"));
goto error;
}
@@ -1593,6 +1594,7 @@ virStorageVolDefFormat(virStoragePoolDefPtr pool,
virStorageVolDefPtr def)
{
virStorageVolOptionsPtr options;
+virStorageSourcePtr backingStore;
virBuffer buf = VIR_BUFFER_INITIALIZER;
options = virStorageVolOptionsForPoolType(pool->type);
@@ -1644,10 +1646,10 @@ virStorageVolDefFormat(virStoragePoolDefPtr pool,
&def->target, "target") < 0)
goto cleanup;
-if (def->target.backingStore &&
-virStorageVolTargetDefFormat(options, &buf,
- def->target.backingStore,
- "backingStore") < 0)
+backingStore = virStorageSourceGetBackingStore(&def->target, 0);
+if (backingStore && virStor
Re: [libvirt] [PATCH v3 8/8] libxl: implement virDomainGetJobStats
On 12/03/2015 12:29 PM, Joao Martins wrote: > > On 12/03/2015 06:48 PM, Jim Fehlig wrote: >> Joao Martins wrote: >>> Introduces support for domainGetJobStats which has the same >>> info as domainGetJobInfo but in a slightly different format. >>> Another difference is that virDomainGetJobStats can also >>> retrieve info on the most recently completed job. Though so >>> far this is only used in the source node to know if the >>> migration has been completed. But because we don't support >>> completed jobs we will deliver an error. >> This patch, and 7/8, look good - ACK. Nice to see all the >> >> error : virDomainGetJobInfo:8844 : this function is not supported by the >> connection driver: virDomainGetJobInfo >> >> log entries disappear when doing save, migrate, etc :-). But I'll wait until >> the >> freeze is lifted to push them. > Great! And it's also nice to see migration no longer crashing on Openstack, > since the monitoring of it relies on these API calls. I've pushed 7 and 8 now that the release is out. Thanks! Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] vf configuration cleanup when VM is delete
On 12/15/2015 04:12 PM, Vlad Yasevich wrote: On 12/15/2015 02:45 PM, Laine Stump wrote: On 12/15/2015 01:34 PM, Laine Stump wrote: On 12/13/2015 10:51 AM, Moshe Levi wrote: Hi, I have a setup with libvirt 1.3.0 and OpenStack trunk. Before launched the VM ip link command show the following VF mac/vlan configuration [1] When I launch a VM with via openstack api (OpenStack direct port) I can see that the VF get the mac/vlan according to libvrit xml [2] and ip link command [3], but when I delete the VM the mac/vlan config are still shown as in [3] and not restored to [1] Shouldn’t libvirt restore the mac/vlan to [1]. The same problem exists when using (OpenStack macvtap port) but just for the MAC configuration of the VF. What libvirt does is to restore the MAC address to whatever it was before we set it up for use with a guest. Although there are some sriov net drivers that (for some unfathomable reason) think it's cool to assign a random MAC address to each VF at boot time, the "normal" thing is for the VFs to have a MAC address of all 0's to start with. So libvirt should be saving 00:00:00:00:00:00 (it will be in the file /var/run/libvirt/hostdevmgr/$ifname_vf$vfnum) then setting the MAC to use; when done, libvirt will read the 00:00:00:00:00:00 and use netlink to set the MAC address, but this is apparently failing. I checked on my Fedora 22 system with the igb driver, and found that if the MAC address was originally set to something other than 0's, it was restored properly by libvirt, but if it was set to all 0's originally, the attempt to set it back to 0 would fail. I then tried doing the same thing with the "ip" utility: # ip link set dev p4p2 vf 0 mac 00:00:00:00:00:00 and I get the following response: RTNETLINK answers: Invalid argument So it appears that either the kernel or the NIC driver is refusing to set the MAC address to all 0's. I'm reasonably certain this is a regression in the kernel, Sigh. It appears that this has "always" been the case - I just checked on a 2.6.32-573 RHEL kernel, and a 3.10.x RHEL7.2 kernel, and 4.1 (Fedora 22) and both of them also refuse to set the MAC address to 00:00:00:00:00:00. I'm not sure if this limitation is in the NIC driver or some basic code in the kernel. It's considered to be an invalid address by is_valid_ether_addr() function. There appear to be different behaviour in some adapters. In current upstream, it looks like a quarter of the VF capable drivers (bnxt, enic, fm10k, sfc) permit VF mac setting of all zeros. The others simply use is_valid_ether_addr function without specifically testing for all-0. I am not sure if this is HW related or simply oversights... Might want to bringing this up on netdev. Thanks, Vlad! Moshe, It sounds like in your case it is caused by code in the mlx driver, so hopefully you can have some influence there. My path is a bit more difficult, as the failure on mine is in the igb driver :-) Sending a message to netdev is a good idea. It would be wonderful if all the vendors could agree to: 1) initialize all VFs with a MAC address of 0 2) allow setting VF MAC address to 0 at any time. I'll put that on my to-do list :-P -vlad although I can't say how long it's been there, as I don't normally pay attention to this (and as I said, many SRIOV NIC drivers don't default their VFs to 0 MAC addresses) What distro and kernel are you using for your tests? [1] - 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto [2] - [3] 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC fa:16:3e:11:af:fe, vlan 190, spoof checking off, link-state enable -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list F15 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH V2] Xen: support maxvcpus in xm and xl config
From: Ian Campbell
xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
as a bit map of which cpus are online (default is all).
xend from 4.0 onwards understands maxvcpus as maxvcpus and
vcpus as the number which are online (from 0..N-1). The
upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
claims that if maxvcpus is omitted then the old behaviour
(i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
in this case vcpu==maxcpus==online cpus. This is good for us
because handling anything else would be fiddly.
This patch changes parsing of the virDomainDef maxvcpus and vcpus
entries to use the corresponding 'maxvcpus' and 'vcpus' settings
from xm and xl config. It also drops use of the old Xen 3.x
'vcpu_avail' setting.
The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
maxvcpus is simply a count, not a bit mask), which is particularly
crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
expected to support vcpu placement, and therefore only the boot
vcpu's info lives in the shared info page).
Existing tests adjusted accordingly, and new tests added for the
'maxvcpus' setting.
Signed-off-by: Jim Fehlig
---
This is a respin of Ian's patch [1] to support parsing/formatting of the
'maxvcpus' xm and xl config setting. It goes a bit further and removes
the old Xen 3.x 'vcpu_avail' setting and lifts the maxvcpus limit of
MAX_VIRT_CPUS entirely.
The patch is based on my recent series [2] removing xend config version from
the codebase.
[1] https://www.redhat.com/archives/libvir-list/2015-November/msg01155.html
[2] https://www.redhat.com/archives/libvir-list/2015-December/msg00616.html
src/xenconfig/xen_common.c| 25 +++--
tests/xlconfigdata/test-paravirt-maxvcpus.cfg | 13 +++
tests/xlconfigdata/test-paravirt-maxvcpus.xml | 28
tests/xlconfigtest.c | 1 +
tests/xmconfigdata/test-paravirt-maxvcpus.cfg | 13 +++
tests/xmconfigdata/test-paravirt-maxvcpus.xml | 31 +++
tests/xmconfigdata/test-paravirt-vcpu.cfg | 4 ++--
tests/xmconfigtest.c | 1 +
8 files changed, 101 insertions(+), 15 deletions(-)
diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index f3e7e18..54f5791 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -488,19 +488,22 @@ xenParseCPUFeatures(virConfPtr conf, virDomainDefPtr def)
const char *str = NULL;
int val = 0;
-if (xenConfigGetULong(conf, "vcpus", &count, 1) < 0 ||
-MAX_VIRT_CPUS < count)
+if (xenConfigGetULong(conf, "vcpus", &count, 1) < 0)
return -1;
if (virDomainDefSetVcpusMax(def, count) < 0)
return -1;
-if (xenConfigGetULong(conf, "vcpu_avail", &count, -1) < 0)
+if (virDomainDefSetVcpus(def, count) < 0)
return -1;
-if (virDomainDefSetVcpus(def, MIN(count_one_bits_l(count),
- virDomainDefGetVcpusMax(def))) < 0)
-return -1;
+if (virConfGetValue(conf, "maxvcpus")) {
+if (xenConfigGetULong(conf, "maxvcpus", &count, 0) < 0)
+return -1;
+
+if (virDomainDefSetVcpusMax(def, count) < 0)
+return -1;
+}
if (xenConfigGetString(conf, "cpus", &str, NULL) < 0)
return -1;
@@ -1494,14 +1497,10 @@ xenFormatCPUAllocation(virConfPtr conf, virDomainDefPtr
def)
int ret = -1;
char *cpus = NULL;
-if (xenConfigSetInt(conf, "vcpus", virDomainDefGetVcpusMax(def)) < 0)
+if (virDomainDefGetVcpus(def) < virDomainDefGetVcpusMax(def) &&
+xenConfigSetInt(conf, "maxvcpus", virDomainDefGetVcpusMax(def)) < 0)
goto cleanup;
-
-/* Computing the vcpu_avail bitmask works because MAX_VIRT_CPUS is
- either 32, or 64 on a platform where long is big enough. */
-if (virDomainDefHasVcpusOffline(def) &&
-xenConfigSetInt(conf, "vcpu_avail",
-(1UL << virDomainDefGetVcpus(def)) - 1) < 0)
+if (xenConfigSetInt(conf, "vcpus", virDomainDefGetVcpus(def)) < 0)
goto cleanup;
if ((def->cpumask != NULL) &&
diff --git a/tests/xlconfigdata/test-paravirt-maxvcpus.cfg
b/tests/xlconfigdata/test-paravirt-maxvcpus.cfg
new file mode 100644
index 000..d506b75
--- /dev/null
+++ b/tests/xlconfigdata/test-paravirt-maxvcpus.cfg
@@ -0,0 +1,13 @@
+name = "XenGuest1"
+uuid = "45b60f51-88a9-47a8-a3b3-5e66d71b2283"
+maxmem = 512
+memory = 512
+maxvcpus = 8
+vcpus = 4
+localtime = 0
+on_poweroff = "preserve"
+on_reboot = "restart"
+on_crash = "preserve"
+vif = [ "mac=5a:36:0e:be:00:09" ]
+bootloader = "/usr/bin/pygrub"
+disk = [
"/var/lib/xen/images/debian/disk.qcow2,qcow2,xvda,w,backendtype=qdisk" ]
diff --git a/tests/xlconfigdata/test-paravirt-maxvcpus.xml
b/tests/xlconfigdata/test-paravirt-maxvcpus.xml
new file mode 100644
index 000..2e1f8f8
--- /dev/null
+++ b/tests/xlconfigdata/test-paravirt-maxvcpus.xml
[libvirt] [PATCH 11/16] Xen: tests: use latest XEND_CONFIG_VERSION in xml2sexpr tests
Change all xml2sexpr tests to use the latest XEND_CONFIG_VERSION (XEND_CONFIG_VERSION_3_1_0 = 4). Fix tests that do not conform to the latest version. Signed-off-by: Jim Fehlig --- tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-curmem.sexpr | 2 +- .../xml2sexpr-disk-block-shareable.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-block.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blkback.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap-qcow.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap-raw.sexpr| 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blktap.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap2-raw.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blktap2.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-drv-loop.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-file.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-escape.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr | 8 +- .../xml2sexprdata/xml2sexpr-fv-force-nohpet.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-kernel.sexpr | 5 +- tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr | 8 +- .../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 5 +- .../xml2sexprdata/xml2sexpr-fv-parallel-tcp.sexpr | 8 +- .../xml2sexpr-fv-serial-dev-2-ports.sexpr | 11 +- .../xml2sexpr-fv-serial-dev-2nd-port.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-serial-file.sexpr | 11 +- tests/xml2sexprdata/xml2sexpr-fv-serial-null.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pipe.sexpr | 11 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pty.sexpr | 8 +- .../xml2sexprdata/xml2sexpr-fv-serial-stdio.sexpr | 8 +- .../xml2sexpr-fv-serial-tcp-telnet.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-serial-tcp.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-serial-udp.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-serial-unix.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-sound.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-usbmouse.sexpr| 8 +- tests/xml2sexprdata/xml2sexpr-fv-utc.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-fv-v2.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-fv-vncunused.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-fv.sexpr | 8 +- tests/xml2sexprdata/xml2sexpr-net-bridged.sexpr| 3 +- tests/xml2sexprdata/xml2sexpr-net-e1000.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-net-routed.sexpr | 3 +- .../xml2sexprdata/xml2sexpr-no-source-cdrom.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-pci-devs.sexpr | 2 +- .../xml2sexpr-pv-bootloader-cmdline.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-pv-bootloader.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-pv-localtime.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-pv-vcpus.sexpr | 3 +- .../xml2sexprdata/xml2sexpr-pv-vfb-new-auto.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-pv-vfb-new.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-pv.sexpr | 3 +- tests/xml2sexprtest.c | 113 ++--- 50 files changed, 208 insertions(+), 157 deletions(-) diff --git a/tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr b/tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr index 4850bc0..923d282 100644 --- a/tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr +++ b/tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr @@ -1,6 +1,6 @@ (vm (name 'pvtest')(memory 420)(maxmem 420)(vcpus 2)\ (uuid '596a5d21-71f4-8fb2-e068-e2386a5c413e')(on_poweroff 'destroy')\ (on_reboot 'destroy')(on_crash 'destroy')(image (linux \ -(kernel '/usr/lib/xen/boot/pv-grub-x86_64.gz')(args '(hd0,0)/grub/menu.lst')))\ -(localtime 0)\ +(kernel '/usr/lib/xen/boot/pv-grub-x86_64.gz')(args '(hd0,0)/grub/menu.lst')\ +(localtime 0)))(localtime 0)\ (device (vbd (dev 'xvda')(uname 'phy:/dev/MainVG/GuestLV')(mode 'w'\ diff --git a/tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr b/tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr index 47c4a3e..6830507 100644 --- a/tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr +++ b/tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr @@ -4,7 +4,7 @@ (kernel '/var/lib/xen/vmlinuz.2Dn2YT')\ (ramdisk '/var/lib/xen/initrd.img.0u-Vhq')\ (args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/\ -core/test/5.91/x86_64/os ')))\ +core/test/5.91/x86_64/os ')(localtime 0)))\ (localtime 0)\ (device (vbd (dev 'xvda')\ (uname 'file:/root/some.img')(mode 'w')))\ diff --git a/tests/xml2sexprdata/xml2sexpr-curmem.sexpr b/tests/xml2sexprdata/xml2sexpr-curmem.sexpr index 89d48b2..4b9fbb3 100644 --- a/tests/xml2sexprdata/xml2sexpr-curmem.sexpr +++ b/tests/xml2sexprdata/xml2sexpr-curmem.sexpr @@ -1,7 +1,7 @@ (vm (name 'rhel5')(memory 175)(maxmem 385)(vcpus 1)\ (uuid '4f77abd2-3019-58e8-3bab-6fbf2118f880')(bootloader '/usr/bi
[libvirt] [PATCH 15/16] Xen: xenconfig: remove xendConfigVersion from public sexpr functions
Remove use of xendConfigVersion in the s-expresion config formatter/parser
in src/xenconfig/. Adjust callers in the xen and libxl drivers accordingly.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_driver.c | 1 -
src/xen/xen_driver.c | 6 +++---
src/xen/xend_internal.c | 20 --
src/xen/xm_internal.c | 2 +-
src/xenconfig/xen_sxpr.c | 48 +++
src/xenconfig/xen_sxpr.h | 21 ++-
src/xenconfig/xenxs_private.h | 8
tests/sexpr2xmltest.c | 5 ++---
tests/xmconfigtest.c | 2 --
tests/xml2sexprtest.c | 2 +-
10 files changed, 33 insertions(+), 82 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index fd92fac..02ef4f5 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -2608,7 +2608,6 @@ libxlConnectDomainXMLFromNative(virConnectPtr conn,
} else if (STREQ(nativeFormat, LIBXL_CONFIG_FORMAT_SEXPR)) {
/* only support latest xend config format */
if (!(def = xenParseSxprString(nativeConfig,
- XEND_CONFIG_VERSION_3_1_0,
NULL,
-1,
cfg->caps,
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index 27da520..6f25625 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -1568,13 +1568,13 @@ xenUnifiedConnectDomainXMLFromNative(virConnectPtr conn,
def = xenParseXM(conf, priv->caps, priv->xmlopt);
} else if (STREQ(format, XEN_CONFIG_FORMAT_SEXPR)) {
-if (xenGetDomIdFromSxprString(config, priv->xendConfigVersion, &id) <
0)
+if (xenGetDomIdFromSxprString(config, &id) < 0)
goto cleanup;
xenUnifiedLock(priv);
tty = xenStoreDomainGetConsolePath(conn, id);
vncport = xenStoreDomainGetVNCPort(conn, id);
xenUnifiedUnlock(priv);
-def = xenParseSxprString(config, priv->xendConfigVersion, tty,
+def = xenParseSxprString(config, tty,
vncport, priv->caps, priv->xmlopt);
}
if (!def)
@@ -1632,7 +1632,7 @@ xenUnifiedConnectDomainXMLToNative(virConnectPtr conn,
goto cleanup;
}
} else if (STREQ(format, XEN_CONFIG_FORMAT_SEXPR)) {
-ret = xenFormatSxpr(conn, def, priv->xendConfigVersion);
+ret = xenFormatSxpr(conn, def);
}
cleanup:
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 72a1259..cd783a1 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -1569,7 +1569,7 @@ xenDaemonDomainFetch(virConnectPtr conn, int domid, const
char *name,
if (root == NULL)
return NULL;
-if (xenGetDomIdFromSxpr(root, priv->xendConfigVersion, &id) < 0)
+if (xenGetDomIdFromSxpr(root, &id) < 0)
goto cleanup;
xenUnifiedLock(priv);
if (sexpr_lookup(root, "domain/image/hvm"))
@@ -1579,7 +1579,6 @@ xenDaemonDomainFetch(virConnectPtr conn, int domid, const
char *name,
vncport = xenStoreDomainGetVNCPort(conn, id);
xenUnifiedUnlock(priv);
if (!(def = xenParseSxpr(root,
- priv->xendConfigVersion,
cpus,
tty,
vncport)))
@@ -2056,7 +2055,6 @@ xenDaemonCreateXML(virConnectPtr conn, virDomainDefPtr
def)
char *sexpr;
const char *tmp;
struct sexpr *root;
-xenUnifiedPrivatePtr priv = conn->privateData;
if (def->id != -1) {
virReportError(VIR_ERR_OPERATION_INVALID,
@@ -2065,7 +2063,7 @@ xenDaemonCreateXML(virConnectPtr conn, virDomainDefPtr
def)
return -1;
}
-if (!(sexpr = xenFormatSxpr(conn, def, priv->xendConfigVersion)))
+if (!(sexpr = xenFormatSxpr(conn, def)))
return -1;
ret = xenDaemonDomainCreateXML(conn, sexpr);
@@ -2167,7 +2165,7 @@ xenDaemonAttachDeviceFlags(virConnectPtr conn,
if (xenFormatSxprDisk(dev->data.disk,
&buf,
def->os.type == VIR_DOMAIN_OSTYPE_HVM ? 1 : 0,
- priv->xendConfigVersion, 1) < 0)
+ 1) < 0)
goto cleanup;
if (dev->data.disk->device != VIR_DOMAIN_DISK_DEVICE_CDROM &&
@@ -2180,7 +2178,7 @@ xenDaemonAttachDeviceFlags(virConnectPtr conn,
dev->data.net,
&buf,
def->os.type == VIR_DOMAIN_OSTYPE_HVM ? 1 : 0,
- priv->xendConfigVersion, 1) < 0)
+ 1) < 0)
goto cleanup;
char macStr[VIR_MAC_STRING_BUFLEN];
@@ -2303,7 +2301,7 @@ xenDaemonUpdateDeviceFlags(virConnectPtr conn,
if (xenFormatSxprDisk(dev->data.disk,
&buf,
[libvirt] [PATCH 09/16] Xen: tests: use latest XEND_CONFIG_VERSION in sexpr2xml tests
Change all sexpr2xml tests to use the latest XEND_CONFIG_VERSION (XEND_CONFIG_VERSION_3_1_0 = 4). Fix tests that do not conform to the latest version. Signed-off-by: Jim Fehlig --- tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml | 2 +- .../sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml| 4 +- .../sexpr2xmldata/sexpr2xml-fv-force-nohpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml| 2 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-parallel-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml | 4 +- .../sexpr2xml-fv-serial-dev-2-ports.sexpr | 5 +- .../sexpr2xml-fv-serial-dev-2-ports.xml| 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.sexpr | 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml| 4 +- .../sexpr2xmldata/sexpr2xml-fv-serial-stdio.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml | 4 +- .../sexpr2xml-fv-serial-tcp-telnet.sexpr | 3 +- .../sexpr2xml-fv-serial-tcp-telnet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml| 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml| 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.sexpr| 3 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-utc.sexpr | 2 + tests/sexpr2xmldata/sexpr2xml-fv-utc.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-v2.xml| 2 +- tests/sexpr2xmldata/sexpr2xml-fv.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml | 2 +- tests/sexpr2xmltest.c | 129 ++--- 51 files changed, 176 insertions(+), 139 deletions(-) diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml b/tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml index 17e723e..d68782d 100644 --- a/tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml +++ b/tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml @@ -12,7 +12,7 @@ - + destroy destroy destroy diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr b/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr index ded668c..777f7e0 100644 --- a/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr +++ b/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr @@ -3,7 +3,9 @@ (on_reboot 'restart')(on_crash 'restart')\ (image (hvm (loader /usr/lib/xen/boot/hvmloader)(kernel '')\ (device_model '/usr/lib64/xen/bin/qemu-dm')(boot d)(cdrom '/root/boot.iso')\ -(acpi 1)(vnc 1)(keymap ja)))(device (vbd (dev 'ioemu:hda')\ +(acpi 1)(vnc 1)(keymap ja)))(device (vbd (dev 'hda')\ (uname 'file:/root/foo.img')(mode 'w')))\ +(device (vbd (dev 'hdc:cdrom')\ +(uname 'file:/root/boot.iso')(mode 'r')))\ (device (vif (mac '00:16:3e:1b:b1:47')(bridge 'xenbr0')\ (script 'vif-bridge')(type ioemu diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml b/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml index 9494ec2..dbfd603 100644 --- a/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml +++ b/tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml @@ -12,7 +12,7 @@ - + destroy restart restart @@ -41,7 +41,7 @@ - + diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.sexpr b/tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.sexpr index d5221
[libvirt] [PATCH 08/16] Xen: xenconfig: remove xendConfigVersion from public functions
Remove use of xendConfigVersion in the xm and xl config formatter/parsers
in src/xenconfig/. Adjust callers in the xen and libxl drivers accordingly.
Signed-off-by: Jim Fehlig
---
src/libxl/libxl_driver.c | 8 +++-
src/xen/xen_driver.c | 5 ++---
src/xen/xm_internal.c | 7 +++
src/xenconfig/xen_common.c | 6 ++
src/xenconfig/xen_common.h | 7 +++
src/xenconfig/xen_xl.c | 9 -
src/xenconfig/xen_xl.h | 7 +++
src/xenconfig/xen_xm.c | 25 +
src/xenconfig/xen_xm.h | 5 ++---
tests/xlconfigtest.c | 4 ++--
tests/xmconfigtest.c | 5 ++---
11 files changed, 35 insertions(+), 53 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index a42647a..fd92fac 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -2595,15 +2595,13 @@ libxlConnectDomainXMLFromNative(virConnectPtr conn,
goto cleanup;
if (!(def = xenParseXL(conf,
cfg->caps,
- driver->xmlopt,
- cfg->verInfo->xen_version_major)))
+ driver->xmlopt)))
goto cleanup;
} else if (STREQ(nativeFormat, LIBXL_CONFIG_FORMAT_XM)) {
if (!(conf = virConfReadMem(nativeConfig, strlen(nativeConfig), 0)))
goto cleanup;
if (!(def = xenParseXM(conf,
- cfg->verInfo->xen_version_major,
cfg->caps,
driver->xmlopt)))
goto cleanup;
@@ -2659,10 +2657,10 @@ libxlConnectDomainXMLToNative(virConnectPtr conn, const
char * nativeFormat,
goto cleanup;
if (STREQ(nativeFormat, LIBXL_CONFIG_FORMAT_XL)) {
-if (!(conf = xenFormatXL(def, conn, cfg->verInfo->xen_version_major)))
+if (!(conf = xenFormatXL(def, conn)))
goto cleanup;
} else if (STREQ(nativeFormat, LIBXL_CONFIG_FORMAT_XM)) {
-if (!(conf = xenFormatXM(conn, def, cfg->verInfo->xen_version_major)))
+if (!(conf = xenFormatXM(conn, def)))
goto cleanup;
} else {
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index 285a553..321a250 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -1645,8 +1645,7 @@ xenUnifiedConnectDomainXMLFromNative(virConnectPtr conn,
if (!conf)
goto cleanup;
-def = xenParseXM(conf, priv->xendConfigVersion,
- priv->caps, priv->xmlopt);
+def = xenParseXM(conf, priv->caps, priv->xmlopt);
} else if (STREQ(format, XEN_CONFIG_FORMAT_SEXPR)) {
if (xenGetDomIdFromSxprString(config, priv->xendConfigVersion, &id) <
0)
goto cleanup;
@@ -1700,7 +1699,7 @@ xenUnifiedConnectDomainXMLToNative(virConnectPtr conn,
if (STREQ(format, XEN_CONFIG_FORMAT_XM)) {
int len = MAX_CONFIG_SIZE;
-conf = xenFormatXM(conn, def, priv->xendConfigVersion);
+conf = xenFormatXM(conn, def);
if (!conf)
goto cleanup;
diff --git a/src/xen/xm_internal.c b/src/xen/xm_internal.c
index ee78fe9..085b24a 100644
--- a/src/xen/xm_internal.c
+++ b/src/xen/xm_internal.c
@@ -139,7 +139,7 @@ xenXMConfigReadFile(virConnectPtr conn, const char
*filename)
if (!(conf = virConfReadFile(filename, 0)))
return NULL;
-def = xenParseXM(conf, priv->xendConfigVersion, priv->caps, priv->xmlopt);
+def = xenParseXM(conf, priv->caps, priv->xmlopt);
virConfFree(conf);
return def;
@@ -151,10 +151,9 @@ xenXMConfigSaveFile(virConnectPtr conn,
virDomainDefPtr def)
{
virConfPtr conf;
-xenUnifiedPrivatePtr priv = conn->privateData;
int ret;
-if (!(conf = xenFormatXM(conn, def, priv->xendConfigVersion)))
+if (!(conf = xenFormatXM(conn, def)))
return -1;
ret = virConfWriteFile(filename, conf);
@@ -972,7 +971,7 @@ xenXMDomainDefineXML(virConnectPtr conn, virDomainDefPtr
def)
return -1;
}
-if (!(conf = xenFormatXM(conn, def, priv->xendConfigVersion)))
+if (!(conf = xenFormatXM(conn, def)))
goto error;
/*
diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index 7932b3c..f3e7e18 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -1017,8 +1017,7 @@ xenParseGeneralMeta(virConfPtr conf, virDomainDefPtr def,
virCapsPtr caps)
int
xenParseConfigCommon(virConfPtr conf,
virDomainDefPtr def,
- virCapsPtr caps,
- int xendConfigVersion ATTRIBUTE_UNUSED)
+ virCapsPtr caps)
{
if (xenParseGeneralMeta(conf, def, caps) < 0)
return -1;
@@ -1761,8 +1760,7 @@ xenFormatVif(virConfPtr conf,
int
xenFormatConfigCommon(virConfPtr conf,
virDomainDefPtr def,
- virConnectPtr conn,
- int
[libvirt] [PATCH 16/16] Xen: remove xendConfigVersion from driver private struct
xendConfigVersion is no longer used, so remove it from the
xenUnifiedPrivate struct.
Signed-off-by: Jim Fehlig
---
src/xen/xen_driver.c| 1 -
src/xen/xen_driver.h| 2 --
src/xen/xend_internal.c | 37 -
3 files changed, 4 insertions(+), 36 deletions(-)
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index 6f25625..b40650f 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -487,7 +487,6 @@ xenUnifiedConnectOpen(virConnectPtr conn, virConnectAuthPtr
auth, unsigned int f
conn->privateData = priv;
priv->handle = -1;
-priv->xendConfigVersion = -1;
priv->xshandle = NULL;
diff --git a/src/xen/xen_driver.h b/src/xen/xen_driver.h
index b5582a1..5d50a90 100644
--- a/src/xen/xen_driver.h
+++ b/src/xen/xen_driver.h
@@ -126,8 +126,6 @@ struct _xenUnifiedPrivate {
virDomainXMLOptionPtr xmlopt;
int handle;/* Xen hypervisor handle */
-int xendConfigVersion; /* XenD config version */
-
/* connection to xend */
struct sockaddr_storage addr;
socklen_t addrlen;
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index cd783a1..db3820d 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -864,31 +864,6 @@ xenDaemonDomainLookupByName_ids(virConnectPtr xend,
}
-static int
-xend_detect_config_version(virConnectPtr conn)
-{
-struct sexpr *root;
-const char *value;
-xenUnifiedPrivatePtr priv = conn->privateData;
-int ret = -1;
-
-root = sexpr_get(conn, "/xend/node/");
-if (root == NULL)
-return ret;
-
-value = sexpr_node(root, "node/xend_config_format");
-
-if (value) {
-if (virStrToLong_i(value, NULL, 10, &priv->xendConfigVersion) < 0)
-goto cleanup;
-}
-ret = 0;
- cleanup:
-sexpr_free(root);
-return ret;
-}
-
-
/**
* sexpr_to_xend_domain_state:
* @root: an S-Expression describing a domain
@@ -1186,22 +1161,19 @@ xenDaemonOpen(virConnectPtr conn,
virReportError(VIR_ERR_NO_CONNECT, __FUNCTION__);
goto failed;
}
-if (xenDaemonOpen_unix(conn, conn->uri->path) < 0 ||
-xend_detect_config_version(conn) == -1)
+if (xenDaemonOpen_unix(conn, conn->uri->path) < 0)
goto failed;
} else if (STRCASEEQ(conn->uri->scheme, "xen")) {
/*
* try first to open the unix socket
*/
-if (xenDaemonOpen_unix(conn, "/var/lib/xend/xend-socket") == 0 &&
-xend_detect_config_version(conn) != -1)
+if (xenDaemonOpen_unix(conn, "/var/lib/xend/xend-socket") == 0)
goto done;
/*
* try though http on port 8000
*/
-if (xenDaemonOpen_tcp(conn, "localhost", "8000") < 0 ||
-xend_detect_config_version(conn) == -1)
+if (xenDaemonOpen_tcp(conn, "localhost", "8000") < 0)
goto failed;
} else if (STRCASEEQ(conn->uri->scheme, "http")) {
if (conn->uri->port &&
@@ -1210,8 +1182,7 @@ xenDaemonOpen(virConnectPtr conn,
if (xenDaemonOpen_tcp(conn,
conn->uri->server ? conn->uri->server :
"localhost",
- port ? port : "8000") < 0 ||
-xend_detect_config_version(conn) == -1)
+ port ? port : "8000") < 0)
goto failed;
} else {
virReportError(VIR_ERR_NO_CONNECT, __FUNCTION__);
--
2.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 05/16] Xen: tests: use latest XEND_CONFIG_VERSION in xm/xl tests
Change all tests to use the latest XEND_CONFIG_VERSION (XEND_CONFIG_VERSION_3_1_0 = 4). Fix tests that do not conform to the latest version. Signed-off-by: Jim Fehlig --- .../test-fullvirt-direct-kernel-boot.cfg | 3 +- .../test-fullvirt-direct-kernel-boot.xml | 2 +- tests/xlconfigdata/test-fullvirt-multiusb.cfg | 3 +- tests/xlconfigdata/test-fullvirt-multiusb.xml | 2 +- tests/xlconfigdata/test-new-disk.cfg | 3 +- tests/xlconfigdata/test-new-disk.xml | 2 +- tests/xlconfigdata/test-spice-features.cfg | 3 +- tests/xlconfigdata/test-spice-features.xml | 2 +- tests/xlconfigdata/test-spice.cfg | 3 +- tests/xlconfigdata/test-spice.xml | 2 +- tests/xlconfigtest.c | 29 --- tests/xmconfigdata/test-escape-paths.cfg | 5 +- tests/xmconfigdata/test-escape-paths.xml | 2 +- .../xmconfigdata/test-fullvirt-default-feature.cfg | 5 +- .../xmconfigdata/test-fullvirt-default-feature.xml | 2 +- tests/xmconfigdata/test-fullvirt-force-hpet.cfg| 5 +- tests/xmconfigdata/test-fullvirt-force-hpet.xml| 2 +- tests/xmconfigdata/test-fullvirt-force-nohpet.cfg | 5 +- tests/xmconfigdata/test-fullvirt-force-nohpet.xml | 2 +- tests/xmconfigdata/test-fullvirt-localtime.cfg | 5 +- tests/xmconfigdata/test-fullvirt-localtime.xml | 2 +- tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 3 + tests/xmconfigdata/test-fullvirt-net-netfront.xml | 2 +- tests/xmconfigdata/test-fullvirt-new-cdrom.cfg | 5 +- tests/xmconfigdata/test-fullvirt-new-cdrom.xml | 2 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.cfg | 5 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.xml | 2 +- .../test-fullvirt-serial-dev-2-ports.cfg | 5 +- .../test-fullvirt-serial-dev-2-ports.xml | 2 +- .../test-fullvirt-serial-dev-2nd-port.cfg | 5 +- .../test-fullvirt-serial-dev-2nd-port.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-file.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-file.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-null.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-null.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pipe.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-pipe.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pty.cfg| 5 +- tests/xmconfigdata/test-fullvirt-serial-pty.xml| 2 +- tests/xmconfigdata/test-fullvirt-serial-stdio.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-stdio.xml | 2 +- .../test-fullvirt-serial-tcp-telnet.cfg| 5 +- .../test-fullvirt-serial-tcp-telnet.xml| 2 +- tests/xmconfigdata/test-fullvirt-serial-tcp.cfg| 5 +- tests/xmconfigdata/test-fullvirt-serial-tcp.xml| 2 +- tests/xmconfigdata/test-fullvirt-serial-udp.cfg| 5 +- tests/xmconfigdata/test-fullvirt-serial-udp.xml| 2 +- tests/xmconfigdata/test-fullvirt-serial-unix.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-unix.xml | 2 +- tests/xmconfigdata/test-fullvirt-sound.cfg | 5 +- tests/xmconfigdata/test-fullvirt-sound.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbmouse.cfg | 5 +- tests/xmconfigdata/test-fullvirt-usbmouse.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbtablet.cfg | 5 +- tests/xmconfigdata/test-fullvirt-usbtablet.xml | 2 +- tests/xmconfigdata/test-fullvirt-utc.cfg | 5 +- tests/xmconfigdata/test-fullvirt-utc.xml | 2 +- tests/xmconfigdata/test-no-source-cdrom.cfg| 5 +- tests/xmconfigdata/test-no-source-cdrom.xml| 2 +- tests/xmconfigdata/test-pci-devs.cfg | 5 +- tests/xmconfigdata/test-pci-devs.xml | 2 +- tests/xmconfigtest.c | 89 +++--- 62 files changed, 197 insertions(+), 119 deletions(-) diff --git a/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.cfg b/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.cfg index 1fac3a5..f452af6 100644 --- a/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.cfg +++ b/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.cfg @@ -8,6 +8,7 @@ acpi = 1 apic = 1 hap = 0 viridian = 0 +rtc_timeoffset = 0 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" @@ -18,7 +19,7 @@ vnc = 1 vncunused = 1 vnclisten = "127.0.0.1" vncpasswd = "123poi" -vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000,type=ioemu" ] +vif = [ "mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000" ] parallel = "none" serial = "none" builder = "hvm" diff --git a/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.xml b/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.xml index d59aa21..f750e02 100644 --- a/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.xml +++ b/tests/xlconfigdata/test-fullvirt-direct-kernel-boot.xml @@ -17,7 +
[libvirt] [PATCH 04/16] Xen: tests: remove old xml2sexpr tests
Remove XML to s-expression converstion tests for old xend 3.0.2
config format.
Signed-off-by: Jim Fehlig
---
tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr | 9 ---
tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml | 31
tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr | 10
tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml| 23 --
tests/xml2sexprtest.c| 7 --
5 files changed, 80 deletions(-)
diff --git a/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr
b/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr
deleted file mode 100644
index 20f9228..000
--- a/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr
+++ /dev/null
@@ -1,9 +0,0 @@
-(vm (name 'fvtest')(memory 400)(maxmem 400)(vcpus 1)\
-(uuid 'b5d70dd2-75cd-aca5-1776-9660b059d8bc')(on_poweroff 'destroy')\
-(on_reboot 'restart')(on_crash 'restart')\
-(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(vcpus 1)(boot c)(acpi 1)\
-(usb 1)(parallel none)(serial none)(device_model '/usr/lib64/xen/bin/qemu-dm')\
-(vnc 1)))(localtime 0)\
-(device (vbd (dev 'ioemu:hda')(uname 'file:/root/foo.img')\
-(mode 'w')))(device (vif (mac '00:16:3e:1b:b1:47')(bridge 'xenbr0')\
-(script 'vif-bridge')(model 'e1000')(type ioemu\
diff --git a/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml
b/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml
deleted file mode 100644
index 42185d5..000
--- a/tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml
+++ /dev/null
@@ -1,31 +0,0 @@
-
- fvtest
- b5d70dd275cdaca517769660b059d8bc
-
-hvm
-/usr/lib/xen/boot/hvmloader
-
-
- 409600
- 1
- destroy
- restart
- restart
-
-
-
-
-/usr/lib64/xen/bin/qemu-dm
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr
b/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr
deleted file mode 100644
index c2c1290..000
--- a/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr
+++ /dev/null
@@ -1,10 +0,0 @@
-(vm (name 'pvtest')(memory 420)(maxmem 420)(vcpus 2)\
-(uuid '596a5d21-71f4-8fb2-e068-e2386a5c413e')(on_poweroff 'destroy')\
-(on_reboot 'destroy')(on_crash 'destroy')\
-(image (linux (kernel '/var/lib/xen/vmlinuz.2Dn2YT')\
-(ramdisk '/var/lib/xen/initrd.img.0u-Vhq')\
-(args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/\
-core/test/5.91/x86_64/os ')(vnc 1)(vncunused 0)(vncdisplay 6)\
-(vnclisten '127.0.0.1')(vncpasswd '123456')(keymap 'ja')))\
-(localtime 0)\
-(device (vbd (dev 'xvda')(uname 'file:/root/some.img')(mode 'w'\
diff --git a/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml
b/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml
deleted file mode 100644
index f5f15a8..000
--- a/tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml
+++ /dev/null
@@ -1,23 +0,0 @@
-
- pvtest
- 596a5d2171f48fb2e068e2386a5c413e
-
-linux
-/var/lib/xen/vmlinuz.2Dn2YT
-/var/lib/xen/initrd.img.0u-Vhq
-
method=http://download.fedora.devel.redhat.com/pub/fedora/linux/core/test/5.91/x86_64/os
-
- 430080
- 2
- destroy
- destroy
- destroy
-
-
-
-
-
-
-
-
-
diff --git a/tests/xml2sexprtest.c b/tests/xml2sexprtest.c
index 47c9db8..d884a4b 100644
--- a/tests/xml2sexprtest.c
+++ b/tests/xml2sexprtest.c
@@ -107,12 +107,6 @@ mymain(void)
DO_TEST("pv", "pv", "pvtest", 2);
DO_TEST("fv", "fv-v2", "fvtest", 2);
DO_TEST("fv-vncunused", "fv-vncunused", "fvtest", 2);
-#ifdef WITH_RHEL5_API
-/* RHEL-5 Xen doesn't support the old style vnc configuration */
-DO_TEST("pv-vfb-orig", "pv-vfb-new", "pvtest", 2);
-#else
-DO_TEST("pv-vfb-orig", "pv-vfb-orig", "pvtest", 2);
-#endif
DO_TEST("pv-vfb-new", "pv-vfb-new", "pvtest", 3);
DO_TEST("pv-vfb-new-auto", "pv-vfb-new-auto", "pvtest", 3);
DO_TEST("pv-bootloader", "pv-bootloader", "pvtest", 1);
@@ -162,7 +156,6 @@ mymain(void)
DO_TEST("fv-sound", "fv-sound", "fvtest", 1);
-DO_TEST("fv-net-ioemu", "fv-net-ioemu", "fvtest", 1);
DO_TEST("fv-net-netfront", "fv-net-netfront", "fvtest", 1);
DO_TEST("boot-grub", "boot-grub", "fvtest", 1);
--
2.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 14/16] Xen: xend: remove use of XEND_CONFIG_VERSION
Remove use of XEND_CONFIG_VERSION_* in xend_internal.c
Signed-off-by: Jim Fehlig
---
src/xen/xend_internal.c | 167
1 file changed, 27 insertions(+), 140 deletions(-)
diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 21d99e3..72a1259 100644
--- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -881,10 +881,6 @@ xend_detect_config_version(virConnectPtr conn)
if (value) {
if (virStrToLong_i(value, NULL, 10, &priv->xendConfigVersion) < 0)
goto cleanup;
-} else {
-/* Xen prior to 3.0.3 did not have the xend_config_format
- field, and is implicitly version 1. */
-priv->xendConfigVersion = XEND_CONFIG_VERSION_3_0_2;
}
ret = 0;
cleanup:
@@ -1124,14 +1120,12 @@ sexpr_to_xend_topology(const struct sexpr *root,
virCapsPtr caps)
* Returns the domain def pointer or NULL in case of error.
*/
static virDomainDefPtr
-sexpr_to_domain(virConnectPtr conn, const struct sexpr *root)
+sexpr_to_domain(virConnectPtr conn ATTRIBUTE_UNUSED, const struct sexpr *root)
{
virDomainDefPtr ret = NULL;
unsigned char uuid[VIR_UUID_BUFLEN];
const char *name;
-const char *tmp;
int id = -1;
-xenUnifiedPrivatePtr priv = conn->privateData;
if (sexpr_uuid(uuid, root, "domain/uuid") < 0)
goto error;
@@ -1139,14 +1133,7 @@ sexpr_to_domain(virConnectPtr conn, const struct sexpr
*root)
if (name == NULL)
goto error;
-tmp = sexpr_node(root, "domain/domid");
-/* New 3.0.4 XenD will not report a domid for inactive domains,
- * so only error out for old XenD
- */
-if (!tmp && priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4)
-goto error;
-
-if (tmp)
+if (sexpr_node(root, "domain/domid"))
id = sexpr_int(root, "domain/domid");
return virDomainDefNewFull(name, uuid, id);
@@ -1853,30 +1840,20 @@ xenDaemonDomainPinVcpu(virConnectPtr conn,
{
char buf[VIR_UUID_BUFLEN], mapstr[sizeof(cpumap_t) * 64];
size_t i, j;
-xenUnifiedPrivatePtr priv = conn->privateData;
if (maplen > (int)sizeof(cpumap_t)) {
virReportError(VIR_ERR_INVALID_ARG, __FUNCTION__);
return -1;
}
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) {
-mapstr[0] = '[';
-mapstr[1] = 0;
-} else {
-mapstr[0] = 0;
-}
-
+mapstr[0] = 0;
/* from bit map, build character string of mapped CPU numbers */
for (i = 0; i < maplen; i++) for (j = 0; j < 8; j++)
if (cpumap[i] & (1 << j)) {
snprintf(buf, sizeof(buf), "%zu,", (8 * i) + j);
strcat(mapstr, buf);
}
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4)
-mapstr[strlen(mapstr) - 1] = ']';
-else
-mapstr[strlen(mapstr) - 1] = 0;
+mapstr[strlen(mapstr) - 1] = 0;
snprintf(buf, sizeof(buf), "%d", vcpu);
@@ -2033,53 +2010,23 @@ xenDaemonLookupByUUID(virConnectPtr conn, const
unsigned char *uuid)
virDomainDefPtr ret;
char *name = NULL;
int id = -1;
-xenUnifiedPrivatePtr priv = conn->privateData;
+char *domname = NULL;
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+struct sexpr *root = NULL;
-/* Old approach for xen <= 3.0.3 */
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) {
-char **names, **tmp;
-unsigned char ident[VIR_UUID_BUFLEN];
-names = xenDaemonListDomainsOld(conn);
-tmp = names;
+virUUIDFormat(uuid, uuidstr);
+root = sexpr_get(conn, "/xend/domain/%s?detail=1", uuidstr);
+if (root == NULL)
+return NULL;
+domname = (char*)sexpr_node(root, "domain/name");
+if (sexpr_node(root, "domain/domid")) /* only active domains have domid */
+id = sexpr_int(root, "domain/domid");
+else
+id = -1;
-if (names == NULL)
-return NULL;
-while (*tmp != NULL) {
-id = xenDaemonDomainLookupByName_ids(conn, *tmp, &ident[0]);
-if (id >= 0) {
-if (!memcmp(uuid, ident, VIR_UUID_BUFLEN)) {
-name = *tmp;
-break;
-}
-}
-tmp++;
-}
-tmp = names;
-while (*tmp) {
-if (*tmp != name)
-VIR_FREE(*tmp);
-tmp++;
-}
-VIR_FREE(names);
-} else { /* New approach for xen >= 3.0.4 */
-char *domname = NULL;
-char uuidstr[VIR_UUID_STRING_BUFLEN];
-struct sexpr *root = NULL;
+ignore_value(VIR_STRDUP(name, domname));
-virUUIDFormat(uuid, uuidstr);
-root = sexpr_get(conn, "/xend/domain/%s?detail=1", uuidstr);
-if (root == NULL)
-return NULL;
-domname = (char*)sexpr_node(root, "domain/name");
-if (sexpr_node(root, "domain/domid")) /* only active domains have
domid */
-id = sexpr_int(root, "domain/domid");
-else
-
[libvirt] [PATCH 07/16] Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_xm
Remove use of XEND_CONFIG_VERSION_* in xm parser/formatter.
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_xm.c | 40
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git a/src/xenconfig/xen_xm.c b/src/xenconfig/xen_xm.c
index 13eedf1..aac274d 100644
--- a/src/xenconfig/xen_xm.c
+++ b/src/xenconfig/xen_xm.c
@@ -104,9 +104,9 @@ xenParseXMOS(virConfPtr conf, virDomainDefPtr def)
static int
-xenParseXMDisk(virConfPtr conf, virDomainDefPtr def, int xendConfigVersion)
+xenParseXMDisk(virConfPtr conf, virDomainDefPtr def,
+ int xendConfigVersion ATTRIBUTE_UNUSED)
{
-const char *str = NULL;
virDomainDiskDefPtr disk = NULL;
int hvm = def->os.type == VIR_DOMAIN_OSTYPE_HVM;
virConfValuePtr list = virConfGetValue(conf, "disk");
@@ -271,29 +271,6 @@ xenParseXMDisk(virConfPtr conf, virDomainDefPtr def, int
xendConfigVersion)
}
}
-if (hvm && xendConfigVersion == XEND_CONFIG_VERSION_3_0_2) {
-if (xenConfigGetString(conf, "cdrom", &str, NULL) < 0)
-goto cleanup;
-if (str) {
-if (!(disk = virDomainDiskDefNew(NULL)))
-goto cleanup;
-
-virDomainDiskSetType(disk, VIR_STORAGE_TYPE_FILE);
-disk->device = VIR_DOMAIN_DISK_DEVICE_CDROM;
-if (virDomainDiskSetDriver(disk, "file") < 0)
-goto cleanup;
-if (virDomainDiskSetSource(disk, str) < 0)
-goto cleanup;
-if (VIR_STRDUP(disk->dst, "hdc") < 0)
-goto cleanup;
-disk->bus = VIR_DOMAIN_DISK_BUS_IDE;
-disk->src->readonly = true;
-
-if (VIR_APPEND_ELEMENT(def->disks, def->ndisks, disk) < 0)
-goto cleanup;
-}
-}
-
return 0;
cleanup:
@@ -305,8 +282,8 @@ xenParseXMDisk(virConfPtr conf, virDomainDefPtr def, int
xendConfigVersion)
static int
xenFormatXMDisk(virConfValuePtr list,
virDomainDiskDefPtr disk,
-int hvm,
-int xendConfigVersion)
+int hvm ATTRIBUTE_UNUSED,
+int xendConfigVersion ATTRIBUTE_UNUSED)
{
virBuffer buf = VIR_BUFFER_INITIALIZER;
virConfValuePtr val, tmp;
@@ -343,8 +320,6 @@ xenFormatXMDisk(virConfValuePtr list,
virBufferAdd(&buf, src, -1);
}
virBufferAddLit(&buf, ",");
-if (hvm && xendConfigVersion == XEND_CONFIG_VERSION_3_0_2)
-virBufferAddLit(&buf, "ioemu:");
virBufferAdd(&buf, disk->dst, -1);
if (disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM)
@@ -400,13 +375,6 @@ xenFormatXMDisks(virConfPtr conf, virDomainDefPtr def, int
xendConfigVersion)
diskVal->list = NULL;
for (i = 0; i < def->ndisks; i++) {
-if (xendConfigVersion == XEND_CONFIG_VERSION_3_0_2 &&
-def->disks[i]->device == VIR_DOMAIN_DISK_DEVICE_CDROM &&
-def->disks[i]->dst &&
-STREQ(def->disks[i]->dst, "hdc")) {
-continue;
-}
-
if (def->disks[i]->device == VIR_DOMAIN_DISK_DEVICE_FLOPPY)
continue;
--
2.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 00/16] Xen: remove xend config version
Hi All, Ian Campbell recently attempted [1] to fix and issue around MAX_VIRT_VPUS on ARM that required adding a new XEND_CONFIG_VERSION. After some discussion [2] we decided to drop support for all of the old xend config versions and go with the version supported in Xen 4.0, since the xl syntax was originally based on (and intended to be compatible with) xm circa that point in time. This series removes all traces of xend config version from the codebase, essentially removing support for Xen 3.x. Hopefully I succeeding in making the rather large series reviewable. The series is also available on the remove-xend-config-version branch of my libvirt github clone [2]. [1] https://www.redhat.com/archives/libvir-list/2015-November/msg01153.html [2] https://www.redhat.com/archives/libvir-list/2015-December/msg00148.html [3] https://github.com/jfehlig/libvirt/tree/remove-xend-config-version Jim Fehlig (16): Xen: tests: remove old xm config tests Xen: tests: remove net-ioemu xm config test Xen: tests: remove old sexpr2xml tests Xen: tests: remove old xml2sexpr tests Xen: tests: use latest XEND_CONFIG_VERSION in xm/xl tests Xen: xenconfig: remove XEND_CONFIG_VERSION in common code Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_xm Xen: xenconfig: remove xendConfigVersion from public functions Xen: tests: use latest XEND_CONFIG_VERSION in sexpr2xml tests Xen: xenconfig: remove disks from '(image)' sexpr Xen: tests: use latest XEND_CONFIG_VERSION in xml2sexpr tests Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_sxpr Xen: xen_driver: remove use of XEND_CONFIG_VERSION Xen: xend: remove use of XEND_CONFIG_VERSION Xen: xenconfig: remove xendConfigVersion from public sexpr functions Xen: remove xendConfigVersion from driver private struct src/libxl/libxl_driver.c | 9 +- src/xen/xen_driver.c | 296 --- src/xen/xen_driver.h | 2 - src/xen/xend_internal.c| 224 ++- src/xen/xm_internal.c | 9 +- src/xenconfig/xen_common.c | 211 --- src/xenconfig/xen_common.h | 7 +- src/xenconfig/xen_sxpr.c | 411 ++--- src/xenconfig/xen_sxpr.h | 21 +- src/xenconfig/xen_xl.c | 9 +- src/xenconfig/xen_xl.h | 7 +- src/xenconfig/xen_xm.c | 57 +-- src/xenconfig/xen_xm.h | 5 +- src/xenconfig/xenxs_private.h | 8 - tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml | 2 +- .../sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml| 4 +- .../sexpr2xmldata/sexpr2xml-fv-force-nohpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml| 2 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 9 - tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 48 --- .../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-parallel-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml | 4 +- .../sexpr2xml-fv-serial-dev-2-ports.sexpr | 5 +- .../sexpr2xml-fv-serial-dev-2-ports.xml| 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.sexpr | 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml| 4 +- .../sexpr2xmldata/sexpr2xml-fv-serial-stdio.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml | 4 +- .../sexpr2xml-fv-serial-tcp-telnet.sexpr | 3 +- .../sexpr2xml-fv-serial-tcp-telnet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml| 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml| 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-f
[libvirt] [PATCH 06/16] Xen: xenconfig: remove XEND_CONFIG_VERSION in common code
Remove use of XEND_CONFIG_VERSION_* from xenconfig/xen_common.c
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_common.c | 209 +++--
1 file changed, 71 insertions(+), 138 deletions(-)
diff --git a/src/xenconfig/xen_common.c b/src/xenconfig/xen_common.c
index 7e9c7e5..7932b3c 100644
--- a/src/xenconfig/xen_common.c
+++ b/src/xenconfig/xen_common.c
@@ -323,8 +323,7 @@ xenParseMem(virConfPtr conf, virDomainDefPtr def)
static int
-xenParseTimeOffset(virConfPtr conf, virDomainDefPtr def,
- int xendConfigVersion)
+xenParseTimeOffset(virConfPtr conf, virDomainDefPtr def)
{
int vmlocaltime;
@@ -332,24 +331,15 @@ xenParseTimeOffset(virConfPtr conf, virDomainDefPtr def,
return -1;
if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
-/* only managed HVM domains since 3.1.0 have persistent rtc_timeoffset
*/
-if (xendConfigVersion < XEND_CONFIG_VERSION_3_1_0) {
-if (vmlocaltime)
-def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
-else
-def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_UTC;
-def->clock.data.utc_reset = true;
-} else {
-unsigned long rtc_timeoffset;
-def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_VARIABLE;
-if (xenConfigGetULong(conf, "rtc_timeoffset", &rtc_timeoffset, 0)
< 0)
-return -1;
+unsigned long rtc_timeoffset;
+def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_VARIABLE;
+if (xenConfigGetULong(conf, "rtc_timeoffset", &rtc_timeoffset, 0) < 0)
+return -1;
-def->clock.data.variable.adjustment = (int)rtc_timeoffset;
-def->clock.data.variable.basis = vmlocaltime ?
-VIR_DOMAIN_CLOCK_BASIS_LOCALTIME :
-VIR_DOMAIN_CLOCK_BASIS_UTC;
-}
+def->clock.data.variable.adjustment = (int)rtc_timeoffset;
+def->clock.data.variable.basis = vmlocaltime ?
+VIR_DOMAIN_CLOCK_BASIS_LOCALTIME :
+VIR_DOMAIN_CLOCK_BASIS_UTC;
} else {
/* PV domains do not have an emulated RTC and the offset is fixed. */
def->clock.offset = vmlocaltime ?
@@ -573,7 +563,7 @@ xenParseCPUFeatures(virConfPtr conf, virDomainDefPtr def)
#define MAX_VFB 1024
static int
-xenParseVfb(virConfPtr conf, virDomainDefPtr def, int xendConfigVersion)
+xenParseVfb(virConfPtr conf, virDomainDefPtr def)
{
int val;
char *listenAddr = NULL;
@@ -581,7 +571,7 @@ xenParseVfb(virConfPtr conf, virDomainDefPtr def, int
xendConfigVersion)
virConfValuePtr list;
virDomainGraphicsDefPtr graphics = NULL;
-if (hvm || xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) {
+if (hvm) {
if (xenConfigGetBool(conf, "vnc", &val, 0) < 0)
goto cleanup;
if (val) {
@@ -1028,7 +1018,7 @@ int
xenParseConfigCommon(virConfPtr conf,
virDomainDefPtr def,
virCapsPtr caps,
- int xendConfigVersion)
+ int xendConfigVersion ATTRIBUTE_UNUSED)
{
if (xenParseGeneralMeta(conf, def, caps) < 0)
return -1;
@@ -1042,7 +1032,7 @@ xenParseConfigCommon(virConfPtr conf,
if (xenParseCPUFeatures(conf, def) < 0)
return -1;
-if (xenParseTimeOffset(conf, def, xendConfigVersion) < 0)
+if (xenParseTimeOffset(conf, def) < 0)
return -1;
if (xenConfigCopyStringOpt(conf, "device_model", &def->emulator) < 0)
@@ -1057,7 +1047,7 @@ xenParseConfigCommon(virConfPtr conf,
if (xenParseEmulatedDevices(conf, def) < 0)
return -1;
-if (xenParseVfb(conf, def, xendConfigVersion) < 0)
+if (xenParseVfb(conf, def) < 0)
return -1;
if (xenParseCharDev(conf, def) < 0)
@@ -1109,7 +1099,7 @@ static int
xenFormatNet(virConnectPtr conn,
virConfValuePtr list,
virDomainNetDefPtr net,
- int hvm, int xendConfigVersion)
+ int hvm)
{
virBuffer buf = VIR_BUFFER_INITIALIZER;
virConfValuePtr val, tmp;
@@ -1185,13 +1175,6 @@ xenFormatNet(virConnectPtr conn,
} else {
if (net->model != NULL)
virBufferAsprintf(&buf, ",model=%s", net->model);
-
-/*
- * apparently type ioemu breaks paravirt drivers on HVM so skip
this
- * from XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU
- */
-if (xendConfigVersion <= XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU)
-virBufferAddLit(&buf, ",type=ioemu");
}
}
@@ -1322,18 +1305,36 @@ xenFormatMem(virConfPtr conf, virDomainDefPtr def)
static int
-xenFormatTimeOffset(virConfPtr conf, virDomainDefPtr def, int
xendConfigVersion)
+xenFormatTimeOffset(virConfPtr conf, virDomainDefPtr def)
{
int vmlocaltime;
-if (xendConfigVersion < XEND_CONFIG_VERSION_3_1_0) {
-/* <3.1: UTC and LOCALTIME */
+if (def->os.type == VIR
[libvirt] [PATCH 12/16] Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_sxpr
Remove use of XEND_CONFIG_VERSION_* in s-expression parser/formatter.
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_sxpr.c | 285 ++-
1 file changed, 107 insertions(+), 178 deletions(-)
diff --git a/src/xenconfig/xen_sxpr.c b/src/xenconfig/xen_sxpr.c
index 3e3b43f..defff23 100644
--- a/src/xenconfig/xen_sxpr.c
+++ b/src/xenconfig/xen_sxpr.c
@@ -58,17 +58,14 @@ int xenGetDomIdFromSxprString(const char *sexpr, int
xendConfigVersion, int *id)
}
/* Get a domain id from a S-expression */
-int xenGetDomIdFromSxpr(const struct sexpr *root, int xendConfigVersion, int
*id)
+int xenGetDomIdFromSxpr(const struct sexpr *root,
+int xendConfigVersion ATTRIBUTE_UNUSED,
+int *id)
{
const char * tmp = sexpr_node(root, "domain/domid");
-if (tmp == NULL && xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) { /*
domid was mandatory */
-virReportError(VIR_ERR_INTERNAL_ERROR,
- "%s", _("domain information incomplete, missing id"));
-return -1;
-} else {
-*id = tmp ? sexpr_int(root, "domain/domid") : -1;
-return 0;
-}
+
+*id = tmp ? sexpr_int(root, "domain/domid") : -1;
+return 0;
}
/*
@@ -335,7 +332,7 @@ static int
xenParseSxprDisks(virDomainDefPtr def,
const struct sexpr *root,
int hvm,
- int xendConfigVersion)
+ int xendConfigVersion ATTRIBUTE_UNUSED)
{
const struct sexpr *cur, *node;
virDomainDiskDefPtr disk = NULL;
@@ -466,19 +463,16 @@ xenParseSxprDisks(virDomainDefPtr def,
dst += 6;
disk->device = VIR_DOMAIN_DISK_DEVICE_DISK;
-/* New style disk config from Xen >= 3.0.3 */
-if (xendConfigVersion >= XEND_CONFIG_VERSION_3_0_3) {
-offset = strrchr(dst, ':');
-if (offset) {
-if (STREQ(offset, ":cdrom")) {
-disk->device = VIR_DOMAIN_DISK_DEVICE_CDROM;
-} else if (STREQ(offset, ":disk")) {
-/* The default anyway */
-} else {
-/* Unknown, lets pretend its a disk too */
-}
-offset[0] = '\0';
+offset = strrchr(dst, ':');
+if (offset) {
+if (STREQ(offset, ":cdrom")) {
+disk->device = VIR_DOMAIN_DISK_DEVICE_CDROM;
+} else if (STREQ(offset, ":disk")) {
+/* The default anyway */
+} else {
+/* Unknown, lets pretend its a disk too */
}
+offset[0] = '\0';
}
if (VIR_STRDUP(disk->dst, dst) < 0)
@@ -771,7 +765,8 @@ static int
xenParseSxprGraphicsOld(virDomainDefPtr def,
const struct sexpr *root,
int hvm,
-int xendConfigVersion, int vncport)
+int xendConfigVersion ATTRIBUTE_UNUSED,
+int vncport)
{
const char *tmp;
virDomainGraphicsDefPtr graphics = NULL;
@@ -791,15 +786,6 @@ xenParseSxprGraphicsOld(virDomainDefPtr def,
goto error;
graphics->type = VIR_DOMAIN_GRAPHICS_TYPE_VNC;
-/* For Xen >= 3.0.3, don't generate a fixed port mapping
- * because it will almost certainly be wrong ! Just leave
- * it as -1 which lets caller see that the VNC server isn't
- * present yet. Subsequent dumps of the XML will eventually
- * find the port in XenStore once VNC server has started
- */
-if (port == -1 && xendConfigVersion < XEND_CONFIG_VERSION_3_0_3)
-port = 5900 + def->id;
-
if ((unused && STREQ(unused, "1")) || port == -1)
graphics->data.vnc.autoport = true;
graphics->data.vnc.port = port;
@@ -1098,11 +1084,6 @@ xenParseSxpr(const struct sexpr *root,
goto error;
tmp = sexpr_node(root, "domain/domid");
-if (tmp == NULL && xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) { /*
domid was mandatory */
-virReportError(VIR_ERR_INTERNAL_ERROR,
- "%s", _("domain information incomplete, missing id"));
-goto error;
-}
def->virtType = VIR_DOMAIN_VIRT_XEN;
if (tmp)
def->id = sexpr_int(root, "domain/domid");
@@ -1234,6 +1215,8 @@ xenParseSxpr(const struct sexpr *root,
vmlocaltime = sexpr_int(root, "domain/localtime");
if (hvm) {
const char *value = sexpr_node(root, "domain/image/hvm/localtime");
+int rtc_offset;
+
if (value) {
if (virStrToLong_i(value, NULL, 0, &vmlocaltime) < 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
@@ -1241,22 +1224,12 @@ xenParseSxpr(const struct sexpr *root,
go
[libvirt] [PATCH 13/16] Xen: xen_driver: remove use of XEND_CONFIG_VERSION
Remove use of XEND_CONFIG_VERSION_* in the Xen unified driver.
Signed-off-by: Jim Fehlig
---
src/xen/xen_driver.c | 284 +++
1 file changed, 61 insertions(+), 223 deletions(-)
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index 321a250..27da520 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -109,16 +109,10 @@ static virDomainDefPtr xenGetDomainDefForID(virConnectPtr
conn, int id)
static virDomainDefPtr xenGetDomainDefForName(virConnectPtr conn, const char
*name)
{
-xenUnifiedPrivatePtr priv = conn->privateData;
virDomainDefPtr ret;
ret = xenDaemonLookupByName(conn, name);
-/* Try XM for inactive domains. */
-if (!ret &&
-priv->xendConfigVersion <= XEND_CONFIG_VERSION_3_0_3)
-ret = xenXMDomainLookupByName(conn, name);
-
if (!ret && virGetLastError() == NULL)
virReportError(VIR_ERR_NO_DOMAIN, __FUNCTION__);
@@ -128,18 +122,13 @@ static virDomainDefPtr
xenGetDomainDefForName(virConnectPtr conn, const char *na
static virDomainDefPtr xenGetDomainDefForUUID(virConnectPtr conn, const
unsigned char *uuid)
{
-xenUnifiedPrivatePtr priv = conn->privateData;
virDomainDefPtr ret;
ret = xenHypervisorLookupDomainByUUID(conn, uuid);
-/* Try XM for inactive domains. */
-if (!ret) {
-if (priv->xendConfigVersion <= XEND_CONFIG_VERSION_3_0_3)
-ret = xenXMDomainLookupByUUID(conn, uuid);
-else
-ret = xenDaemonLookupByUUID(conn, uuid);
-}
+/* Try xend for inactive domains. */
+if (!ret)
+ret = xenDaemonLookupByUUID(conn, uuid);
if (!ret && virGetLastError() == NULL)
virReportError(VIR_ERR_NO_DOMAIN, __FUNCTION__);
@@ -516,15 +505,6 @@ xenUnifiedConnectOpen(virConnectPtr conn,
virConnectAuthPtr auth, unsigned int f
VIR_DEBUG("Activated XenD sub-driver");
priv->opened[XEN_UNIFIED_XEND_OFFSET] = 1;
-/* For old XenD, the XM driver is required to succeed */
-if (priv->xendConfigVersion <= XEND_CONFIG_VERSION_3_0_3) {
-VIR_DEBUG("Trying XM sub-driver");
-if (xenXMOpen(conn, auth, flags) < 0)
-goto error;
-VIR_DEBUG("Activated XM sub-driver");
-priv->opened[XEN_UNIFIED_XM_OFFSET] = 1;
-}
-
VIR_DEBUG("Trying XS sub-driver");
if (xenStoreOpen(conn, auth, flags) < 0)
goto error;
@@ -1055,7 +1035,6 @@ xenUnifiedDomainDestroy(virDomainPtr dom)
static char *
xenUnifiedDomainGetOSType(virDomainPtr dom)
{
-xenUnifiedPrivatePtr priv = dom->conn->privateData;
char *ret = NULL;
virDomainDefPtr def;
@@ -1065,17 +1044,10 @@ xenUnifiedDomainGetOSType(virDomainPtr dom)
if (virDomainGetOSTypeEnsureACL(dom->conn, def) < 0)
goto cleanup;
-if (def->id < 0) {
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4) {
-virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Unable to query OS type for inactive domain"));
-return NULL;
-} else {
-ret = xenDaemonDomainGetOSType(dom->conn, def);
-}
-} else {
+if (def->id < 0)
+ret = xenDaemonDomainGetOSType(dom->conn, def);
+else
ret = xenHypervisorDomainGetOSType(dom->conn, def);
-}
cleanup:
virDomainDefFree(def);
@@ -1086,7 +1058,6 @@ xenUnifiedDomainGetOSType(virDomainPtr dom)
static unsigned long long
xenUnifiedDomainGetMaxMemory(virDomainPtr dom)
{
-xenUnifiedPrivatePtr priv = dom->conn->privateData;
unsigned long long ret = 0;
virDomainDefPtr def;
@@ -1096,14 +1067,10 @@ xenUnifiedDomainGetMaxMemory(virDomainPtr dom)
if (virDomainGetMaxMemoryEnsureACL(dom->conn, def) < 0)
goto cleanup;
-if (def->id < 0) {
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4)
-ret = xenXMDomainGetMaxMemory(dom->conn, def);
-else
-ret = xenDaemonDomainGetMaxMemory(dom->conn, def);
-} else {
+if (def->id < 0)
+ret = xenDaemonDomainGetMaxMemory(dom->conn, def);
+else
ret = xenHypervisorGetMaxMemory(dom->conn, def);
-}
cleanup:
virDomainDefFree(def);
@@ -1113,7 +1080,6 @@ xenUnifiedDomainGetMaxMemory(virDomainPtr dom)
static int
xenUnifiedDomainSetMaxMemory(virDomainPtr dom, unsigned long memory)
{
-xenUnifiedPrivatePtr priv = dom->conn->privateData;
int ret = -1;
virDomainDefPtr def;
@@ -1123,14 +1089,10 @@ xenUnifiedDomainSetMaxMemory(virDomainPtr dom, unsigned
long memory)
if (virDomainSetMaxMemoryEnsureACL(dom->conn, def) < 0)
goto cleanup;
-if (def->id < 0) {
-if (priv->xendConfigVersion < XEND_CONFIG_VERSION_3_0_4)
-ret = xenXMDomainSetMaxMemory(dom->conn, def, memory);
-else
-ret = xenDaemonDomainSetMaxMemory(dom->conn, def, memory);
-} else {
+if (def->id < 0)
+ret = xenDaemonDomainSetMaxMemory(dom->conn, de
[libvirt] [PATCH 02/16] Xen: tests: remove net-ioemu xm config test
Remove the fullvirt-net-ioemu test since explicitly specifying
'type=ioemu' has not been needed in xm/xend for a long time. It is
not used at all in xl/libxl.
Signed-off-by: Jim Fehlig
---
tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 25 -
tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 49 --
tests/xmconfigtest.c | 1 -
3 files changed, 75 deletions(-)
diff --git a/tests/xmconfigdata/test-fullvirt-net-ioemu.cfg
b/tests/xmconfigdata/test-fullvirt-net-ioemu.cfg
deleted file mode 100644
index 722f021..000
--- a/tests/xmconfigdata/test-fullvirt-net-ioemu.cfg
+++ /dev/null
@@ -1,25 +0,0 @@
-name = "XenGuest2"
-uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
-maxmem = 579
-memory = 394
-vcpus = 1
-pae = 1
-acpi = 1
-apic = 1
-localtime = 0
-on_poweroff = "destroy"
-on_reboot = "restart"
-on_crash = "restart"
-device_model = "/usr/lib/xen/bin/qemu-dm"
-sdl = 0
-vnc = 1
-vncunused = 1
-vnclisten = "127.0.0.1"
-vncpasswd = "123poi"
-vif = [
"mac=00:16:3e:66:92:9c,bridge=xenbr1,script=vif-bridge,model=e1000,type=ioemu" ]
-parallel = "none"
-serial = "none"
-builder = "hvm"
-kernel = "/usr/lib/xen/boot/hvmloader"
-boot = "d"
-disk = [ "phy:/dev/HostVG/XenGuest2,hda,w", "file:/root/boot.iso,hdc:cdrom,r" ]
diff --git a/tests/xmconfigdata/test-fullvirt-net-ioemu.xml
b/tests/xmconfigdata/test-fullvirt-net-ioemu.xml
deleted file mode 100644
index ad15dde..000
--- a/tests/xmconfigdata/test-fullvirt-net-ioemu.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-
- XenGuest2
- c7a5fdb2-cdaf-9455-926a-d65c16db1809
- 592896
- 403456
- 1
-
-hvm
-/usr/lib/xen/boot/hvmloader
-
-
-
-
-
-
-
-
- destroy
- restart
- restart
-
-/usr/lib/xen/bin/qemu-dm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/xmconfigtest.c b/tests/xmconfigtest.c
index 04535fb..bfbd9c4 100644
--- a/tests/xmconfigtest.c
+++ b/tests/xmconfigtest.c
@@ -243,7 +243,6 @@ mymain(void)
DO_TEST("fullvirt-sound", 2);
-DO_TEST("fullvirt-net-ioemu", 2);
DO_TEST("fullvirt-net-netfront", 2);
DO_TEST_FORMAT("fullvirt-default-feature", 2);
--
2.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 03/16] Xen: tests: remove old sexpr2xml tests
Remove s-expression to XML conversion tests for old xend 3.0.2
config format.
Signed-off-by: Jim Fehlig
---
tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 9 -
tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 48
tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr | 9 -
tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml| 34 -
tests/sexpr2xmltest.c| 2 -
5 files changed, 102 deletions(-)
diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr
b/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr
deleted file mode 100644
index e7031dc..000
--- a/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr
+++ /dev/null
@@ -1,9 +0,0 @@
-(domain (domid 3)(name 'fvtest')(memory 400)(maxmem 400)(vcpus 1)\
-(uuid 'b5d70dd275cdaca517769660b059d8bc')(on_poweroff 'destroy')\
-(on_reboot 'restart')(on_crash 'restart')\
-(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')\
-(device_model '/usr/lib64/xen/bin/qemu-dm')(boot c)(cdrom '/root/boot.iso')\
-(acpi 1)(vnc 1)(keymap ja)))(device (vbd (dev 'ioemu:hda')\
-(uname 'file:/root/foo.img')(mode 'w')))\
-(device (vif (mac '00:16:3e:1b:b1:47')(bridge 'xenbr0')\
-(script 'vif-bridge')(model 'e1000')(type 'ioemu'
diff --git a/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml
b/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml
deleted file mode 100644
index ec75365..000
--- a/tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml
+++ /dev/null
@@ -1,48 +0,0 @@
-
- fvtest
- b5d70dd2-75cd-aca5-1776-9660b059d8bc
- 409600
- 409600
- 1
-
-hvm
-/usr/lib/xen/boot/hvmloader
-
-
-
-
-
-
- destroy
- restart
- restart
-
-/usr/lib64/xen/bin/qemu-dm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr
b/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr
deleted file mode 100644
index c825f32..000
--- a/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr
+++ /dev/null
@@ -1,9 +0,0 @@
-(domain (domid 6)(name 'pvtest')(memory 420)(maxmem 420)(vcpus 2)\
-(uuid '596a5d2171f48fb2e068e2386a5c413e')(on_poweroff 'destroy')\
-(on_reboot 'destroy')(on_crash 'destroy')\
-(image (linux (kernel '/var/lib/xen/vmlinuz.2Dn2YT')\
-(ramdisk '/var/lib/xen/initrd.img.0u-Vhq')\
-(args ' method=http://download.fedora.devel.redhat.com/pub/fedora/linux/\
-core/test/5.91/x86_64/os ')(vnc 1)(vncunused 1)(vnclisten 0.0.0.0)\
-(vncpasswd 123456)(keymap ja)))(device (vbd (dev 'xvda')\
-(uname 'file:/root/some.img')(mode 'w'
diff --git a/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml
b/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml
deleted file mode 100644
index f5b80c8..000
--- a/tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml
+++ /dev/null
@@ -1,34 +0,0 @@
-
- pvtest
- 596a5d21-71f4-8fb2-e068-e2386a5c413e
- 430080
- 430080
- 2
-
-linux
-/var/lib/xen/vmlinuz.2Dn2YT
-/var/lib/xen/initrd.img.0u-Vhq
-
method=http://download.fedora.devel.redhat.com/pub/fedora/linux/core/test/5.91/x86_64/os
-
-
- destroy
- destroy
- destroy
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/sexpr2xmltest.c b/tests/sexpr2xmltest.c
index f7f61cc..c95de9f 100644
--- a/tests/sexpr2xmltest.c
+++ b/tests/sexpr2xmltest.c
@@ -136,7 +136,6 @@ mymain(void)
DO_TEST("fv", "fv", 1);
DO_TEST("pv", "pv", 2);
DO_TEST("fv-v2", "fv-v2", 2);
-DO_TEST("pv-vfb-orig", "pv-vfb-orig", 2);
DO_TEST("pv-vfb-new", "pv-vfb-new", 3);
DO_TEST("pv-vfb-new-vncdisplay", "pv-vfb-new-vncdisplay", 3);
DO_TEST("pv-vfb-type-crash", "pv-vfb-type-crash", 3);
@@ -185,7 +184,6 @@ mymain(void)
DO_TEST("fv-sound", "fv-sound", 1);
DO_TEST("fv-sound-all", "fv-sound-all", 1);
-DO_TEST("fv-net-ioemu", "fv-net-ioemu", 1);
DO_TEST("fv-net-netfront", "fv-net-netfront", 1);
DO_TEST("fv-empty-kernel", "fv-empty-kernel", 1);
--
2.1.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 10/16] Xen: xenconfig: remove disks from '(image)' sexpr
It has been quite some time since xend required specifying cdroms
and fds in '(image (hvm ...))'. Remove the code from the parsing
and formatting functions and fixup the associated tests.
Signed-off-by: Jim Fehlig
---
src/xenconfig/xen_sxpr.c | 94 --
tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr | 2 +-
.../xml2sexprdata/xml2sexpr-fv-force-nohpet.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr | 2 +-
.../xml2sexprdata/xml2sexpr-fv-parallel-tcp.sexpr | 2 +-
.../xml2sexpr-fv-serial-dev-2-ports.sexpr | 2 +-
.../xml2sexpr-fv-serial-dev-2nd-port.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-file.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-null.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-pipe.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-pty.sexpr | 2 +-
.../xml2sexprdata/xml2sexpr-fv-serial-stdio.sexpr | 2 +-
.../xml2sexpr-fv-serial-tcp-telnet.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-tcp.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-udp.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-serial-unix.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-sound.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv-usbmouse.sexpr| 2 +-
tests/xml2sexprdata/xml2sexpr-fv-utc.sexpr | 2 +-
tests/xml2sexprdata/xml2sexpr-fv.sexpr | 2 +-
20 files changed, 19 insertions(+), 113 deletions(-)
diff --git a/src/xenconfig/xen_sxpr.c b/src/xenconfig/xen_sxpr.c
index 49f438d..3e3b43f 100644
--- a/src/xenconfig/xen_sxpr.c
+++ b/src/xenconfig/xen_sxpr.c
@@ -1317,74 +1317,6 @@ xenParseSxpr(const struct sexpr *root,
vncport) < 0)
goto error;
-
-/* Old style cdrom config from Xen <= 3.0.2 */
-if (hvm &&
-xendConfigVersion == XEND_CONFIG_VERSION_3_0_2) {
-tmp = sexpr_node(root, "domain/image/hvm/cdrom");
-if ((tmp != NULL) && (tmp[0] != 0)) {
-virDomainDiskDefPtr disk;
-if (!(disk = virDomainDiskDefNew(NULL)))
-goto error;
-if (virDomainDiskSetSource(disk, tmp) < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-virDomainDiskSetType(disk, VIR_STORAGE_TYPE_FILE);
-disk->device = VIR_DOMAIN_DISK_DEVICE_CDROM;
-if (VIR_STRDUP(disk->dst, "hdc") < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-if (virDomainDiskSetDriver(disk, "file") < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-disk->bus = VIR_DOMAIN_DISK_BUS_IDE;
-disk->src->readonly = true;
-
-if (VIR_APPEND_ELEMENT(def->disks, def->ndisks, disk) < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-}
-}
-
-
-/* Floppy disk config */
-if (hvm) {
-const char *const fds[] = { "fda", "fdb" };
-size_t i;
-for (i = 0; i < ARRAY_CARDINALITY(fds); i++) {
-tmp = sexpr_fmt_node(root, "domain/image/hvm/%s", fds[i]);
-if ((tmp != NULL) && (tmp[0] != 0)) {
-virDomainDiskDefPtr disk;
-if (!(disk = virDomainDiskDefNew(NULL)))
-goto error;
-if (virDomainDiskSetSource(disk, tmp) < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-virDomainDiskSetType(disk, VIR_STORAGE_TYPE_FILE);
-disk->device = VIR_DOMAIN_DISK_DEVICE_FLOPPY;
-if (VIR_STRDUP(disk->dst, fds[i]) < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-if (virDomainDiskSetSource(disk, "file") < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-disk->bus = VIR_DOMAIN_DISK_BUS_FDC;
-
-if (VIR_APPEND_ELEMENT(def->disks, def->ndisks, disk) < 0) {
-virDomainDiskDefFree(disk);
-goto error;
-}
-}
-}
-}
-
/* in case of HVM we have USB device emulation */
if (hvm &&
xenParseSxprUSB(def, root) < 0)
@@ -2357,32 +2289,6 @@ xenFormatSxpr(virConnectPtr conn,
}
virBufferAsprintf(&buf, "(boot %s)", bootorder);
-/* some disk devices are defined here */
-for (i = 0; i < def->ndisks; i++) {
-const char *src = virDomainDiskGetSource(def->disks[i]);
-
-switch (def->disks[i]->device) {
-case VIR_DOMAIN_DISK_DEVICE_CDROM:
-/* Only xend <= 3.0.2 wants cdrom config here */
-if (xendConfigVersion != XEND_CONFIG_VERSION_3_0_2)
-
[libvirt] [PATCH 01/16] Xen: tests: remove old xm config tests
Remove xm config tests for old xend 3.0.2 config format.
Signed-off-by: Jim Fehlig
---
tests/xmconfigdata/test-fullvirt-old-cdrom.cfg | 26
tests/xmconfigdata/test-fullvirt-old-cdrom.xml | 49 --
.../test-paravirt-old-pvfb-vncdisplay.cfg | 18
.../test-paravirt-old-pvfb-vncdisplay.xml | 36
tests/xmconfigdata/test-paravirt-old-pvfb.cfg | 17
tests/xmconfigdata/test-paravirt-old-pvfb.xml | 36
tests/xmconfigtest.c | 3 --
7 files changed, 185 deletions(-)
diff --git a/tests/xmconfigdata/test-fullvirt-old-cdrom.cfg
b/tests/xmconfigdata/test-fullvirt-old-cdrom.cfg
deleted file mode 100755
index 5c8b47b..000
--- a/tests/xmconfigdata/test-fullvirt-old-cdrom.cfg
+++ /dev/null
@@ -1,26 +0,0 @@
-name = "XenGuest2"
-uuid = "c7a5fdb2-cdaf-9455-926a-d65c16db1809"
-maxmem = 579
-memory = 394
-vcpus = 1
-pae = 1
-acpi = 1
-apic = 1
-cdrom = "/root/boot.iso"
-localtime = 0
-on_poweroff = "destroy"
-on_reboot = "restart"
-on_crash = "restart"
-device_model = "/usr/lib/xen/bin/qemu-dm"
-sdl = 0
-vnc = 1
-vncunused = 1
-vnclisten = "127.0.0.1"
-vncpasswd = "123poi"
-vif = [
"mac=00:16:3e:66:92:9c,bridge=xenbr0,script=vif-bridge,model=e1000,type=ioemu" ]
-parallel = "none"
-serial = "none"
-builder = "hvm"
-kernel = "/usr/lib/xen/boot/hvmloader"
-boot = "d"
-disk = [ "phy:/dev/HostVG/XenGuest2,ioemu:hda,w" ]
diff --git a/tests/xmconfigdata/test-fullvirt-old-cdrom.xml
b/tests/xmconfigdata/test-fullvirt-old-cdrom.xml
deleted file mode 100644
index dd5fd3f..000
--- a/tests/xmconfigdata/test-fullvirt-old-cdrom.xml
+++ /dev/null
@@ -1,49 +0,0 @@
-
- XenGuest2
- c7a5fdb2-cdaf-9455-926a-d65c16db1809
- 592896
- 403456
- 1
-
-hvm
-/usr/lib/xen/boot/hvmloader
-
-
-
-
-
-
-
-
- destroy
- restart
- restart
-
-/usr/lib/xen/bin/qemu-dm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.cfg
b/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.cfg
deleted file mode 100644
index 94c01ed..000
--- a/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.cfg
+++ /dev/null
@@ -1,18 +0,0 @@
-name = "XenGuest1"
-uuid = "c7a5fdb0-cdaf-9455-926a-d65c16db1809"
-maxmem = 579
-memory = 394
-vcpus = 1
-localtime = 0
-on_poweroff = "destroy"
-on_reboot = "restart"
-on_crash = "restart"
-sdl = 0
-vnc = 1
-vncunused = 0
-vncdisplay = 25
-vnclisten = "127.0.0.1"
-vncpasswd = "123poi"
-vif = [ "mac=00:16:3e:66:94:9c,bridge=br0,script=vif-bridge" ]
-bootloader = "/usr/bin/pygrub"
-disk = [ "phy:/dev/HostVG/XenGuest1,xvda,w" ]
diff --git a/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.xml
b/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.xml
deleted file mode 100644
index ce7bfb9..000
--- a/tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-
- XenGuest1
- c7a5fdb0-cdaf-9455-926a-d65c16db1809
- 592896
- 403456
- 1
- /usr/bin/pygrub
-
-linux
-
-
- destroy
- restart
- restart
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/xmconfigdata/test-paravirt-old-pvfb.cfg
b/tests/xmconfigdata/test-paravirt-old-pvfb.cfg
deleted file mode 100755
index 9f11f5b..000
--- a/tests/xmconfigdata/test-paravirt-old-pvfb.cfg
+++ /dev/null
@@ -1,17 +0,0 @@
-name = "XenGuest1"
-uuid = "c7a5fdb0-cdaf-9455-926a-d65c16db1809"
-maxmem = 579
-memory = 394
-vcpus = 1
-localtime = 0
-on_poweroff = "destroy"
-on_reboot = "restart"
-on_crash = "restart"
-sdl = 0
-vnc = 1
-vncunused = 1
-vnclisten = "127.0.0.1"
-vncpasswd = "123poi"
-vif = [ "mac=00:16:3e:66:94:9c,bridge=br0,script=vif-bridge" ]
-bootloader = "/usr/bin/pygrub"
-disk = [ "phy:/dev/HostVG/XenGuest1,xvda,w" ]
diff --git a/tests/xmconfigdata/test-paravirt-old-pvfb.xml
b/tests/xmconfigdata/test-paravirt-old-pvfb.xml
deleted file mode 100644
index cba6dff..000
--- a/tests/xmconfigdata/test-paravirt-old-pvfb.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-
- XenGuest1
- c7a5fdb0-cdaf-9455-926a-d65c16db1809
- 592896
- 403456
- 1
- /usr/bin/pygrub
-
-linux
-
-
- destroy
- restart
- restart
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/tests/xmconfigtest.c b/tests/xmconfigtest.c
index 804f9ee..04535fb 100644
--- a/tests/xmconfigtest.c
+++ b/tests/xmconfigtest.c
@@ -214,14 +214,11 @@ mymain(void)
DO_TEST_FORMAT(name, version); \
} while (0)
-DO_TEST("paravirt-old-pvfb", 1);
-DO_TEST("paravirt-old-pvfb-vncdisplay", 1);
DO_TEST("paravirt-new-pvfb", 3);
DO_TEST("
Re: [libvirt] vf configuration cleanup when VM is delete
On 12/15/2015 02:45 PM, Laine Stump wrote: > On 12/15/2015 01:34 PM, Laine Stump wrote: >> On 12/13/2015 10:51 AM, Moshe Levi wrote: >>> >>> Hi, >>> >>> I have a setup with libvirt 1.3.0 and OpenStack trunk. >>> >>> Before launched the VM ip link command show the following VF mac/vlan >>> configuration [1] >>> >>> When I launch a VM with via openstack api >>> (OpenStack direct >>> port) >>> >>> I can see that the VF get the mac/vlan according to libvrit xml [2] and ip >>> link >>> command [3], but when I delete the VM the mac/vlan config are still shown >>> as in [3] >>> and not restored to [1] >>> >>> Shouldn’t libvirt restore the mac/vlan to [1]. >>> >>> The same problem exists when using (OpenStack >>> macvtap port) >>> but just for the MAC configuration of the VF. >>> >> >> What libvirt does is to restore the MAC address to whatever it was before we >> set it up >> for use with a guest. Although there are some sriov net drivers that (for >> some >> unfathomable reason) think it's cool to assign a random MAC address to each >> VF at boot >> time, the "normal" thing is for the VFs to have a MAC address of all 0's to >> start with. >> So libvirt should be saving 00:00:00:00:00:00 (it will be in the file >> /var/run/libvirt/hostdevmgr/$ifname_vf$vfnum) then setting the MAC to use; >> when done, >> libvirt will read the 00:00:00:00:00:00 and use netlink to set the MAC >> address, but this >> is apparently failing. >> >> I checked on my Fedora 22 system with the igb driver, and found that if the >> MAC address >> was originally set to something other than 0's, it was restored properly by >> libvirt, but >> if it was set to all 0's originally, the attempt to set it back to 0 would >> fail. >> >> I then tried doing the same thing with the "ip" utility: >> >> # ip link set dev p4p2 vf 0 mac 00:00:00:00:00:00 >> >> and I get the following response: >> >> RTNETLINK answers: Invalid argument >> >> So it appears that either the kernel or the NIC driver is refusing to set >> the MAC >> address to all 0's. I'm reasonably certain this is a regression in the >> kernel, > > Sigh. It appears that this has "always" been the case - I just checked on a > 2.6.32-573 > RHEL kernel, and a 3.10.x RHEL7.2 kernel, and 4.1 (Fedora 22) and both of > them also refuse > to set the MAC address to 00:00:00:00:00:00. I'm not sure if this limitation > is in the NIC > driver or some basic code in the kernel. It's considered to be an invalid address by is_valid_ether_addr() function. There appear to be different behaviour in some adapters. In current upstream, it looks like a quarter of the VF capable drivers (bnxt, enic, fm10k, sfc) permit VF mac setting of all zeros. The others simply use is_valid_ether_addr function without specifically testing for all-0. I am not sure if this is HW related or simply oversights... Might want to bringing this up on netdev. -vlad > > >> although I can't say how long it's been there, as I don't normally pay >> attention to this >> (and as I said, many SRIOV NIC drivers don't default their VFs to 0 MAC >> addresses) >> >> What distro and kernel are you using for your tests? >> >> >>> [1] - 24: enp3s0f0: mtu 1500 qdisc mq >>> master >>> ovs-system state UP mode DEFAULT group default qlen 1000 >>> >>> link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff >>> >>> vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> [2] - >>> >>> >>> >>> >>> >>> >>> >>> >> function='0x7'/> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> function='0x0'/> >>> >>> >>> >>> [3] 24: enp3s0f0: mtu 1500 qdisc mq >>> master ovs-system >>> state UP mode DEFAULT group default qlen 1000 >>> >>> link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff >>> >>> vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto >>> >>> vf 3 MAC fa:16:3e:11:af:fe, vlan 190, spoof checking off, link-state >>> enable >>> >>> >>> >>> -- >>> libvir-list mailing list >>> libvir-list@redhat.com >>> https://www.redhat.com/mailman/listinfo/libvir-list >> F15 >> >> >> -- >> libvir-list mailing list >> libvir-list@redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list > > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v7 05/13] virstoragefile: change backingStore to backingStores.
On 12/03/2015 09:35 AM, Matthias Gatto wrote:
> The backingStore field was a virStorageSourcePtr.
> Because a quorum can contain more that one backingStore at the same level,
> it's now an array of 'virStorageSourcePtr'.
>
> This patch rename src->backingStore to src->backingStores,
> Made the necessary changes to virStorageSourceSetBackingStore
> and virStorageSourceGetBackingStore.
> virStorageSourceSetBackingStore can now expand the size of src->backingStores.
>
> Signed-off-by: Matthias Gatto
> ---
> src/storage/storage_backend.c| 2 +-
> src/storage/storage_backend_fs.c | 2 +-
> src/util/virstoragefile.c| 66
> +++-
> src/util/virstoragefile.h| 3 +-
> 4 files changed, 56 insertions(+), 17 deletions(-)
>
> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
> index 08ed1dd..d71bb1a 100644
> --- a/src/storage/storage_backend.c
> +++ b/src/storage/storage_backend.c
> @@ -498,7 +498,7 @@ virStorageBackendCreateRaw(virConnectPtr conn
> ATTRIBUTE_UNUSED,
> goto cleanup;
> }
>
> -if (vol->target.backingStore) {
> +if (vol->target.backingStores) {
> virReportError(VIR_ERR_NO_SUPPORT, "%s",
> _("backing storage not supported for raw volumes"));
> goto cleanup;
> diff --git a/src/storage/storage_backend_fs.c
> b/src/storage/storage_backend_fs.c
> index b216e91..68419e3 100644
> --- a/src/storage/storage_backend_fs.c
> +++ b/src/storage/storage_backend_fs.c
> @@ -1100,7 +1100,7 @@ static int createFileDir(virConnectPtr conn
> ATTRIBUTE_UNUSED,
> return -1;
> }
>
> -if (vol->target.backingStore) {
> +if (vol->target.backingStores) {
> virReportError(VIR_ERR_NO_SUPPORT, "%s",
> _("backing storage not supported for directories
> volumes"));
> return -1;
I would think these two accesses would need a read access rather than
changing from backingStore to backingStores. First clue would be that
now that everything is supposed to be contained within virstoragefile.c
so any change outside that has been something changed since you first
started this adventure.
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index 1299f98..8c05786 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
> @@ -1809,22 +1809,50 @@ virStorageSourcePoolDefCopy(const
> virStorageSourcePoolDef *src)
> }
>
>
> +/**
> + * virStorageSourceGetBackingStore:
> + * @src: virStorageSourcePtr containing the backing stores
> + * @pos: position of the backing store to get
> + *
> + * return the backingStore at the position of @pos
> + */
> virStorageSourcePtr
> -virStorageSourceGetBackingStore(const virStorageSource *src,
> -size_t pos ATTRIBUTE_UNUSED)
> +virStorageSourceGetBackingStore(const virStorageSource *src, size_t pos)
> {
> -if (!src)
> +if (!src || !src->backingStores || pos >= src->nBackingStores)
> return NULL;
> -return src->backingStore;
> +return src->backingStores[pos];
> }
>
>
> +/**
> + * virStorageSourceSetBackingStore:
> + * @src: virStorageSourcePtr to hold @backingStore
> + * @backingStore: backingStore to store
> + * @pos: position of the backing store to store
> + *
> + * Set @backingStore at @pos in src->backingStores.
> + * If src->backingStores don't have the space to contain
> + * @backingStore, we expand src->backingStores.
> + * If src->backingStores[pos] is alerady set, free it.
> + */
> int
> virStorageSourceSetBackingStore(virStorageSourcePtr src,
> virStorageSourcePtr backingStore,
> -size_t pos ATTRIBUTE_UNUSED)
> +size_t pos)
> {
> -src->backingStore = backingStore;
> +if (!src)
> +return -1;
> +
> +if (pos >= src->nBackingStores) {
> +int nbr = pos - src->nBackingStores + 1;
> +if (VIR_EXPAND_N(src->backingStores, src->nBackingStores, nbr) < 0)
> +return -1;
> +}
> +
> +if (src->backingStores[pos])
> +virStorageSourceFree(src->backingStores[pos]);
> +src->backingStores[pos] = backingStore;
> return 0;
> }
>
> @@ -1843,6 +1871,7 @@ virStorageSourceCopy(const virStorageSource *src,
> bool backingChain)
> {
> virStorageSourcePtr ret = NULL;
> +size_t i;
>
> if (VIR_ALLOC(ret) < 0)
> return NULL;
> @@ -1855,6 +1884,8 @@ virStorageSourceCopy(const virStorageSource *src,
> ret->physical = src->physical;
> ret->readonly = src->readonly;
> ret->shared = src->shared;
> +ret->nBackingStores = src->nBackingStores;
> +ret->threshold = src->threshold;
This appears to be a rogue change... It causes my build to fail. Looks
like it's defined in patch 7 and further used in patch 8 - so those will
need an update once this is pushed.
John
>
> /* s
Re: [libvirt] [PATCH v7 06/13] virstoragefile: Add virStorageSourceIsRAID
On 12/03/2015 09:35 AM, Matthias Gatto wrote:
> Add a new function which return true if a virStorageSourcePtr is
> a RAID.
>
> For now, quorum is the only RAID we have.
>
> This function is usefull, because, a lot of code access directly
> to a virStorageSource internal member (like path) with some functions
> like "virDomainDiskGetSource".
> This beavious won't work with Quorum, and so we need to add
> exeptions for these functions, but I'm not convinced by the idea to add a lot
> of "disk->format == QUORUM" in all the code that deserve
> exeption for Quorum, so I've add a generic function for this.
>
> Signed-off-by: Matthias Gatto
> ---
> src/libvirt_private.syms | 1 +
> src/util/virstoragefile.c | 27 +++
> src/util/virstoragefile.h | 2 ++
> 3 files changed, 30 insertions(+)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index d3baee8..571b6f7 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -2195,6 +2195,7 @@ virStorageSourceGetSecurityLabelDef;
> virStorageSourceInitChainElement;
> virStorageSourceIsEmpty;
> virStorageSourceIsLocalStorage;
> +virStorageSourceIsRAID;
> virStorageSourceNewFromBacking;
> virStorageSourceParseRBDColonString;
> virStorageSourcePoolDefFree;
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index 8c05786..0d27ca6 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
> @@ -1808,6 +1808,33 @@ virStorageSourcePoolDefCopy(const
> virStorageSourcePoolDef *src)
> return NULL;
> }
>
> +/**
> + * virStorageSourceIsRAID:
> + * return true if the backingStores field inside @src is use
> + * as a child of a contener
> + */
> +bool virStorageSourceIsRAID(virStorageSourcePtr src)
> +{
> +virStorageType type;
> +
> +if (!src)
> +return false;
> +type = virStorageSourceGetActualType(src);
> +switch (type) {
> +case VIR_STORAGE_TYPE_NONE:
> +case VIR_STORAGE_TYPE_FILE:
> +case VIR_STORAGE_TYPE_BLOCK:
> +case VIR_STORAGE_TYPE_DIR:
> +case VIR_STORAGE_TYPE_NETWORK:
> +case VIR_STORAGE_TYPE_VOLUME:
> +case VIR_STORAGE_TYPE_LAST:
> +return false;
> +
> +case VIR_STORAGE_TYPE_QUORUM:
This isn't defined until patch 7...
John
I'm going to stop here, but since I saw this as well I figured I'd note
it. Each patch needs to be compilable and bisectable.
> +return true;
> +}
> +return false;
> +}
>
> /**
> * virStorageSourceGetBackingStore:
> diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h
> index 290c20f..68a21d0 100644
> --- a/src/util/virstoragefile.h
> +++ b/src/util/virstoragefile.h
> @@ -290,6 +290,8 @@ struct _virStorageSource {
> # define DEV_BSIZE 512
> # endif
>
> +bool virStorageSourceIsRAID(virStorageSourcePtr src);
> +
> int virStorageSourceSetBackingStore(virStorageSourcePtr src,
> virStorageSourcePtr backingStore,
> size_t pos);
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v7 04/13] virstoragefile: Always use virStorageSourceSetBackingStore to set backing store
On 12/03/2015 09:35 AM, Matthias Gatto wrote:
> Replace the parts of the code where a backing store is set manually
> with virStorageSourceSetBackingStore
>
> Signed-off-by: Matthias Gatto
> Signed-off-by: John Ferlan
> ---
> src/conf/domain_conf.c| 3 ++-
> src/conf/storage_conf.c | 17 ++---
> src/qemu/qemu_driver.c| 17 +++--
> src/storage/storage_backend_fs.c | 7 +--
> src/storage/storage_backend_gluster.c | 5 +++--
> src/storage/storage_backend_logical.c | 5 +++--
> src/storage/storage_driver.c | 3 ++-
> src/util/virstoragefile.c | 8 +---
> tests/virstoragetest.c| 4 ++--
> 9 files changed, 43 insertions(+), 26 deletions(-)
>
Upstream changes and changes from/for patch 2 make this even more
difficult. Rather than hit every change required and in order to make
some progress, it's perhaps easier to repost patches 1-5 and get them
accepted/upstream first. Then focus on the rest afterwards.
I'll cobble together something - it'll differ slightly from what's here.
John
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 5b413b5..d146811 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -6359,7 +6359,8 @@ virDomainDiskBackingStoreParse(xmlXPathContextPtr ctxt,
> virDomainDiskBackingStoreParse(ctxt, backingStore) < 0)
> goto cleanup;
>
> -src->backingStore = backingStore;
> +if (virStorageSourceSetBackingStore(src, backingStore, 0) < 0)
> +goto cleanup;
> ret = 0;
>
> cleanup:
> diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
> index d048e39..b9db5eb 100644
> --- a/src/conf/storage_conf.c
> +++ b/src/conf/storage_conf.c
> @@ -1259,6 +1259,7 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
> char *capacity = NULL;
> char *unit = NULL;
> char *backingStore = NULL;
> +virStorageSourcePtr backingStorePtr;
> xmlNodePtr node;
> xmlNodePtr *nodes = NULL;
> size_t i;
> @@ -1295,20 +1296,22 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
> }
>
> if ((backingStore = virXPathString("string(./backingStore/path)",
> ctxt))) {
> -if (VIR_ALLOC(ret->target.backingStore) < 0)
> +if (VIR_ALLOC(backingStorePtr) < 0)
> goto error;
>
> -ret->target.backingStore->path = backingStore;
> +if (virStorageSourceSetBackingStore(&ret->target, backingStorePtr,
> 0) < 0)
> +goto error;
> +backingStorePtr->path = backingStore;
> backingStore = NULL;
>
> if (options->formatFromString) {
> char *format =
> virXPathString("string(./backingStore/format/@type)", ctxt);
> if (format == NULL)
> -ret->target.backingStore->format = options->defaultFormat;
> +backingStorePtr->format = options->defaultFormat;
> else
> -ret->target.backingStore->format =
> (options->formatFromString)(format);
> +backingStorePtr->format =
> (options->formatFromString)(format);
>
> -if (ret->target.backingStore->format < 0) {
> +if (backingStorePtr->format < 0) {
> virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> _("unknown volume format type %s"), format);
> VIR_FREE(format);
> @@ -1317,9 +1320,9 @@ virStorageVolDefParseXML(virStoragePoolDefPtr pool,
> VIR_FREE(format);
> }
>
> -if (VIR_ALLOC(ret->target.backingStore->perms) < 0)
> +if (VIR_ALLOC(backingStorePtr->perms) < 0)
> goto error;
> -if (virStorageDefParsePerms(ctxt, ret->target.backingStore->perms,
> +if (virStorageDefParsePerms(ctxt, backingStorePtr->perms,
> "./backingStore/permissions") < 0)
> goto error;
> }
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 8ba7566..edfd8e6 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -14261,13 +14261,18 @@
> qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
> /* Update vm in place to match changes. */
> need_unlink = false;
>
> -newDiskSrc->backingStore = disk->src;
> -disk->src = newDiskSrc;
> +if (virStorageSourceSetBackingStore(newDiskSrc, disk->src, 0) < 0) {
> +ret = -1;
> +goto cleanup;
> +}
> newDiskSrc = NULL;
>
> if (persistDisk) {
> -persistDiskSrc->backingStore = persistDisk->src;
> -persistDisk->src = persistDiskSrc;
> +if (virStorageSourceSetBackingStore(persistDiskSrc,
> +persistDisk->src, 0) < 0) {
> +ret = -1;
> +goto cleanup;
> +}
> persistDiskSrc = NULL;
> }
>
> @@ -14310,13 +14315,13 @@
> qemuDomainSnapshotUndoSingle
Re: [libvirt] [PATCH v7 03/13] virstoragefile: Add virStorageSourceSetBackingStore
On 12/03/2015 09:35 AM, Matthias Gatto wrote:
> As explained for virStorageSourceGetBackingStore, quorum allows
> multiple backing store, this make the operation to set bs complex
> because we have to check if the backingStore is used as an array
> or a pointer, and set it differently in both case.
>
> In order to help the manipulation of backing store, I've added a
> function virStorageSourceSetBackingStore.
>
> For now virStorageSourceSetBackingStore don't handle the case where
> we have more than one backing store in virStorageSource.
>
> Signed-off-by: Matthias Gatto
> Signed-off-by: John Ferlan
> ---
> src/libvirt_private.syms | 1 +
> src/util/virstoragefile.c | 10 ++
> src/util/virstoragefile.h | 4
> 3 files changed, 15 insertions(+)
>
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 5354a4a..d3baee8 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -2200,6 +2200,7 @@ virStorageSourceParseRBDColonString;
> virStorageSourcePoolDefFree;
> virStorageSourcePoolModeTypeFromString;
> virStorageSourcePoolModeTypeToString;
> +virStorageSourceSetBackingStore;
> virStorageSourceUpdateBlockPhysicalSize;
> virStorageTypeFromString;
> virStorageTypeToString;
> diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c
> index af17d82..a8a2134 100644
> --- a/src/util/virstoragefile.c
> +++ b/src/util/virstoragefile.c
> @@ -1819,6 +1819,16 @@ virStorageSourceGetBackingStore(const virStorageSource
> *src,
> }
>
>
> +int
> +virStorageSourceSetBackingStore(virStorageSourcePtr src,
> +virStorageSourcePtr backingStore,
> +size_t pos ATTRIBUTE_UNUSED)
> +{
As Peter points out in v6 - there's no range checking here.
John
> +src->backingStore = backingStore;
> +return 0;
> +}
> +
> +
> /**
> * virStorageSourcePtr:
> *
> diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h
> index 8cd4854..ce1cb5d 100644
> --- a/src/util/virstoragefile.h
> +++ b/src/util/virstoragefile.h
> @@ -289,6 +289,10 @@ struct _virStorageSource {
> # define DEV_BSIZE 512
> # endif
>
> +int virStorageSourceSetBackingStore(virStorageSourcePtr src,
> +virStorageSourcePtr backingStore,
> +size_t pos);
> +
> virStorageSourcePtr virStorageSourceGetBackingStore(const virStorageSource
> *src,
> size_t pos);
>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] storage: Attempt to refresh volume after successful wipe volume
https://bugzilla.redhat.com/show_bug.cgi?id=1270709 When a volume wipe is successful, perform a volume refresh afterwards to update any volume data that may be used in future volume commands, such as volume resize. For a raw file volume, a wipe could truncate the file and a followup volume resize the capacity may fail because the volume target allocation isn't updated to reflect the wipe activity. Since the documentation doesn't mention this side effect of the zero algorithm for a raw file volume, update the various documentation to describe the results. Signed-off-by: John Ferlan --- v1: http://www.redhat.com/archives/libvir-list/2015-December/msg00085.html Changes since v1: * Use the preferred call format from review * Cause error if refreshVol fails * Add wording to docs regarding zero wipe algorithm and truncating the raw file. src/libvirt-storage.c| 9 +++-- src/storage/storage_driver.c | 9 - tools/virsh.pod | 5 + 3 files changed, 20 insertions(+), 3 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 66dd9f0..62bb999 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1725,7 +1725,9 @@ virStorageVolDelete(virStorageVolPtr vol, * @vol: pointer to storage volume * @flags: extra flags; not used yet, so callers should always pass 0 * - * Ensure data previously on a volume is not accessible to future reads + * Ensure data previously on a volume is not accessible to future reads. + * Use of this function is equivalent to calling virStorageVolWipePattern + * with the VIR_STORAGE_VOL_WIPE_ALG_ZERO for the algorithm. * * Returns 0 on success, or -1 on error */ @@ -1766,7 +1768,10 @@ virStorageVolWipe(virStorageVolPtr vol, * @flags: future flags, use 0 for now * * Similar to virStorageVolWipe, but one can choose - * between different wiping algorithms. + * between different wiping algorithms. When choosing the + * zero algorithm (VIR_STORAGE_VOL_WIPE_ALG_ZERO), it is + * possible the target storage backend will truncate the + * file rather than writing a stream of zeroes. * * Returns 0 on success, or -1 on error. */ diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index bbf21f6..2531a88 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2436,7 +2436,14 @@ storageVolWipePattern(virStorageVolPtr obj, goto cleanup; } -ret = backend->wipeVol(obj->conn, pool, vol, algorithm, flags); +if (backend->wipeVol(obj->conn, pool, vol, algorithm, flags) < 0) +goto cleanup; + +if (backend->refreshVol && +backend->refreshVol(obj->conn, pool, vol) < 0) +goto cleanup; + +ret = 0; cleanup: virStoragePoolObjUnlock(pool); diff --git a/tools/virsh.pod b/tools/virsh.pod index 21ae4a3..7f6dc8d 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -3509,6 +3509,11 @@ B B: The availability of algorithms may be limited by the version of the C binary installed on the host. +B: Use of the zero algorithm for some storage backends may result +in the truncation of the target file instead of writing all zeroes to the +file. The Storage Driver will refresh the volume allocation and capacity +after successful volume wipe completion. + =item B [I<--pool> I] I Output the volume information as an XML dump to stdout. -- 2.5.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] vf configuration cleanup when VM is delete
On 12/15/2015 01:34 PM, Laine Stump wrote: On 12/13/2015 10:51 AM, Moshe Levi wrote: Hi, I have a setup with libvirt 1.3.0 and OpenStack trunk. Before launched the VM ip link command show the following VF mac/vlan configuration [1] When I launch a VM with via openstack api (OpenStack direct port) I can see that the VF get the mac/vlan according to libvrit xml [2] and ip link command [3], but when I delete the VM the mac/vlan config are still shown as in [3] and not restored to [1] Shouldn’t libvirt restore the mac/vlan to [1]. The same problem exists when using (OpenStack macvtap port) but just for the MAC configuration of the VF. What libvirt does is to restore the MAC address to whatever it was before we set it up for use with a guest. Although there are some sriov net drivers that (for some unfathomable reason) think it's cool to assign a random MAC address to each VF at boot time, the "normal" thing is for the VFs to have a MAC address of all 0's to start with. So libvirt should be saving 00:00:00:00:00:00 (it will be in the file /var/run/libvirt/hostdevmgr/$ifname_vf$vfnum) then setting the MAC to use; when done, libvirt will read the 00:00:00:00:00:00 and use netlink to set the MAC address, but this is apparently failing. I checked on my Fedora 22 system with the igb driver, and found that if the MAC address was originally set to something other than 0's, it was restored properly by libvirt, but if it was set to all 0's originally, the attempt to set it back to 0 would fail. I then tried doing the same thing with the "ip" utility: # ip link set dev p4p2 vf 0 mac 00:00:00:00:00:00 and I get the following response: RTNETLINK answers: Invalid argument So it appears that either the kernel or the NIC driver is refusing to set the MAC address to all 0's. I'm reasonably certain this is a regression in the kernel, Sigh. It appears that this has "always" been the case - I just checked on a 2.6.32-573 RHEL kernel, and a 3.10.x RHEL7.2 kernel, and 4.1 (Fedora 22) and both of them also refuse to set the MAC address to 00:00:00:00:00:00. I'm not sure if this limitation is in the NIC driver or some basic code in the kernel. although I can't say how long it's been there, as I don't normally pay attention to this (and as I said, many SRIOV NIC drivers don't default their VFs to 0 MAC addresses) What distro and kernel are you using for your tests? [1] - 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto [2] - function='0x7'/> function='0x0'/> [3] 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC fa:16:3e:11:af:fe, vlan 190, spoof checking off, link-state enable -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list F15 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5] Fix issues with activating pool with invalid source
On 12/07/2015 03:47 PM, John Ferlan wrote: > These patches resolve issues with 'FS', 'NFS', and 'LOGICAL' pools where > if the pool source device didn't match the reality what was running on > the host there were inconsistent results. > > For the file pools, a pool would be declared 'active' after restart even > though a start would fail because the check code only cared that the device > the pool was using was mounted. Patches 3 alters the check to not only > make sure the device is mounted, but that the source for the device matches > the source used to start the pool. > > For the logical pool, a pool could be both started and declared 'active' > on restart as long as the "pool->def->source.name" was a valid volume > group on the host even though the pool's source device(s) didn't match > the same volume group. Usually the pool build process takes care of > ensuring not only that the source device exists, but matching the > device(s) to the volume group name create (via vgcreate). The reality > is pool startup never checked that the volume group name being used > by the pool matched the reality of the volume group on the host. Patch > 5 will now ensure not only startup matches the name and device list, > but that restart setting 'active' would do the same. > > John Ferlan (5): > storage: Create helper to generate FS pool source value > storage: Refactor virStorageBackendFileSystemGetPoolSource > storage: Check FS pool source during > virStorageBackendFileSystemIsMounted > storage: Create helper for virStorageBackendLogicalFindPoolSources > storage: Add helper to compare logical pool def against pvs output > > src/storage/storage_backend_fs.c | 73 - > src/storage/storage_backend_logical.c | 148 > +- > 2 files changed, 182 insertions(+), 39 deletions(-) > Adjusted patch 1 & 5 as suggested and pushed. Thanks - John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: Fix event generated for qemuDomainRevertToSnapshot (pause->run)
A closer review of the code shows that for the transition from paused to
running which was supposed to emit the VIR_DOMAIN_EVENT_RESUMED - no event
would be generated. Rather the event is generated when going from running
to running.
Following the 'was_running' boolean shows it is set when the domain obj
is active and the domain obj state is VIR_DOMAIN_RUNNING. So rather than
using was_running to generate the RESUMED event, use !was_running
Signed-off-by: John Ferlan
---
I hope I've read the bread crumbs in the code correctly regarding state
transitions! Saw this while reviewing something else:
http://www.redhat.com/archives/libvir-list/2015-December/msg00330.html
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 783a7cd..deeffc1 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15549,7 +15549,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr
snapshot,
event = virDomainEventLifecycleNewFromObj(vm,
VIR_DOMAIN_EVENT_STARTED,
detail);
-} else if (was_running) {
+} else if (!was_running) {
/* Transition 8 */
detail = VIR_DOMAIN_EVENT_RESUMED;
event = virDomainEventLifecycleNewFromObj(vm,
--
2.5.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v3] pci: Use virPCIDeviceAddress in virPCIDevice
On 12/15/2015 01:23 PM, Andrea Bolognani wrote: Instead of replicating the information (domain, bus, slot, function) inside the virPCIDevice structure, use the already-existing virPCIDeviceAddress structure. For users of the module, this means that the object returned by virPCIDeviceGetAddress() can no longer be NULL and must no longer be freed by the caller. --- Changes in v3: * don't check the return value of virPCIDeviceGetAddress(), it can no longer be NULL * don't use a variable to store the device address if it's only going to be used a single time ACK. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v3] pci: Use virPCIDeviceAddress in virPCIDevice
Instead of replicating the information (domain, bus, slot, function)
inside the virPCIDevice structure, use the already-existing
virPCIDeviceAddress structure.
For users of the module, this means that the object returned by
virPCIDeviceGetAddress() can no longer be NULL and must no longer
be freed by the caller.
---
Changes in v3:
* don't check the return value of virPCIDeviceGetAddress(), it can no
longer be NULL
* don't use a variable to store the device address if it's only going
to be used a single time
Changes in v2:
* use virPCIDeviceAddress instead of virPCIDeviceAddressPtr to avoid
extra allocations
src/util/virhostdev.c | 20 ++-
src/util/virpci.c | 97 +++
2 files changed, 47 insertions(+), 70 deletions(-)
diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c
index de029a0..4065535 100644
--- a/src/util/virhostdev.c
+++ b/src/util/virhostdev.c
@@ -585,15 +585,12 @@ virHostdevPreparePCIDevices(virHostdevManagerPtr
hostdev_mgr,
goto cleanup;
}
-VIR_FREE(devAddr);
-if (!(devAddr = virPCIDeviceGetAddress(dev)))
-goto cleanup;
-
/* The device is in use by other active domain if
* the dev is in list activePCIHostdevs. VFIO devices
* belonging to same iommu group can't be shared
* across guests.
*/
+devAddr = virPCIDeviceGetAddress(dev);
if (usesVfio) {
if (virPCIDeviceAddressIOMMUGroupIterate(devAddr,
virHostdevIsPCINodeDeviceUsed,
@@ -728,7 +725,6 @@ virHostdevPreparePCIDevices(virHostdevManagerPtr
hostdev_mgr,
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnref(pcidevs);
-VIR_FREE(devAddr);
return ret;
}
@@ -1558,7 +1554,6 @@ int
virHostdevPCINodeDeviceDetach(virHostdevManagerPtr hostdev_mgr,
virPCIDevicePtr pci)
{
-virPCIDeviceAddressPtr devAddr = NULL;
struct virHostdevIsPCINodeDeviceUsedData data = { hostdev_mgr, NULL,
false };
int ret = -1;
@@ -1566,10 +1561,7 @@ virHostdevPCINodeDeviceDetach(virHostdevManagerPtr
hostdev_mgr,
virObjectLock(hostdev_mgr->activePCIHostdevs);
virObjectLock(hostdev_mgr->inactivePCIHostdevs);
-if (!(devAddr = virPCIDeviceGetAddress(pci)))
-goto out;
-
-if (virHostdevIsPCINodeDeviceUsed(devAddr, &data))
+if (virHostdevIsPCINodeDeviceUsed(virPCIDeviceGetAddress(pci), &data))
goto out;
if (virPCIDeviceDetach(pci, hostdev_mgr->activePCIHostdevs,
@@ -1581,7 +1573,6 @@ virHostdevPCINodeDeviceDetach(virHostdevManagerPtr
hostdev_mgr,
out:
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
-VIR_FREE(devAddr);
return ret;
}
@@ -1589,7 +1580,6 @@ int
virHostdevPCINodeDeviceReAttach(virHostdevManagerPtr hostdev_mgr,
virPCIDevicePtr pci)
{
-virPCIDeviceAddressPtr devAddr = NULL;
struct virHostdevIsPCINodeDeviceUsedData data = {hostdev_mgr, NULL,
false};
int ret = -1;
@@ -1597,10 +1587,7 @@ virHostdevPCINodeDeviceReAttach(virHostdevManagerPtr
hostdev_mgr,
virObjectLock(hostdev_mgr->activePCIHostdevs);
virObjectLock(hostdev_mgr->inactivePCIHostdevs);
-if (!(devAddr = virPCIDeviceGetAddress(pci)))
-goto out;
-
-if (virHostdevIsPCINodeDeviceUsed(devAddr, &data))
+if (virHostdevIsPCINodeDeviceUsed(virPCIDeviceGetAddress(pci), &data))
goto out;
virPCIDeviceReattachInit(pci);
@@ -1613,7 +1600,6 @@ virHostdevPCINodeDeviceReAttach(virHostdevManagerPtr
hostdev_mgr,
out:
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
-VIR_FREE(devAddr);
return ret;
}
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 7ca3fef..6f0cb8c 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -56,10 +56,7 @@ VIR_ENUM_IMPL(virPCIELinkSpeed, VIR_PCIE_LINK_SPEED_LAST,
"", "2.5", "5", "8")
struct _virPCIDevice {
-unsigned int domain;
-unsigned int bus;
-unsigned int slot;
-unsigned int function;
+virPCIDeviceAddress address;
char name[PCI_ADDR_LEN]; /* domain:bus:slot.function */
char id[PCI_ID_LEN]; /* product vendor */
@@ -655,10 +652,10 @@ virPCIDeviceSharesBusWithActive(virPCIDevicePtr dev,
virPCIDevicePtr check, void
virPCIDeviceList *inactiveDevs = data;
/* Different domain, different bus, or simply identical device */
-if (dev->domain != check->domain ||
-dev->bus != check->bus ||
-(dev->slot == check->slot &&
- dev->function == check->function))
+if (dev->address.domain != ch
Re: [libvirt] ARM KVM GICv3 Support
Hi, On 15/12/15 16:42, Peter Maydell wrote: > On 15 December 2015 at 16:35, Andrew Jones wrote: >> This is probably good for guests that happy with both. Guests that >> need/want a specific choice will put their integer there, and then >> we need a way to do a capabilities check before launching that guest >> on an arbitrary host. > > OK, so how do we typically do that? I notice I have a 'kvm-ok' > script on my machine which helpfully reports things like whether > KVM is enabled, and it seems like it might be helpful to extend > that to know a bit more about ARM hosts. But I'm guessing libvirt > doesn't use that for its capability checking ? Even that wouldn't help us, I guess, as you cannot easily check for GICv3/GICv2 compatibility with a _script_. Having access to ioctl's make this pretty easy though: Just try to call KVM_CREATE_DEVICE with the proper type and get -ENODEV if this one is not supported. This can be done without any extra userland tool by just executing some ioctls on /dev/kvm (from C or using some helper library). Does adding such a check to libvirt sounds feasible? Cheers, Andre. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] pci: Use virPCIDeviceAddress in virPCIDevice
On Tue, 2015-12-15 at 12:27 -0500, Laine Stump wrote: > On 12/15/2015 05:48 AM, Andrea Bolognani wrote: > > On Tue, 2015-12-15 at 10:05 +0100, Andrea Bolognani wrote: > > > @@ -1661,25 +1661,14 @@ virPCIDeviceFree(virPCIDevicePtr dev) > > > * @dev: device to get address from > > > * > > > * Take a PCI device on input and return its PCI address. The > > > - * caller must free the returned value when no longer needed. > > > + * returned object is owned by the device and must not be freed. > > > * > > > * Returns NULL on failure, the device address on success. > > > */ > > Not sending a v3 just for this, but if ACKed I'll also squash in > > > > - * Returns NULL on failure, the device address on success. > > + * Returns: a pointer to the address, which can never be NULL. > > > > to keep the documentation consistent with the actual behaviour. > > Also, the places where this is called no longer need to check for NULL > and goto cleanup. And beyond that, 2 of the three callers only use the > returned value a single time, so the code could be shortened even > further by just using "virPCIDeviceGetAddress(blah)" directly, instead > of placing that return value into a local, and then calling using the > local a single time later. > > ACK for the whole patch as long as you remove the check for NULL from > all the callers of virPCIDeviceGetAddress() (and optionally eliminate > the temporary variable in the two cases where it is used only once). v3 here: https://www.redhat.com/archives/libvir-list/2015-December/msg00601.html Hopefully I haven't made any silly mistakes this time :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] vf configuration cleanup when VM is delete
On 12/13/2015 10:51 AM, Moshe Levi wrote: Hi, I have a setup with libvirt 1.3.0 and OpenStack trunk. Before launched the VM ip link command show the following VF mac/vlan configuration [1] When I launch a VM with via openstack api (OpenStack direct port) I can see that the VF get the mac/vlan according to libvrit xml [2] and ip link command [3], but when I delete the VM the mac/vlan config are still shown as in [3] and not restored to [1] Shouldn’t libvirt restore the mac/vlan to [1]. The same problem exists when using (OpenStack macvtap port) but just for the MAC configuration of the VF. What libvirt does is to restore the MAC address to whatever it was before we set it up for use with a guest. Although there are some sriov net drivers that (for some unfathomable reason) think it's cool to assign a random MAC address to each VF at boot time, the "normal" thing is for the VFs to have a MAC address of all 0's to start with. So libvirt should be saving 00:00:00:00:00:00 (it will be in the file /var/run/libvirt/hostdevmgr/$ifname_vf$vfnum) then setting the MAC to use; when done, libvirt will read the 00:00:00:00:00:00 and use netlink to set the MAC address, but this is apparently failing. I checked on my Fedora 22 system with the igb driver, and found that if the MAC address was originally set to something other than 0's, it was restored properly by libvirt, but if it was set to all 0's originally, the attempt to set it back to 0 would fail. I then tried doing the same thing with the "ip" utility: # ip link set dev p4p2 vf 0 mac 00:00:00:00:00:00 and I get the following response: RTNETLINK answers: Invalid argument So it appears that either the kernel or the NIC driver is refusing to set the MAC address to all 0's. I'm reasonably certain this is a regression in the kernel, although I can't say how long it's been there, as I don't normally pay attention to this (and as I said, many SRIOV NIC drivers don't default their VFs to 0 MAC addresses) What distro and kernel are you using for your tests? [1] - 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto [2] - function='0x7'/> function='0x0'/> [3] 24: enp3s0f0: mtu 1500 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000 link/ether e4:1d:2d:a5:f1:22 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto vf 3 MAC fa:16:3e:11:af:fe, vlan 190, spoof checking off, link-state enable -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list F15 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] pci: Use virPCIDeviceAddress in virPCIDevice
On 12/15/2015 05:48 AM, Andrea Bolognani wrote: On Tue, 2015-12-15 at 10:05 +0100, Andrea Bolognani wrote: @@ -1661,25 +1661,14 @@ virPCIDeviceFree(virPCIDevicePtr dev) * @dev: device to get address from * * Take a PCI device on input and return its PCI address. The - * caller must free the returned value when no longer needed. + * returned object is owned by the device and must not be freed. * * Returns NULL on failure, the device address on success. */ Not sending a v3 just for this, but if ACKed I'll also squash in - * Returns NULL on failure, the device address on success. + * Returns: a pointer to the address, which can never be NULL. to keep the documentation consistent with the actual behaviour. Also, the places where this is called no longer need to check for NULL and goto cleanup. And beyond that, 2 of the three callers only use the returned value a single time, so the code could be shortened even further by just using "virPCIDeviceGetAddress(blah)" directly, instead of placing that return value into a local, and then calling using the local a single time later. ACK for the whole patch as long as you remove the check for NULL from all the callers of virPCIDeviceGetAddress() (and optionally eliminate the temporary variable in the two cases where it is used only once). -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 15 December 2015 at 16:57, Andre Przywara wrote: > Even that wouldn't help us, I guess, as you cannot easily check for > GICv3/GICv2 compatibility with a _script_. Having access to ioctl's make > this pretty easy though: Just try to call KVM_CREATE_DEVICE with the > proper type and get -ENODEV if this one is not supported. This can be > done without any extra userland tool by just executing some ioctls on > /dev/kvm (from C or using some helper library). kvm-ok already runs a few external helper binaries for some things. (Also you can do ioctls from a script if it's a perl script ;-)) As you say the actual technical details of how to query for the host's current supported functionality are straightforward, so it's just a question of how libvirt is expecting that to be exposed to it. thanks -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, Dec 15, 2015 at 05:53:43PM +0100, Andrea Bolognani wrote: > On Tue, 2015-12-15 at 10:35 -0600, Andrew Jones wrote: > > On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote: > > > On 15 December 2015 at 14:12, Martin Kletzander > > > wrote: > > > > On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: > > > > > > > > > > On 15 December 2015 at 09:36, Martin Kletzander > > > > > wrote: > > > > > > > > > > > > We do pass some options, for example, you can restrict the GIC to > > > > > > v2: > > > > > > https://libvirt.org/formatdomain.html#elementsFeatures > > > > > > > > > > > > That could be modified to work for your purpose IIUC, right? > > > > > > > > > > > > > > > What does that option do to the QEMU command line? The documentation > > > > > doesn't seem to say. > > > > > > > > > > > > > It appends gic-version= to the machine option, if bunch of conditions > > > > are met -- it has to be ARM machine, it has to be something else than > > > > version 2, and so on, more details are visible in the code and I won't > > > > cover them here. I hope that's understandable. > > > > > > OK. So it should be sufficient just to have > > > > > > which will then provide whatever VGIC the host machine can do with > > > hardware acceleration. > > > > This is probably good for guests that happy with both. Guests that > > need/want a specific choice will put their integer there, and then > > we need a way to do a capabilities check before launching that guest > > on an arbitrary host. > > That won't work at the moment since we're expecting the value to be a > number, but extending it so that 'host' is accepted as well should be > easy to do in a backwards-compatible way. > > The behaviour of the value '2' has been defined as "don't specify any > GIC version" though, and I'm afraid we'll be unable to change that > because it would affect existing guests. Martin can probably weigh in. > > Having a way for libvirt to know what values can be used on the specific > machines it's running on it's another topic altogether - is there a good > way to detect it? Is that based on the hardware, on the QEMU binary, on > the machine type? My understanding of libvirt host feature probing is that it generally queries QEMU, rather than the host directly. QEMU using Andre's ioctl test, when asked with QEMU's command line using some '\?' type of input, seems like the typical approach to me. Thanks, drew -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, Dec 15, 2015 at 04:42:13PM +, Peter Maydell wrote: > On 15 December 2015 at 16:35, Andrew Jones wrote: > > This is probably good for guests that happy with both. Guests that > > need/want a specific choice will put their integer there, and then > > we need a way to do a capabilities check before launching that guest > > on an arbitrary host. > > OK, so how do we typically do that? I notice I have a 'kvm-ok' > script on my machine which helpfully reports things like whether > KVM is enabled, and it seems like it might be helpful to extend > that to know a bit more about ARM hosts. But I'm guessing libvirt > doesn't use that for its capability checking ? I defer to our libvirt experts. I'm suspicious that we'll need libvirt changes though, as my experience with libvirt capabilities has always been for cpu features, not machine model features, and thus I'm not sure there's support for the later yet. Thanks, drew -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 12/15/2015 11:53 AM, Andrea Bolognani wrote:
> On Tue, 2015-12-15 at 10:35 -0600, Andrew Jones wrote:
>> On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote:
>>> On 15 December 2015 at 14:12, Martin Kletzander wrote:
On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote:
>
> On 15 December 2015 at 09:36, Martin Kletzander
> wrote:
>>
>> We do pass some options, for example, you can restrict the GIC to v2:
>> https://libvirt.org/formatdomain.html#elementsFeatures
>>
>> That could be modified to work for your purpose IIUC, right?
>
>
> What does that option do to the QEMU command line? The documentation
> doesn't seem to say.
>
It appends gic-version= to the machine option, if bunch of conditions
are met -- it has to be ARM machine, it has to be something else than
version 2, and so on, more details are visible in the code and I won't
cover them here. I hope that's understandable.
>>>
>>> OK. So it should be sufficient just to have
>>>
>>> which will then provide whatever VGIC the host machine can do with
>>> hardware acceleration.
>>
>> This is probably good for guests that happy with both. Guests that
>> need/want a specific choice will put their integer there, and then
>> we need a way to do a capabilities check before launching that guest
>> on an arbitrary host.
>
> That won't work at the moment since we're expecting the value to be a
> number, but extending it so that 'host' is accepted as well should be
> easy to do in a backwards-compatible way.
>
> The behaviour of the value '2' has been defined as "don't specify any
> GIC version" though, and I'm afraid we'll be unable to change that
> because it would affect existing guests. Martin can probably weigh in.
>
> Having a way for libvirt to know what values can be used on the specific
> machines it's running on it's another topic altogether - is there a good
> way to detect it? Is that based on the hardware, on the QEMU binary, on
> the machine type?
>
If one digs into the qemu_command code though they would find that if
"" were supplied in the domain XML without the version='#', then we
don't generate the command line option with any "gic*" string.
qemuBuildMachineArgStr()
if (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON) {
if (def->gic_version) {
...
virBufferAsprintf(&buf, ",gic-version=%d", def->gic_version);
}
}
Perhaps the "else" to (def->gic_version) could be "gic-version=host".
Would that suffice? or be the right thing to do?
John
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 15 December 2015 at 16:53, Andrea Bolognani wrote: > The behaviour of the value '2' has been defined as "don't specify any > GIC version" though, and I'm afraid we'll be unable to change that > because it would affect existing guests. Martin can probably weigh in. QEMU also treats "nothing specified" as meaning "2", at least for the virt board, so that part is fine. (The option is board specific anyway.) -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 15 December 2015 at 16:35, Andrew Jones wrote: > This is probably good for guests that happy with both. Guests that > need/want a specific choice will put their integer there, and then > we need a way to do a capabilities check before launching that guest > on an arbitrary host. OK, so how do we typically do that? I notice I have a 'kvm-ok' script on my machine which helpfully reports things like whether KVM is enabled, and it seems like it might be helpful to extend that to know a bit more about ARM hosts. But I'm guessing libvirt doesn't use that for its capability checking ? thanks -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, 2015-12-15 at 10:35 -0600, Andrew Jones wrote: > On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote: > > On 15 December 2015 at 14:12, Martin Kletzander wrote: > > > On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: > > > > > > > > On 15 December 2015 at 09:36, Martin Kletzander > > > > wrote: > > > > > > > > > > We do pass some options, for example, you can restrict the GIC to v2: > > > > > https://libvirt.org/formatdomain.html#elementsFeatures > > > > > > > > > > That could be modified to work for your purpose IIUC, right? > > > > > > > > > > > > What does that option do to the QEMU command line? The documentation > > > > doesn't seem to say. > > > > > > > > > > It appends gic-version= to the machine option, if bunch of conditions > > > are met -- it has to be ARM machine, it has to be something else than > > > version 2, and so on, more details are visible in the code and I won't > > > cover them here. I hope that's understandable. > > > > OK. So it should be sufficient just to have > > > > which will then provide whatever VGIC the host machine can do with > > hardware acceleration. > > This is probably good for guests that happy with both. Guests that > need/want a specific choice will put their integer there, and then > we need a way to do a capabilities check before launching that guest > on an arbitrary host. That won't work at the moment since we're expecting the value to be a number, but extending it so that 'host' is accepted as well should be easy to do in a backwards-compatible way. The behaviour of the value '2' has been defined as "don't specify any GIC version" though, and I'm afraid we'll be unable to change that because it would affect existing guests. Martin can probably weigh in. Having a way for libvirt to know what values can be used on the specific machines it's running on it's another topic altogether - is there a good way to detect it? Is that based on the hardware, on the QEMU binary, on the machine type? Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: emit 'defined' event after reverted to snapshot
On 12/15/2015 04:00 AM, Dmitry Andreev wrote:
>
>
> On 14.12.2015 23:10, John Ferlan wrote:
>>
>>
>> On 12/09/2015 03:29 AM, Dmitry Andreev wrote:
>>> Config file is changed. VIR_DOMAIN_EVENT_DEFINED should be emitted
>>> ---
>>> src/qemu/qemu_driver.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>>> index ae1d8e7..b32172a 100644
>>> --- a/src/qemu/qemu_driver.c
>>> +++ b/src/qemu/qemu_driver.c
>>> @@ -15293,6 +15293,7 @@
>>> qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
>>> virDomainSnapshotObjPtr snap = NULL;
>>> virObjectEventPtr event = NULL;
>>> virObjectEventPtr event2 = NULL;
>>> +virObjectEventPtr define_event = NULL;
>>> int detail;
>>> qemuDomainObjPrivatePtr priv;
>>> int rc;
>>> @@ -15401,6 +15402,9 @@
>>> qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
>>> config = virDomainDefCopy(snap->def->dom, caps,
>>> driver->xmlopt, true);
>>> if (!config)
>>> goto endjob;
>>> +define_event = virDomainEventLifecycleNewFromObj(vm,
>>> + VIR_DOMAIN_EVENT_DEFINED,
>>> +
>>> VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT);
>>> }
>>>
>>> switch ((virDomainState) snap->def->state) {
>>> @@ -15627,6 +15631,7 @@
>>> qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot,
>>> } else if (snap) {
>>> snap->def->current = false;
>>> }
>>> +qemuDomainEventQueue(driver, define_event);
>>
>> I think this can go right after the generation of the event. That way it
>> can come "in order"...
>>
>> Following the rest of the logic, event can be queued as it happens and
>> then "reused" in a few instances prior to event2 being generated. Then
>> at cleanup the most recent event and event2 get queued.
>
> As I can see from the code - 'stopped' event is the only event that is
> queued as it happens. The VM state is changed to STOPPED inside the
> switch for few cases. If you queue the 'defined' event before the
> switch (or right after the generation) the order will be 'defined' ->
> 'stopped' -> event -> event2 when the natural order is 'stopped' before
> 'defined'.
>
> API client will get 'defined' event for VM with cached running state
> before you send him 'stopped' event.
>
hmm... true. Following the transitions is a bit of a challenge. Not part
of this issue, but I think there's also a bug in there now. I'll send a
different patch on that...
As for this new event, I think there is an odd path after the comment
about transitions 1, 4, 7, where the STOP event is created, but before
the "if (config)", we goto cleanup where the DEFINED event could be
generated before the STOP event gets queued, but the redefinition never
occurs.
So, I think perhaps, prior to the "goto cleanup;" there could be
virObjectUnref(define_event); define_event = NULL; similar to what
happens in the code after the comments about transitions 2, 5, 8 when
the event is cleared.
Alternatively, whenever there is:
if (config)
virDomainObjAssignDef(...)
that's when the "define_event" could be queued, especially since once
that ObjAssignDef code runs - regardless of what other paths are taken
in the code, the domain is redefined.
John
>>
>> If you're OK with me moving that, then I can do so and push the two
>> patches.
>>
>> John
>>> if (event) {
>>> qemuDomainEventQueue(driver, event);
>>> qemuDomainEventQueue(driver, event2);
>>>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, Dec 15, 2015 at 04:03:13PM +, Peter Maydell wrote: > On 15 December 2015 at 14:12, Martin Kletzander wrote: > > On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: > >> > >> On 15 December 2015 at 09:36, Martin Kletzander > >> wrote: > >>> > >>> We do pass some options, for example, you can restrict the GIC to v2: > >>> https://libvirt.org/formatdomain.html#elementsFeatures > >>> > >>> That could be modified to work for your purpose IIUC, right? > >> > >> > >> What does that option do to the QEMU command line? The documentation > >> doesn't seem to say. > >> > > > > It appends gic-version= to the machine option, if bunch of conditions > > are met -- it has to be ARM machine, it has to be something else than > > version 2, and so on, more details are visible in the code and I won't > > cover them here. I hope that's understandable. > > OK. So it should be sufficient just to have > > which will then provide whatever VGIC the host machine can do with > hardware acceleration. This is probably good for guests that happy with both. Guests that need/want a specific choice will put their integer there, and then we need a way to do a capabilities check before launching that guest on an arbitrary host. drew -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt qcow2 internal snapshot without vm state
2015-12-15 10:21 GMT+03:00 Peter Krempa : > You could possibly do that with 'blockdev-snapshot-internal-sync', but > libvirt doesn't support that yet. Internal snapshots are always with > memory state if the VM is online at the time the snapshot is taken. Thanks! May be this is question on wrong list, but do you know - does it possible to run qemu with -loadvm xxx param with disk only snapshot? Does it try to boot kernel like normal boot? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 15 December 2015 at 14:12, Martin Kletzander wrote: > On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: >> >> On 15 December 2015 at 09:36, Martin Kletzander >> wrote: >>> >>> We do pass some options, for example, you can restrict the GIC to v2: >>> https://libvirt.org/formatdomain.html#elementsFeatures >>> >>> That could be modified to work for your purpose IIUC, right? >> >> >> What does that option do to the QEMU command line? The documentation >> doesn't seem to say. >> > > It appends gic-version= to the machine option, if bunch of conditions > are met -- it has to be ARM machine, it has to be something else than > version 2, and so on, more details are visible in the code and I won't > cover them here. I hope that's understandable. OK. So it should be sufficient just to have which will then provide whatever VGIC the host machine can do with hardware acceleration. thanks -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/5] storage: Check FS pool source during virStorageBackendFileSystemIsMounted
On 07.12.2015 21:47, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1025230
>
> When determining whether a FS pool is mounted, rather than assuming that
> the FS pool is mounted just because the target.path is in the mount list,
> let's make sure that the FS pool source matches what is mounted
>
> Signed-off-by: John Ferlan
> ---
> src/storage/storage_backend_fs.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/storage/storage_backend_fs.c
> b/src/storage/storage_backend_fs.c
> index 1dd5727..70e6be6 100644
> --- a/src/storage/storage_backend_fs.c
> +++ b/src/storage/storage_backend_fs.c
> @@ -419,6 +419,7 @@ static int
> virStorageBackendFileSystemIsMounted(virStoragePoolObjPtr pool)
> {
> int ret = -1;
> +char *src = NULL;
> FILE *mtab;
> struct mntent ent;
> char buf[1024];
> @@ -431,16 +432,23 @@
> virStorageBackendFileSystemIsMounted(virStoragePoolObjPtr pool)
> }
>
> while ((getmntent_r(mtab, &ent, buf, sizeof(buf))) != NULL) {
> -if (STREQ(ent.mnt_dir, pool->def->target.path)) {
> +if (!(src = virStorageBackendFileSystemGetPoolSource(pool)))
> +goto cleanup;
> +
> +if (STREQ(ent.mnt_dir, pool->def->target.path) &&
> +STREQ(ent.mnt_fsname, src)) {
> ret = 1;
> goto cleanup;
> }
> +
> +VIR_FREE(src);
> }
>
> ret = 0;
>
> cleanup:
> VIR_FORCE_FCLOSE(mtab);
> +VIR_FREE(src);
> return ret;
> }
>
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 5/5] storage: Add helper to compare logical pool def against pvs output
On 07.12.2015 21:47, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1025230
>
> Add a new helper virStorageBackendLogicalMatchPoolSource to compare the
> pool's source name against the output from a 'pvs' command to list all
> volume group physical volume data on the host. In addition, compare the
> pool's source device list against the particular volume group's device
> list to ensure the source device(s) listed for the pool match what the
> was listed for the volume group.
>
> Then for pool startup or check API's we need to call this new API in
> order to ensure that the pool we're about to start or declare active
> during checkPool has a valid definition vs. the running host.
>
> Signed-off-by: John Ferlan
> ---
> src/storage/storage_backend_logical.c | 96
> ++-
> 1 file changed, 94 insertions(+), 2 deletions(-)
>
> diff --git a/src/storage/storage_backend_logical.c
> b/src/storage/storage_backend_logical.c
> index 53ba983..6dea9d2 100644
> --- a/src/storage/storage_backend_logical.c
> +++ b/src/storage/storage_backend_logical.c
> @@ -498,11 +498,99 @@ virStorageBackendLogicalFindPoolSources(virConnectPtr
> conn ATTRIBUTE_UNUSED,
> }
>
>
> +/*
> + * virStorageBackendLogicalMatchPoolSource
> + * @pool: Pointer to the source pool object
> + *
> + * Search the output generated by a 'pvs --noheadings -o pv_name,vg_name'
> + * to match the 'vg_name' with the pool def->source.name and for the list
> + * of pool def->source.devices[].
> + *
> + * Returns true if the volume group name matches the pool's source.name
> + * and at least one of the pool's def->source.devices[] matches the
> + * list of physical device names listed for the pool. Return false if
> + * we cannot find a matching volume group name and if we cannot match
> + * the any device list members.
> + */
> +static bool
> +virStorageBackendLogicalMatchPoolSource(virStoragePoolObjPtr pool)
> +{
> +virStoragePoolSourceList sourceList;
> +virStoragePoolSource *thisSource;
> +size_t i, j;
> +int matchcount = 0;
> +bool ret = false;
> +
> +memset(&sourceList, 0, sizeof(sourceList));
> +sourceList.type = VIR_STORAGE_POOL_LOGICAL;
> +
> +if (virStorageBackendLogicalGetPoolSources(&sourceList) < 0)
> +goto cleanup;
> +
> +/* Search the pvs output for this pool's source.name */
> +for (i = 0; i < sourceList.nsources; i++) {
> +thisSource = &sourceList.sources[i];
> +if (STREQ(thisSource->name, pool->def->source.name))
> +break;
> +}
> +
> +if (i == sourceList.nsources) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> + _("cannot find logical volume group name '%s'"),
> + pool->def->source.name);
> +goto cleanup;
> +}
> +
> +/* Let's make sure the pool's device(s) match what the pvs output has
> + * for volume group devices.
> + */
> +for (i = 0; i < pool->def->source.ndevice; i++) {
> +for (j = 0; j < thisSource->ndevice; j++) {
> +if (STREQ(pool->def->source.devices[i].path,
> + thisSource->devices[j].path))
> +matchcount++;
> +}
> +}
> +
> +/* If we didn't find any matches, then this pool has listed (a) source
> + * device path(s) that don't/doesn't match what was created for the pool
> + */
> +if (matchcount == 0) {
> +virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> + _("cannot find any matching source devices for
> logical "
> + "volume group '%s'"), pool->def->source.name);
> +goto cleanup;
> +}
> +
> +/* Either there's more devices in the pool source device list or there's
> + * more devices in the pvs output. Could easily happen if someone decides
> + * to 'add' to or 'remove' from the volume group outside of libvirt's
> + * knowledge. Rather than fail on that, provide a warning and move on.
> + */
> +if (matchcount != pool->def->source.ndevice)
> +VIR_WARN("pool device list count doesn't match pvs device list
> count");
> +
> +ret = true;
> +
> + cleanup:
> +for (i = 0; i < sourceList.nsources; i++)
> +virStoragePoolSourceClear(&sourceList.sources[i]);
> +VIR_FREE(sourceList.sources);
> +
> +return ret;
> +}
> +
> +
> static int
> virStorageBackendLogicalCheckPool(virStoragePoolObjPtr pool,
>bool *isActive)
> {
> -*isActive = virFileExists(pool->def->target.path);
> +/* If we can find the target.path as well as ensure that the
> + * pool's def source
> + */
> +if (virFileExists(pool->def->target.path) &&
> +virStorageBackendLogicalMatchPoolSource(pool))
> +*isActive = true;
missing 'else *isActive = false;';
or just use *isActive = virFileExists() &&
virStorageBackendLogicalMatchPoolSource();
We should not rely on chance that caller sets isAct
Re: [libvirt] [PATCH 1/5] storage: Create helper to generate FS pool source value
On 07.12.2015 21:47, John Ferlan wrote:
> Refactor the code that builds the pool source string during the FS
> storage pool mount to be a separate helper.
>
> A future patch will use the helper in order to validate the mounted
> FS matches the pool's expectation during poolCheck processing
>
> Signed-off-by: John Ferlan
> ---
> src/storage/storage_backend_fs.c | 51
> +++-
> 1 file changed, 35 insertions(+), 16 deletions(-)
>
> diff --git a/src/storage/storage_backend_fs.c
> b/src/storage/storage_backend_fs.c
> index 99ea394..ef1a7d0 100644
> --- a/src/storage/storage_backend_fs.c
> +++ b/src/storage/storage_backend_fs.c
> @@ -375,6 +375,39 @@ virStorageBackendFileSystemIsValid(virStoragePoolObjPtr
> pool)
> return 0;
> }
>
> +
> +/**
> + * virStorageBackendFileSystemGetPoolSource
> + * @pool: storage pool object pointer
> + *
> + * Allocate/return a string representing the FS storage pool source.
> + * It is up to the caller to VIR_FREE the allocated string
> + */
> +static char *
> +virStorageBackendFileSystemGetPoolSource(virStoragePoolObjPtr pool)
> +{
> +char *src = NULL;
> +
> +if (pool->def->type == VIR_STORAGE_POOL_NETFS) {
> +if (pool->def->source.format == VIR_STORAGE_POOL_NETFS_CIFS) {
> +if (virAsprintf(&src, "//%s/%s",
> +pool->def->source.hosts[0].name,
> +pool->def->source.dir) == -1)
> +return NULL;
When touching this, I'd s/== -1/< 0/. Then, these if()-s seem a bit
useless - if virAsprintf() fails, @src is going to be NULL anyway.
Your call if you want to do ignore_value(virAsprintf(...));
> +} else {
> +if (virAsprintf(&src, "%s:%s",
> +pool->def->source.hosts[0].name,
> +pool->def->source.dir) == -1)
> +return NULL;
> +}
> +} else {
> +if (VIR_STRDUP(src, pool->def->source.devices[0].path) < 0)
> +return NULL;
> +}
> +return src;
> +}
> +
> +
> /**
> * @pool storage pool to check for status
> *
> @@ -445,22 +478,8 @@ virStorageBackendFileSystemMount(virStoragePoolObjPtr
> pool)
> return -1;
> }
>
> -if (pool->def->type == VIR_STORAGE_POOL_NETFS) {
> -if (pool->def->source.format == VIR_STORAGE_POOL_NETFS_CIFS) {
> -if (virAsprintf(&src, "//%s/%s",
> -pool->def->source.hosts[0].name,
> -pool->def->source.dir) == -1)
> -return -1;
> -} else {
> -if (virAsprintf(&src, "%s:%s",
> -pool->def->source.hosts[0].name,
> -pool->def->source.dir) == -1)
> -return -1;
> -}
> -} else {
> -if (VIR_STRDUP(src, pool->def->source.devices[0].path) < 0)
> -return -1;
> -}
> +if (!(src = virStorageBackendFileSystemGetPoolSource(pool)))
> +return -1;
>
> if (netauto)
> cmd = virCommandNewArgList(MOUNT,
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/5] storage: Refactor virStorageBackendFileSystemGetPoolSource
On 07.12.2015 21:47, John Ferlan wrote:
> Refactor code to use standard return functioning with respect to setting
> a ret value and going to cleanup.
>
> Signed-off-by: John Ferlan
> ---
> src/storage/storage_backend_fs.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/storage/storage_backend_fs.c
> b/src/storage/storage_backend_fs.c
> index ef1a7d0..1dd5727 100644
> --- a/src/storage/storage_backend_fs.c
> +++ b/src/storage/storage_backend_fs.c
> @@ -418,6 +418,7 @@
> virStorageBackendFileSystemGetPoolSource(virStoragePoolObjPtr pool)
> static int
> virStorageBackendFileSystemIsMounted(virStoragePoolObjPtr pool)
> {
> +int ret = -1;
> FILE *mtab;
> struct mntent ent;
> char buf[1024];
> @@ -426,18 +427,21 @@
> virStorageBackendFileSystemIsMounted(virStoragePoolObjPtr pool)
> virReportSystemError(errno,
> _("cannot read mount list '%s'"),
> _PATH_MOUNTED);
> -return -1;
> +goto cleanup;
> }
>
> while ((getmntent_r(mtab, &ent, buf, sizeof(buf))) != NULL) {
> if (STREQ(ent.mnt_dir, pool->def->target.path)) {
> -VIR_FORCE_FCLOSE(mtab);
> -return 1;
> +ret = 1;
> +goto cleanup;
> }
> }
>
> +ret = 0;
> +
> + cleanup:
> VIR_FORCE_FCLOSE(mtab);
> -return 0;
> +return ret;
> }
>
> /**
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/5] storage: Create helper for virStorageBackendLogicalFindPoolSources
On 07.12.2015 21:47, John Ferlan wrote:
> Rework virStorageBackendLogicalFindPoolSources a bit to create a
> helper virStorageBackendLogicalGetPoolSources that will make the
> pvs call in order to generate a list of associated pv_name and vg_name's.
>
> A future patch will make use of this for start/check processing to
> ensure the storage pool source definition matches expectations.
>
> Signed-off-by: John Ferlan
> ---
> src/storage/storage_backend_logical.c | 52
> ---
> 1 file changed, 36 insertions(+), 16 deletions(-)
>
> diff --git a/src/storage/storage_backend_logical.c
> b/src/storage/storage_backend_logical.c
> index 536e617..53ba983 100644
> --- a/src/storage/storage_backend_logical.c
> +++ b/src/storage/storage_backend_logical.c
> @@ -414,10 +414,16 @@ virStorageBackendLogicalFindPoolSourcesFunc(char
> **const groups,
> return -1;
> }
>
> -static char *
> -virStorageBackendLogicalFindPoolSources(virConnectPtr conn ATTRIBUTE_UNUSED,
> -const char *srcSpec ATTRIBUTE_UNUSED,
> -unsigned int flags)
> +/*
> + * @sourceList: Pointer to a storage pool source list
> + *
> + * Use the pvs command to fill the list of pv_name and vg_name associated
> + * into the passed sourceList.
> + *
> + * Returns 0 if successful, -1 and sets error on failure
> + */
> +static int
> +virStorageBackendLogicalGetPoolSources(virStoragePoolSourceListPtr
> sourceList)
> {
> /*
> * # pvs --noheadings -o pv_name,vg_name
> @@ -431,11 +437,7 @@ virStorageBackendLogicalFindPoolSources(virConnectPtr
> conn ATTRIBUTE_UNUSED,
> 2
> };
> virCommandPtr cmd;
> -char *retval = NULL;
> -virStoragePoolSourceList sourceList;
> -size_t i;
> -
> -virCheckFlags(0, NULL);
> +int ret = -1;
>
> /*
> * NOTE: ignoring errors here; this is just to "touch" any logical
> volumes
> @@ -447,20 +449,38 @@ virStorageBackendLogicalFindPoolSources(virConnectPtr
> conn ATTRIBUTE_UNUSED,
> VIR_WARN("Failure when running vgscan to refresh physical volumes");
> virCommandFree(cmd);
>
> -memset(&sourceList, 0, sizeof(sourceList));
> -sourceList.type = VIR_STORAGE_POOL_LOGICAL;
> -
> cmd = virCommandNewArgList(PVS,
> "--noheadings",
> "-o", "pv_name,vg_name",
> NULL);
> if (virCommandRunRegex(cmd, 1, regexes, vars,
> virStorageBackendLogicalFindPoolSourcesFunc,
> - &sourceList, "pvs") < 0) {
> -virCommandFree(cmd);
> -return NULL;
> -}
> + sourceList, "pvs") < 0)
> +goto cleanup;
> +ret = 0;
> +
> + cleanup:
> virCommandFree(cmd);
> +return ret;
> +}
> +
> +
> +static char *
> +virStorageBackendLogicalFindPoolSources(virConnectPtr conn ATTRIBUTE_UNUSED,
> +const char *srcSpec ATTRIBUTE_UNUSED,
> +unsigned int flags)
> +{
> +virStoragePoolSourceList sourceList;
> +size_t i;
> +char *retval = NULL;
> +
> +virCheckFlags(0, NULL);
> +
> +memset(&sourceList, 0, sizeof(sourceList));
> +sourceList.type = VIR_STORAGE_POOL_LOGICAL;
> +
> +if (virStorageBackendLogicalGetPoolSources(&sourceList) < 0)
> +goto cleanup;
>
> retval = virStoragePoolSourceListFormat(&sourceList);
> if (retval == NULL) {
>
ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [Patch V2 1/2] x86, mce: Basic support to add LMCE support to QEMU
On Mon, Dec 14, 2015 at 07:17:27PM -0500, Raj, Ashok wrote: > On Mon, Dec 14, 2015 at 11:37:16PM +0100, Borislav Petkov wrote: > > On Mon, Dec 14, 2015 at 02:11:46PM -0500, Raj, Ashok wrote: > > > This is mostly harmless.. since the MCG_CAP space is shared and has no > > > conflict between vendors. Also just the CAP being set has no effect. > > > > Of course it does - we check SER_P in machine_check_poll() and when > > I emulate an AMD guest and inject errors into it, error handling is > > obviously wrong, see: > > > > https://lkml.kernel.org/r/20151123150355.ge5...@pd.tnic > > > > I can see how this hurts.. since the poller isn't doing cpu model specific > stuff..? > > in the LMCE case, even if you advertise MCG_LMCE_P in MCG_CAP, the guest > kernel > wont call intel_init_lmce() only from mce_intel.c.. so the same problem > won't happen. > > but the issue Eduardo mentioned seems like the following. > > New QEMU_LMCE + New KVM_LMCE + New_GUEST_LMCE - No problem > > but if you were to migrage the Guest_LMCE to a non-LMCE supported KVM host > we could run into an issue.. > > is this the compatibility issue that you were looking to fix Eduardo? If I understood you correctly, yes. Also, note that currently kvm_arch_init_vcpu() simply warns about missing capabilities, instead of preventing the VM from running/migrating (as it should). We need to change that, and figure out a good way to report "feature FOO can't be enabled in this host" errors to management software[1]. The main problem is that we don't even have a QMP console available anymore if machine initialization is aborted. CCing libvir-list so they get in the loop. [1] This is similar to what we need for CPUID checks, but the new MCE feature means we need something more generic (that just reports QOM property names, probably?) -- Eduardo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 0/3] security: misc cleanups
On Mon, Dec 14, 2015 at 01:36:43PM -0500, John Ferlan wrote: > On 12/09/2015 08:50 AM, Ján Tomko wrote: > > v1: https://www.redhat.com/archives/libvir-list/2015-November/msg00781.html > > new in v2: > > * split by security driver > > * more functions renamed > > > > Ján Tomko (3): > > security_dac: remove extra Security from function names > > security_selinux: remove extra Security from function names > > security_stack: : remove extra security from function names > > > > src/security/security_dac.c | 242 +- > > src/security/security_selinux.c | 375 > > > > src/security/security_stack.c | 68 > > 3 files changed, 338 insertions(+), 347 deletions(-) > > > > ACK series Now pushed. Thank you. Jan signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] volume download/upload but for snapshots
2015-12-15 17:14 GMT+03:00 Michal Privoznik : > Defining a volume would be just to workaround the problem. I think it > deserves a separate API. Whether someone from libvirt dev can help with this ?=) -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/2] Add support for zero-write detection
On Tue, Dec 15, 2015 at 07:27:46AM -0500, John Ferlan wrote:
On 12/14/2015 09:57 AM, Martin Kletzander wrote:
QEMU supports detect-zeroes option since version 2.1, but we never
added support for it in libvirt. If was requested by Vasiliy Tolstov
in the list, so I just added it.
There are two discussions to be had, optionally. One is to decide
whether we should disable detect_zeros='unmap' if discard is not set
to 'unmap', but this is getting very hypervisor-specific, so I just
documented the behaviour. The other one is the naming. I described
why I made the decision for "zeros" instead of "zeroes" the decision
in the patch, but I have no problem changing it to what others like
better.
Unfortunate that qemu chose "zeroes" instead of "zeros" or instead of
"detect_zero_writes" (or something even longer and more descriptive).
Seems strange though to say "detect_zeros=unmap". Would perhaps
something like :
detect = zero_write [or just zero, zeros, or zeroes]
detect = unmap
...
or
detect_zero = write
detect_zero = unmap
...
Be more generic? Also, I would think detect_zero[e]s = off is
meaningless since it's an optional parameter. The way the code is
written, passing detect_zeroes=off to me would be akin to not providing
it at all.
Yes, we could be more generic, I just couldn't think of any
generalization of this feature. The "off" value is possible to use
just in case the hypervisor default is something else ("on", for
example), so that you can forcibly turn it off. Otherwise we would hae
to guarantee that the default is off and I see that as a can of worms.
I think from my quick read - this would be similar to the "discard"
option, w.r.t. values used/set.
John
v2:
- format detect_zeroes on the command line instead of detect_zeros
v1:
- https://www.redhat.com/archives/libvir-list/2015-December/msg00484.html
Martin Kletzander (2):
conf: Add support of zero-detection for disks
qemu: Add support for zero-detection writes
docs/formatdomain.html.in | 10 ++
docs/schemas/domaincommon.rng | 12 +++
src/conf/domain_conf.c | 23 +-
src/conf/domain_conf.h | 11 +++
src/libvirt_private.syms | 2 ++
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c| 11 +++
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 +
.../qemuxml2argv-disk-drive-detect-zeros.args | 27
.../qemuxml2argv-disk-drive-detect-zeros.xml | 37 ++
tests/qemuxml2argvtest.c | 4 +++
tests/qemuxml2xmltest.c| 1 +
15 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-detect-zeros.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-disk-drive-detect-zeros.xml
--
2.6.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Exclusive VM lock
On Tue, Dec 15, 2015 at 03:26:44PM +0300, Dmitry Andreev wrote: On 15.12.2015 11:47, Martin Kletzander wrote: On Mon, Dec 14, 2015 at 06:50:56PM +0300, Dmitry Andreev wrote: On 14.12.2015 18:10, Peter Krempa wrote: On Mon, Dec 14, 2015 at 17:18:22 +0300, Dmitry Andreev wrote: Hi, I'm looking for a mechanism to do a sequence of API calls as atomic operation. Is there any way for libvirt's API client to acquire an exclusive VM lock to prevent other client from changing VM state through libvirt? No there isn't anything. Libvirt is locking only on internal events that need protection. Doing transaction locking should be relatively easy to implement on application layer though. Sure we can implement a lock manager on the API client side, but it can't lock VM for other clients. And that’s the problem for us. Are maintainers interested in VM lock manager on the server side? Can I move in this direction or you have something against it? Well, I think that if you want to lock it in the layer above, you should lock it in the layer above. And you can disable other clients, restrict them, etc. Would you mind describing the use-case more thoroughly? Maybe we have a solution for that already. We allow users to manage VMs with virt-manager but when we updates VM configuration using API we want the read-change-write operation to be atomic. In few other cases we don't want to allow user run or stop vm while we doing post creation or guest configuration job. Oh, for that PolicyKit might be a bit overkill, but it's currently the only thing I can think of. You might modify the rules so that users can do what you allow only if you want them to. Maybe the best way to handle this is to do an automatic update of polkit rules. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Warn when using vhost-user without shared memory
[...]
>>> +bool shmem = vm->def->nshmems;
>>> +
>>> +/*
>>> + * This check is by no means complete. We merely check
>>> + * whetere there are *some* hugepages enabled and *some* NUMA
>>> + * nodes with shared memory access.
>>> + */
>>> +if (!shmem && vm->def->mem.nhugepages) {
>>> +for (i = 0; i <
>>> virDomainNumaGetNodeCount(vm->def->numa); i++) {
>>> +if
>>> (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) ==
>>> +VIR_NUMA_MEM_ACCESS_SHARED)
>>> +shmem = true;
>>> +break;
>>
>> Coverity complains here that i++ is not reachable. I think you meant to
>> put the break; inside the if, right?
>>
>> John
>
> Yes, exactly, thanks for noticing, this should be the diff:
>
> diff --git i/src/qemu/qemu_process.c w/src/qemu/qemu_process.c
> index ba8dfebd1357..f2740687f655 100644
> --- i/src/qemu/qemu_process.c
> +++ w/src/qemu/qemu_process.c
> @@ -4781,9 +4781,10 @@ qemuProcessLaunch(virConnectPtr conn,
> if (!shmem && vm->def->mem.nhugepages) {
> for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa);
> i++) {
> if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa,
> i) ==
> -VIR_NUMA_MEM_ACCESS_SHARED)
> +VIR_NUMA_MEM_ACCESS_SHARED) {
> shmem = true;
> -break;
> +break;
> +}
> }
> }
>
> --
>
> I will push it later on if you agree.
>
> Martin
Looks OK to me
ACK
John
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] volume download/upload but for snapshots
On 02.12.2015 10:50, Vasiliy Tolstov wrote: > Hi! I'm happy with libvirt volume download/upload ability, but also i > need to download snapshot, what is the best way to do that? > Define volume from snapshot? Or write libvirt function for this? > Defining a volume would be just to workaround the problem. I think it deserves a separate API. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, Dec 15, 2015 at 09:41:02AM +, Peter Maydell wrote: On 15 December 2015 at 09:36, Martin Kletzander wrote: We do pass some options, for example, you can restrict the GIC to v2: https://libvirt.org/formatdomain.html#elementsFeatures That could be modified to work for your purpose IIUC, right? What does that option do to the QEMU command line? The documentation doesn't seem to say. It appends gic-version= to the machine option, if bunch of conditions are met -- it has to be ARM machine, it has to be something else than version 2, and so on, more details are visible in the code and I won't cover them here. I hope that's understandable. thanks -- PMM signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Warn when using vhost-user without shared memory
On Tue, Dec 15, 2015 at 06:44:25AM -0500, John Ferlan wrote:
On 12/08/2015 10:24 AM, Martin Kletzander wrote:
When user configures vhost-user interface and forgets to also configure
any shared memory, the search for the root cause of non-operational
interface might take unpleasantly long time. Let's enhance user
experience by emitting a warning in the logs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1266982
Signed-off-by: Martin Kletzander
---
src/qemu/qemu_process.c | 44
1 file changed, 44 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 420196264685..fb471342e790 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -4542,6 +4542,7 @@ qemuProcessLaunch(virConnectPtr conn,
unsigned int hostdev_flags = 0;
size_t nnicindexes = 0;
int *nicindexes = NULL;
+bool check_shmem = false;
VIR_DEBUG("vm=%p name=%s id=%d asyncJob=%d "
"incoming.launchURI=%s incoming.deferredURI=%s "
@@ -4749,6 +4750,49 @@ qemuProcessLaunch(virConnectPtr conn,
goto cleanup;
}
+VIR_DEBUG("Checking for any possible (non-fatal) issues");
+
+/*
+ * For vhost-user to work, the domain has to have some type of
+ * shared memory configured. We're not the proper once to judge
+ * whether shared hugepages or shm are enough and will be in the
+ * future, so we'll just warn in case there is none of that
+ * configured. Moreover failing would give the false illusion
+ * that libvirt is really checking that everything works before
+ * running the domain and not only we are unable to do that, but
+ * it's also not our aim to do so.
+ */
+for (i = 0; i < vm->def->nnets; i++) {
+if (virDomainNetGetActualType(vm->def->nets[i]) ==
+ VIR_DOMAIN_NET_TYPE_VHOSTUSER) {
+check_shmem = true;
+break;
+}
+}
+
+if (check_shmem) {
+bool shmem = vm->def->nshmems;
+
+/*
+ * This check is by no means complete. We merely check
+ * whetere there are *some* hugepages enabled and *some* NUMA
+ * nodes with shared memory access.
+ */
+if (!shmem && vm->def->mem.nhugepages) {
+for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa); i++) {
+if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) ==
+VIR_NUMA_MEM_ACCESS_SHARED)
+shmem = true;
+break;
Coverity complains here that i++ is not reachable. I think you meant to
put the break; inside the if, right?
John
Yes, exactly, thanks for noticing, this should be the diff:
diff --git i/src/qemu/qemu_process.c w/src/qemu/qemu_process.c
index ba8dfebd1357..f2740687f655 100644
--- i/src/qemu/qemu_process.c
+++ w/src/qemu/qemu_process.c
@@ -4781,9 +4781,10 @@ qemuProcessLaunch(virConnectPtr conn,
if (!shmem && vm->def->mem.nhugepages) {
for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa); i++) {
if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) ==
-VIR_NUMA_MEM_ACCESS_SHARED)
+VIR_NUMA_MEM_ACCESS_SHARED) {
shmem = true;
-break;
+break;
+}
}
}
--
I will push it later on if you agree.
Martin
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 4/4] qemu: Implement shared memory device hot-unplug
[...] >>> +if (rc < 0) >>> +return -1; >>> + >> I know this is a copy of the RemoveRNGDevice; however, this code doesn't >> remove an 'obj'. In fact, if !shmem->server.enabled, then we don't enter >> the monitor at all. >> >> Thus the following event probably won't happen... > > I am not sure what your mean is ... i guess your mean the device remove > event we get from qmp monitor won't happen ? we will get that event if > qemu remove shmem device success, it should always happen if qemu really > remove it and there is no bugs on qemu :) > While reviewing I got lazy and didn't check the non hotplug case to how shmem is added to the vm, but the point I was trying to make is that "if (shmem->server.enabled)" fails (e.g. is false), then there is no "rc = qemuMonitorDelObject(priv->mon, objAlias);" call in this API (similar to RNG code), thus how does the following event get triggered? Even if the condition was true, does detaching the char dev cause the event to be triggered? I thought the event was related to the DelObject code, but I didn't go follow that code John [...] -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 0/2] Add support for zero-write detection
On 12/14/2015 09:57 AM, Martin Kletzander wrote: > QEMU supports detect-zeroes option since version 2.1, but we never > added support for it in libvirt. If was requested by Vasiliy Tolstov > in the list, so I just added it. > > There are two discussions to be had, optionally. One is to decide > whether we should disable detect_zeros='unmap' if discard is not set > to 'unmap', but this is getting very hypervisor-specific, so I just > documented the behaviour. The other one is the naming. I described > why I made the decision for "zeros" instead of "zeroes" the decision > in the patch, but I have no problem changing it to what others like > better. Unfortunate that qemu chose "zeroes" instead of "zeros" or instead of "detect_zero_writes" (or something even longer and more descriptive). Seems strange though to say "detect_zeros=unmap". Would perhaps something like : detect = zero_write [or just zero, zeros, or zeroes] detect = unmap ... or detect_zero = write detect_zero = unmap ... Be more generic? Also, I would think detect_zero[e]s = off is meaningless since it's an optional parameter. The way the code is written, passing detect_zeroes=off to me would be akin to not providing it at all. I think from my quick read - this would be similar to the "discard" option, w.r.t. values used/set. John > > v2: > - format detect_zeroes on the command line instead of detect_zeros > > v1: > - https://www.redhat.com/archives/libvir-list/2015-December/msg00484.html > > Martin Kletzander (2): > conf: Add support of zero-detection for disks > qemu: Add support for zero-detection writes > > docs/formatdomain.html.in | 10 ++ > docs/schemas/domaincommon.rng | 12 +++ > src/conf/domain_conf.c | 23 +- > src/conf/domain_conf.h | 11 +++ > src/libvirt_private.syms | 2 ++ > src/qemu/qemu_capabilities.c | 2 ++ > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c| 11 +++ > 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 + > .../qemuxml2argv-disk-drive-detect-zeros.args | 27 > .../qemuxml2argv-disk-drive-detect-zeros.xml | 37 > ++ > tests/qemuxml2argvtest.c | 4 +++ > tests/qemuxml2xmltest.c| 1 + > 15 files changed, 143 insertions(+), 1 deletion(-) > create mode 100644 > tests/qemuxml2argvdata/qemuxml2argv-disk-drive-detect-zeros.args > create mode 100644 > tests/qemuxml2argvdata/qemuxml2argv-disk-drive-detect-zeros.xml > > -- > 2.6.4 > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Exclusive VM lock
On 15.12.2015 11:47, Martin Kletzander wrote: On Mon, Dec 14, 2015 at 06:50:56PM +0300, Dmitry Andreev wrote: On 14.12.2015 18:10, Peter Krempa wrote: On Mon, Dec 14, 2015 at 17:18:22 +0300, Dmitry Andreev wrote: Hi, I'm looking for a mechanism to do a sequence of API calls as atomic operation. Is there any way for libvirt's API client to acquire an exclusive VM lock to prevent other client from changing VM state through libvirt? No there isn't anything. Libvirt is locking only on internal events that need protection. Doing transaction locking should be relatively easy to implement on application layer though. Sure we can implement a lock manager on the API client side, but it can't lock VM for other clients. And that’s the problem for us. Are maintainers interested in VM lock manager on the server side? Can I move in this direction or you have something against it? Well, I think that if you want to lock it in the layer above, you should lock it in the layer above. And you can disable other clients, restrict them, etc. Would you mind describing the use-case more thoroughly? Maybe we have a solution for that already. We allow users to manage VMs with virt-manager but when we updates VM configuration using API we want the read-change-write operation to be atomic. In few other cases we don't want to allow user run or stop vm while we doing post creation or guest configuration job. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
Hello! Nobody ever CCed me, so i saw this topic only occasionally... Sorry for the late reply. > The challenge is that QEMU's virt machine model defaults to GICv2 unless > you specify an additional "-machine gic-version=host" parameter to QEMU, > in which case your VM gets the same GIC version as your host. Or you can specify gic-version=3, and get v3. The idea behind this was to be backwards-compatible. In old qemu versions you don't specify anything, and get v2. With new qemu it's the same. The only problem here is that on some GICv3 hosts you can run only GICv3 KVM guests, because vGICv2 support is optional. With TCG (once GICv3 software emulation is implemented) you wouldn't have this limitation at all. Actually, i am also proposing kernel patches which enable to use software-emulated GIC with KVM (http://www.spinics.net/lists/kvm/msg124539.html, http://www.spinics.net/lists/kvm/msg124545.html), but got no review so far. I also have support in qemu for this. With these patches you would actually be able to run GICv2 guest on GICv3-only host, but with some performance penalty, just by adding kernel_irqchip=off machine option. > Now, I'm told that this is inconvenient for libvirt, because it > typically does not pass any -machine options, is that correct? It's incorrect: http://www.redhat.com/archives/libvir-list/2015-September/msg01067.html > Second, some hardware platforms only support GICv2 guests, some only > support GICv3 guests, and some support both GICv2 and GICv3 guests > (those hosts with a GICv3 with the backwards compatibility support). > > It is unclear to me how libvirt users will relate to these constraints. Actually, i see GICv3 and GICv2 "virt" actually as different machine types. Because in real world these would be different motherboards, even if we imagine that CPUs are the same. Actually, initially i proposed to simply add "virt-v3" (or "virt-gicv3", if you want) machine type. I believe this would resolve many things automatically (obviously in order to run a machine you need an OS new enough to support it, and all applications would just see the new machine choice). But Peter strongly disagreed with that and asked me to add an option to existing virt machine instead. > The end goal here is to determine if we need to add any functionality to > QEMU to better support libvirt, and what kind of features/glue need to > be added to libvirt for this to work. I'd say that it's not libvirt's work now. We have support in the XML for this option, so now it's up to application to be able to specify this. For example, applications, once "virt" type is chosen, should be able to present one more control to choose between GIC versions. Just think of it as "machine sub-type". Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, 2015-12-15 at 11:11 +0100, Christoffer Dall wrote: > On Tue, Dec 15, 2015 at 10:36:32AM +0100, Martin Kletzander wrote: > > On Mon, Dec 14, 2015 at 10:47:26AM -0600, Andrew Jones wrote: > > > On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote: > > > > Hi all, > > > > > > > > I'm trying to figure out what the correct solution for libvirt support > > > > for ARM KVM guests with GICv3 is. > > > > > > > > The challenge is that QEMU's virt machine model defaults to GICv2 unless > > > > you specify an additional "-machine gic-version=host" parameter to QEMU, > > > > in which case your VM gets the same GIC version as your host. > > > > > > > > Now, I'm told that this is inconvenient for libvirt, because it > > > > typically does not pass any -machine options, is that correct? > > > > We do pass some options, for example, you can restrict the GIC to v2: > > https://libvirt.org/formatdomain.html#elementsFeatures > > > > That could be modified to work for your purpose IIUC, right? > > > How do I figure out which values the version can take (v2, v3, host?) > and which QEMU cmdline that translates into? The parser will currently accept any numeric value, including eg. 1 and 42. The value 2 is special and is silently ignored for backwards compatibility; any other value will cause libvirt to add the gic-version option to the machine type. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3 v2] vz: implementation of boot device order
This patch implements functionality of boot device order
based on boot element from os section in XML.
Now we support boot from CDROM and HDD.
If we have several devices of the same type (for example hdd0 and hdd1),
than we mark the first one as bootable.
---
diff from v1:
Move this commit to patch series
src/vz/vz_sdk.c | 111 +---
1 file changed, 81 insertions(+), 30 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 1fcfb2e..4cf9871 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2212,6 +2212,78 @@ prlsdkAddDeviceToBootList(PRL_HANDLE sdkdom,
return -1;
}
+static int
+prlsdkSetBootDevices(PRL_HANDLE sdkdom,
+ virDomainDefPtr def)
+{
+size_t i;
+PRL_RESULT pret;
+PRL_HANDLE devList = PRL_INVALID_HANDLE;
+PRL_HANDLE dev = PRL_INVALID_HANDLE;
+PRL_DEVICE_TYPE currentDevType, bootDevType;
+PRL_UINT32 devIndex, devCount, j;
+PRL_UINT32 bootSequence = 0;
+bool rootMount = false;
+
+pret = PrlVmCfg_GetAllDevices(sdkdom, &devList);
+prlsdkCheckRetGoto(pret, error);
+
+pret = PrlHndlList_GetItemsCount(devList, &devCount);
+prlsdkCheckRetGoto(pret, error);
+
+for (i = 0; i < def->os.nBootDevs; i++) {
+switch (def->os.bootDevs[i]) {
+case VIR_DOMAIN_BOOT_CDROM:
+bootDevType = PDE_OPTICAL_DISK;
+break;
+case VIR_DOMAIN_BOOT_DISK:
+bootDevType = PDE_HARD_DISK;
+break;
+default:
+continue;
+}
+
+for (j = 0; j < devCount; j++) {
+pret = PrlHndlList_GetItem(devList, j, &dev);
+prlsdkCheckRetGoto(pret, error);
+
+pret = PrlVmDev_GetType(dev, ¤tDevType);
+prlsdkCheckRetGoto(pret, error);
+
+if (currentDevType == bootDevType) {
+pret = PrlVmDev_GetIndex(dev, &devIndex);
+prlsdkCheckRetGoto(pret, error);
+
+if (prlsdkAddDeviceToBootList(sdkdom, devIndex,
currentDevType, bootSequence) < 0)
+goto error;
+bootSequence++;
+
+if (IS_CT(def) && !rootMount) {
+/* If we add physical device as a boot disk to container
+ we have to specify mount point for it */
+pret = PrlVmDevHd_SetMountPoint(dev, "/");
+prlsdkCheckRetGoto(pret, error);
+rootMount = true;
+}
+}
+PrlHandle_Free(dev);
+dev = PRL_INVALID_HANDLE;
+}
+}
+
+PrlHandle_Free(devList);
+return 0;
+
+ error:
+if (dev != PRL_INVALID_HANDLE)
+PrlHandle_Free(dev);
+
+if (devList != PRL_INVALID_HANDLE)
+PrlHandle_Free(devList);
+
+return -1;
+}
+
static int prlsdkCheckGraphicsUnsupportedParams(virDomainDefPtr def)
{
virDomainGraphicsDefPtr gr;
@@ -3159,9 +3231,7 @@ static int prlsdkDelDisk(PRL_HANDLE sdkdom, int idx)
}
static int prlsdkAddDisk(PRL_HANDLE sdkdom,
- virDomainDiskDefPtr disk,
- bool bootDisk,
- bool isCt)
+ virDomainDiskDefPtr disk)
{
PRL_RESULT pret;
PRL_HANDLE sdkdisk = PRL_INVALID_HANDLE;
@@ -3170,7 +3240,6 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
PRL_MASS_STORAGE_INTERFACE_TYPE sdkbus;
int idx;
virDomainDeviceDriveAddressPtr drive;
-PRL_UINT32 devIndex;
PRL_DEVICE_TYPE devType;
char *dst = NULL;
@@ -3319,21 +3388,6 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
goto cleanup;
}
-if (bootDisk) {
-pret = PrlVmDev_GetIndex(sdkdisk, &devIndex);
-prlsdkCheckRetGoto(pret, cleanup);
-
-if (prlsdkAddDeviceToBootList(sdkdom, devIndex, devType, 0) < 0)
-goto cleanup;
-
-/* If we add physical device as a boot disk to container
- * we have to specify mount point for it */
-if (isCt) {
-pret = PrlVmDevHd_SetMountPoint(sdkdisk, "/");
-prlsdkCheckRetGoto(pret, cleanup);
-}
-}
-
return 0;
cleanup:
PrlHandle_Free(sdkdisk);
@@ -3352,7 +3406,7 @@ prlsdkAttachVolume(virDomainObjPtr dom,
virDomainDiskDefPtr disk)
if (PRL_FAILED(waitJob(job)))
goto cleanup;
-ret = prlsdkAddDisk(privdom->sdkdom, disk, false, IS_CT(dom->def));
+ret = prlsdkAddDisk(privdom->sdkdom, disk);
if (ret == 0) {
job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE);
if (PRL_FAILED(waitJob(job))) {
@@ -3490,7 +3544,7 @@ prlsdkDoApplyConfig(virConnectPtr conn,
PRL_RESULT pret;
size_t i;
char uuidstr[VIR_UUID_STRING_BUFLEN + 2];
-bool needBoot = true;
+bool rootfsFound = false;
char *mask = NULL;
if (prlsdkCheckUnsupportedParams(sdkdom, def) < 0)
@@ -3576,21 +3630,18 @@ prlsdkDoApplyConfig(virConnectPtr conn,
goto
Re: [libvirt] [PATCH] qemu: Warn when using vhost-user without shared memory
On 12/08/2015 10:24 AM, Martin Kletzander wrote:
> When user configures vhost-user interface and forgets to also configure
> any shared memory, the search for the root cause of non-operational
> interface might take unpleasantly long time. Let's enhance user
> experience by emitting a warning in the logs.
>
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1266982
>
> Signed-off-by: Martin Kletzander
> ---
> src/qemu/qemu_process.c | 44
> 1 file changed, 44 insertions(+)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 420196264685..fb471342e790 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -4542,6 +4542,7 @@ qemuProcessLaunch(virConnectPtr conn,
> unsigned int hostdev_flags = 0;
> size_t nnicindexes = 0;
> int *nicindexes = NULL;
> +bool check_shmem = false;
>
> VIR_DEBUG("vm=%p name=%s id=%d asyncJob=%d "
>"incoming.launchURI=%s incoming.deferredURI=%s "
> @@ -4749,6 +4750,49 @@ qemuProcessLaunch(virConnectPtr conn,
> goto cleanup;
> }
>
> +VIR_DEBUG("Checking for any possible (non-fatal) issues");
> +
> +/*
> + * For vhost-user to work, the domain has to have some type of
> + * shared memory configured. We're not the proper once to judge
> + * whether shared hugepages or shm are enough and will be in the
> + * future, so we'll just warn in case there is none of that
> + * configured. Moreover failing would give the false illusion
> + * that libvirt is really checking that everything works before
> + * running the domain and not only we are unable to do that, but
> + * it's also not our aim to do so.
> + */
> +for (i = 0; i < vm->def->nnets; i++) {
> +if (virDomainNetGetActualType(vm->def->nets[i]) ==
> + VIR_DOMAIN_NET_TYPE_VHOSTUSER) {
> +check_shmem = true;
> +break;
> +}
> +}
> +
> +if (check_shmem) {
> +bool shmem = vm->def->nshmems;
> +
> +/*
> + * This check is by no means complete. We merely check
> + * whetere there are *some* hugepages enabled and *some* NUMA
> + * nodes with shared memory access.
> + */
> +if (!shmem && vm->def->mem.nhugepages) {
> +for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa); i++) {
> +if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) ==
> +VIR_NUMA_MEM_ACCESS_SHARED)
> +shmem = true;
> +break;
Coverity complains here that i++ is not reachable. I think you meant to
put the break; inside the if, right?
John
> +}
> +}
> +
> +if (!shmem) {
> +VIR_WARN("Detected vhost-user interface without any shared
> memory. "
> + "The interface might not be operational");
> +}
> +}
> +
> VIR_DEBUG("Building emulator command line");
> if (!(cmd = qemuBuildCommandLine(conn, driver, vm->def, priv->monConfig,
> priv->monJSON, priv->qemuCaps,
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3 v3] vz: allow to create container based on template
We shouldn't delete disk from default config if we create container based on
template,
because we don't have the new disk from XML, only template name.
And don't add template section from XML as new filesystem,
we use PrlVmCfg_SetOsTemplate function to set template name.
Do not set PRNVM_PRESERVE_DISK flag in PrlVm_RegEx() call,
because this will cause an error during CT startup.
---
diff from v2:
fix syntax check
diff from v1:
Remove unusable variable (PRL_VM_DEV_EMULATION_TYPE emul)
Add parameter useCtTemplateFs in prlsdkDoApplyConfig() function
Allow only one fs with "template" type and only for CT creation
Move this commit to patch series
src/vz/vz_sdk.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 2b031c9..c5f8edd 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2107,12 +2107,13 @@ prlsdkCheckUnsupportedParams(PRL_HANDLE sdkdom,
virDomainDefPtr def)
return 0;
}
-static int prlsdkClearDevices(PRL_HANDLE sdkdom)
+static int prlsdkClearDevices(PRL_HANDLE sdkdom, bool skipdisk)
{
PRL_RESULT pret;
PRL_UINT32 n, i;
PRL_HANDLE devList;
PRL_HANDLE dev;
+PRL_DEVICE_TYPE devType;
int ret = -1;
pret = PrlVmCfg_SetVNCMode(sdkdom, PRD_DISABLED);
@@ -2128,6 +2129,15 @@ static int prlsdkClearDevices(PRL_HANDLE sdkdom)
pret = PrlHndlList_GetItem(devList, i, &dev);
prlsdkCheckRetGoto(pret, cleanup);
+if (skipdisk) {
+pret = PrlVmDev_GetType(dev, &devType);
+prlsdkCheckRetGoto(pret, cleanup);
+
+if (devType == PDE_HARD_DISK) {
+PrlHandle_Free(dev);
+continue;
+}
+}
pret = PrlVmDev_Remove(dev);
PrlHandle_Free(dev);
}
@@ -3470,7 +3480,8 @@ static int
prlsdkDoApplyConfig(virConnectPtr conn,
PRL_HANDLE sdkdom,
virDomainDefPtr def,
-virDomainDefPtr olddef)
+virDomainDefPtr olddef,
+bool useCtTemplateFs)
{
PRL_RESULT pret;
size_t i;
@@ -3526,7 +3537,7 @@ prlsdkDoApplyConfig(virConnectPtr conn,
}
prlsdkCheckRetGoto(pret, error);
-if (prlsdkClearDevices(sdkdom) < 0)
+if (prlsdkClearDevices(sdkdom, useCtTemplateFs) < 0)
goto error;
if (prlsdkRemoveBootDevices(sdkdom) < 0)
@@ -3554,6 +3565,12 @@ prlsdkDoApplyConfig(virConnectPtr conn,
}
for (i = 0; i < def->nfss; i++) {
+if (def->fss[i]->type == VIR_DOMAIN_FS_TYPE_TEMPLATE) {
+if (useCtTemplateFs)
+continue;
+else
+goto error;
+}
if (STREQ(def->fss[i]->dst, "/"))
needBoot = false;
if (prlsdkAddFS(sdkdom, def->fss[i]) < 0)
@@ -3602,7 +3619,7 @@ prlsdkApplyConfig(virConnectPtr conn,
if (PRL_FAILED(waitJob(job)))
return -1;
-ret = prlsdkDoApplyConfig(conn, sdkdom, new, dom->def);
+ret = prlsdkDoApplyConfig(conn, sdkdom, new, dom->def, false);
if (ret == 0) {
job = PrlVm_CommitEx(sdkdom, PVCF_DETACH_HDD_BUNDLE);
@@ -3642,7 +3659,7 @@ prlsdkCreateVm(virConnectPtr conn, virDomainDefPtr def)
pret = PrlVmCfg_SetOfflineManagementEnabled(sdkdom, 0);
prlsdkCheckRetGoto(pret, cleanup);
-ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL);
+ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL, false);
if (ret)
goto cleanup;
@@ -3665,8 +3682,9 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
PRL_HANDLE result = PRL_INVALID_HANDLE;
PRL_RESULT pret;
int ret = -1;
-int useTemplate = 0;
+bool useTemplate = false;
size_t i;
+PRL_UINT32 flags = 0;
if (def->nfss > 1) {
/* Check all filesystems */
@@ -3679,7 +3697,7 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
}
} else if (def->nfss == 1) {
if (def->fss[0]->type == VIR_DOMAIN_FS_TYPE_TEMPLATE) {
-useTemplate = 1;
+useTemplate = true;
} else if (def->fss[0]->type != VIR_DOMAIN_FS_TYPE_FILE) {
virReportError(VIR_ERR_INVALID_ARG, "%s",
_("Unsupported filesystem type."));
@@ -3704,12 +3722,15 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
}
-ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL);
+ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL, useTemplate);
if (ret)
goto cleanup;
-job = PrlVm_RegEx(sdkdom, "",
- PACF_NON_INTERACTIVE_MODE | PRNVM_PRESERVE_DISK);
+flags = PACF_NON_INTERACTIVE_MODE;
+if (!useTemplate)
+flags = flags | PRNVM_PRESERVE_DISK;
+
+job = PrlVm_RegEx(sdkdom, "", flags);
if (PRL_FAILED(waitJob(job)))
ret = -1;
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] vz: allow to create CT from template and boot VM from cdrom
Mikhail Feoktistov (3): vz: allow to create container based on template vz: allow to boot VM from cdrom vz: implementation of boot device order src/vz/vz_sdk.c | 174 1 file changed, 125 insertions(+), 49 deletions(-) -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3 v2] vz: allow to boot VM from cdrom
If user creates virtual machine via virt-manager and select "boot from ISO"
then in libvirt we can see the following devices section
These devices don't have disk->format parameter, so we should
allow to add disks with format = VIR_STORAGE_FILE_NONE.
If user select boot from HDD and add new Cdrom device then we see
Cdrom device doesn't have disk->source parameter,
it means that user did select "attach to real device" or "use ISO".
So we should not return error if we get device with empty source path.
---
diff from v1:
Add commit description
Move this commit to patch series
src/vz/vz_sdk.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index c5f8edd..1fcfb2e 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2026,8 +2026,9 @@ prlsdkCheckUnsupportedParams(PRL_HANDLE sdkdom,
virDomainDefPtr def)
}
if (!IS_CT(def)) {
-if (def->os.nBootDevs != 1 ||
-def->os.bootDevs[0] != VIR_DOMAIN_BOOT_DISK ||
+if (def->os.nBootDevs == 0 ||
+(def->os.bootDevs[0] != VIR_DOMAIN_BOOT_DISK &&
+def->os.bootDevs[0] != VIR_DOMAIN_BOOT_CDROM) ||
def->os.init != NULL || def->os.initargv != NULL) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -3192,11 +3193,12 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
if (disk->src->type == VIR_STORAGE_TYPE_FILE) {
if (disk->device == VIR_DOMAIN_DISK_DEVICE_DISK &&
-virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_PLOOP) {
+(virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_PLOOP &&
+ virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_NONE)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid format of "
- "disk %s, vz driver
supports only "
- "images in ploop
format."), disk->src->path);
+ "disk %s, it should
be either not set or "
+ "ploop format."),
disk->src->path);
goto cleanup;
}
@@ -3218,11 +3220,13 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
pret = PrlVmDev_SetEmulatedType(sdkdisk, emutype);
prlsdkCheckRetGoto(pret, cleanup);
-pret = PrlVmDev_SetSysName(sdkdisk, disk->src->path);
-prlsdkCheckRetGoto(pret, cleanup);
+if (disk->src->path != NULL) {
+pret = PrlVmDev_SetSysName(sdkdisk, disk->src->path);
+prlsdkCheckRetGoto(pret, cleanup);
-pret = PrlVmDev_SetFriendlyName(sdkdisk, disk->src->path);
-prlsdkCheckRetGoto(pret, cleanup);
+pret = PrlVmDev_SetFriendlyName(sdkdisk, disk->src->path);
+prlsdkCheckRetGoto(pret, cleanup);
+}
drive = &disk->info.addr.drive;
if (drive->controller > 0) {
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuMonitorJSONEjectMedia: don't stringify the replay at all
On Tue, Dec 15, 2015 at 11:22:41AM +0100, Michal Privoznik wrote: > On 15.12.2015 11:08, Pavel Hrdina wrote: > > Commit 256496e1 introduced a detection if "is locked" in error replay > > from qemu monitor. Commit c4073657 fixed a memory leak, but it was > > pointed out by Peter, that this could be done cleaner without > > stringifing the replay. > > > > Signed-off-by: Pavel Hrdina > > --- > > src/qemu/qemu_monitor_json.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > Hm.. good point. ACK > > Michal Thanks, pushed now. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] pci: Use virPCIDeviceAddress in virPCIDevice
On Tue, 2015-12-15 at 10:05 +0100, Andrea Bolognani wrote: > @@ -1661,25 +1661,14 @@ virPCIDeviceFree(virPCIDevicePtr dev) > * @dev: device to get address from > * > * Take a PCI device on input and return its PCI address. The > - * caller must free the returned value when no longer needed. > + * returned object is owned by the device and must not be freed. > * > * Returns NULL on failure, the device address on success. > */ Not sending a v3 just for this, but if ACKed I'll also squash in - * Returns NULL on failure, the device address on success. + * Returns: a pointer to the address, which can never be NULL. to keep the documentation consistent with the actual behaviour. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] qemu logging/tracing option in domain xml
On Mon, Dec 14, 2015 at 04:52:43PM +0300, Dmitry Andreev wrote: > Hi all, > > QEMU has the '-d' command line option to configure logs/traces. > As I can see, is the only way to set it in domain xml. > > makes a configuration tainted and doesn't allow to update > tracing/logging configuration in runtime. The ability to update > configuration in runtime will be very useful for us in Virtuozzo for QEMU > problem investigation and development. > > So I want to ask you will you mind if I prepare a patch-set that introduces > a new section for domain xml with next scheme: > > > > > > > > > > > > Is this acceptable? IMHO I've always considered to be appropriate for these ad-hoc developer debugging flags. In addition I'm not hugely interested in adding APIs for controlling QEMU's debugging facilities, since I think these QEMU monitor commands are inherantly hypervisor specific. 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] pci: Use 'addr' instead of 'dev' for virPCIDeviceAddressPtr
On Tue, 2015-12-15 at 10:41 +0100, Martin Kletzander wrote: > On Tue, Dec 15, 2015 at 10:01:23AM +0100, Andrea Bolognani wrote: > > The name 'dev' is more appropriate for virPCIDevicePtr. > > --- > > src/util/virpci.c | 7 --- > > src/util/virpci.h | 4 ++-- > > 2 files changed, 6 insertions(+), 5 deletions(-) > > > > ACK, trivial. > > You could also fix the virPCIDeviceAddressGetIOMMUGroupNum() in the > header file, so it is the same as the .c file. But I did :) Pushed, thanks. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuMonitorJSONEjectMedia: don't stringify the replay at all
On 15.12.2015 11:08, Pavel Hrdina wrote:
> Commit 256496e1 introduced a detection if "is locked" in error replay
> from qemu monitor. Commit c4073657 fixed a memory leak, but it was
> pointed out by Peter, that this could be done cleaner without
> stringifing the replay.
>
> Signed-off-by: Pavel Hrdina
> ---
> src/qemu/qemu_monitor_json.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
> index 4ae63cf..d4b6514 100644
> --- a/src/qemu/qemu_monitor_json.c
> +++ b/src/qemu/qemu_monitor_json.c
> @@ -2223,11 +2223,12 @@ int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon,
> ret = qemuMonitorJSONCheckError(cmd, reply);
>
> if (ret < 0) {
> -char *replyStr = virJSONValueToString(reply, false);
> -
> -if (c_strcasestr(replyStr, "is locked"))
> -ret = -2;
> -VIR_FREE(replyStr);
> +virJSONValuePtr error = virJSONValueObjectGet(reply, "error");
> +if (error) {
> +const char *errorStr = virJSONValueObjectGetString(error,
> "desc");
> +if (errorStr && c_strcasestr(errorStr, "is locked"))
> +ret = -2;
> +}
> }
>
> virJSONValueFree(cmd);
>
Hm.. good point. ACK
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Revert "admin: Rename virAdmConnect to virAdmDaemon"
On Tue, Dec 15, 2015 at 08:30:41AM +0100, Martin Kletzander wrote: > On Mon, Dec 14, 2015 at 09:31:33AM +0100, Erik Skultety wrote: > >On 10/12/15 15:54, Daniel P. Berrange wrote: > >>On Thu, Dec 10, 2015 at 03:46:45PM +0100, Erik Skultety wrote: > >>>Commmit df8192aa introduced admin related rename and some minor > >>>(caused by automated approach, aka sed) and some more severe isues along > >>>with > >>>it. First reason to revert is the inconsistency with libvirt library. > >> > >>We have release 1.3.0 with this header file, so IMHO we can't just > >>rename the public APIs now. > >> > >Yes, I understand that Daniel and I know our policy, but what I thought > >was that since it's still disabled and cannot be used properly (besides > >editing the code and rebuilding upstream and still wouldn't do much), > >there might be an exception to this...obviously, it's not, so at least > >we could revert the client internal changes, I guess. > > > > Yes, moreover the header file is not distributed yet, I took the > precautions so that we can discuss API-incompatible changes for now and > finally come to a conclusion about some of these details and move on. Ok, I'll withdraw my objection > Thinking about it over and over again, I'm probably OK with being > consistent with the libvirt library even though I don't like it as > much. One other thing to solve both naming problems, but it would add > APIs that are not needed now, is to have virAdmConnectGetDaemon which > would return virAdmDaemonPtr. But that might be getting too > complicated. > > I would say that if nobody chimes in with another opinion (for, let's > say, around a week) the safest way will be sticking with the naming > that's consistent with libvirt library, despite the fact that I, > personally, am not in favor of that. As a general rule I've a preference for consistent naming across libvirt, as long as it doesn't result in mis-leading names. 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] ARM KVM GICv3 Support
On Mon, Dec 14, 2015 at 10:47:26AM -0600, Andrew Jones wrote: > On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote: > > Hi all, > > > > I'm trying to figure out what the correct solution for libvirt support > > for ARM KVM guests with GICv3 is. > > > > The challenge is that QEMU's virt machine model defaults to GICv2 unless > > you specify an additional "-machine gic-version=host" parameter to QEMU, > > in which case your VM gets the same GIC version as your host. > > > > Now, I'm told that this is inconvenient for libvirt, because it > > typically does not pass any -machine options, is that correct? > > If that is correct, then my guess is that that's because it's used to > the qemu machine model automatically selecting appropriate defaults, and > for pc, due to versioning, there are several machine model types to > choose from. mach-virt hasn't started versioning yet. > > > > > Further, there are two additional complications: First, some guest > > images may not include GICv3 support. For Linux, this is relatively old > > kernels (prior to v3.17), but other guests may only support GICv2. > > > > Second, some hardware platforms only support GICv2 guests, some only > > support GICv3 guests, and some support both GICv2 and GICv3 guests > > (those hosts with a GICv3 with the backwards compatibility support). > > > > It is unclear to me how libvirt users will relate to these constraints. > > For example, in an OpenStack deployment, will it somehow be easy to tell > > which nodes support which GIC version such that administrators can > > choose compatible VM images, or how does that work? > > libvirt has the concept of capabilities that it can negotiate. I know > this is used heavily with x86 cpu features that some guests depend on. > I think a guest dependency on gic version could fit here. > Sounds fair to me, but I don't know what is required to actually implement/use this for GIC support on ARM? > > > > The end goal here is to determine if we need to add any functionality to > > QEMU to better support libvirt, and what kind of features/glue need to > > be added to libvirt for this to work. > > I've been starting to wonder if we should consider breaking mach-virt > into multiple types. For example, one that focuses on big, enterprise-y > type configs (only 64-bit guests, only virtio-pci, extending the size > of main memory beyond 30G, for sure, and possibly even moving the > PCIE_MMIO_HIGH mapping to extend beyond 511G. It'd even be good to > remap the redistributor space to get more than 123 vcpus. I kind of feel that we should wait until someone says they're trying to run VMs that they cannot, which we haven't heard about yet, AFAIK. My fear with the multiple mach-virt versions is a lot of duplicated code in QEMU or at least a much more complicated board definition. Peter and QEMU developers will have better and stronger opinions on this than me though. > > Making new mach-virt types and versioning those types would probably > avoid needing much libvirt changes, but teaching libvirt (if it doesn't > know already) how to manage machine parameters to effectively create new > types as needed, also sounds good to me. > It's not clear to me if adding a new mach-virt type solves the GICv3 question or if that is an othorgonal discussion. -Christoffer -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Tue, Dec 15, 2015 at 10:36:32AM +0100, Martin Kletzander wrote: > On Mon, Dec 14, 2015 at 10:47:26AM -0600, Andrew Jones wrote: > >On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote: > >>Hi all, > >> > >>I'm trying to figure out what the correct solution for libvirt support > >>for ARM KVM guests with GICv3 is. > >> > >>The challenge is that QEMU's virt machine model defaults to GICv2 unless > >>you specify an additional "-machine gic-version=host" parameter to QEMU, > >>in which case your VM gets the same GIC version as your host. > >> > >>Now, I'm told that this is inconvenient for libvirt, because it > >>typically does not pass any -machine options, is that correct? > > > > We do pass some options, for example, you can restrict the GIC to v2: > https://libvirt.org/formatdomain.html#elementsFeatures > > That could be modified to work for your purpose IIUC, right? > How do I figure out which values the version can take (v2, v3, host?) and which QEMU cmdline that translates into? (sorry for my libvirt n00b-ness here.) Thanks, -Christoffer signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3 v2] vz: implementation of boot device order
This patch implements functionality of boot device order
based on boot element from os section in XML.
Now we support boot from CDROM and HDD.
If we have several devices of the same type (for example hdd0 and hdd1),
than we mark the first one as bootable.
---
diff from v1:
Move this commit to patch series
src/vz/vz_sdk.c | 111 +---
1 file changed, 81 insertions(+), 30 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 1fcfb2e..4cf9871 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2212,6 +2212,78 @@ prlsdkAddDeviceToBootList(PRL_HANDLE sdkdom,
return -1;
}
+static int
+prlsdkSetBootDevices(PRL_HANDLE sdkdom,
+ virDomainDefPtr def)
+{
+size_t i;
+PRL_RESULT pret;
+PRL_HANDLE devList = PRL_INVALID_HANDLE;
+PRL_HANDLE dev = PRL_INVALID_HANDLE;
+PRL_DEVICE_TYPE currentDevType, bootDevType;
+PRL_UINT32 devIndex, devCount, j;
+PRL_UINT32 bootSequence = 0;
+bool rootMount = false;
+
+pret = PrlVmCfg_GetAllDevices(sdkdom, &devList);
+prlsdkCheckRetGoto(pret, error);
+
+pret = PrlHndlList_GetItemsCount(devList, &devCount);
+prlsdkCheckRetGoto(pret, error);
+
+for (i = 0; i < def->os.nBootDevs; i++) {
+switch (def->os.bootDevs[i]) {
+case VIR_DOMAIN_BOOT_CDROM:
+bootDevType = PDE_OPTICAL_DISK;
+break;
+case VIR_DOMAIN_BOOT_DISK:
+bootDevType = PDE_HARD_DISK;
+break;
+default:
+continue;
+}
+
+for (j = 0; j < devCount; j++) {
+pret = PrlHndlList_GetItem(devList, j, &dev);
+prlsdkCheckRetGoto(pret, error);
+
+pret = PrlVmDev_GetType(dev, ¤tDevType);
+prlsdkCheckRetGoto(pret, error);
+
+if (currentDevType == bootDevType) {
+pret = PrlVmDev_GetIndex(dev, &devIndex);
+prlsdkCheckRetGoto(pret, error);
+
+if (prlsdkAddDeviceToBootList(sdkdom, devIndex,
currentDevType, bootSequence) < 0)
+goto error;
+bootSequence++;
+
+if (IS_CT(def) && !rootMount) {
+/* If we add physical device as a boot disk to container
+ we have to specify mount point for it */
+pret = PrlVmDevHd_SetMountPoint(dev, "/");
+prlsdkCheckRetGoto(pret, error);
+rootMount = true;
+}
+}
+PrlHandle_Free(dev);
+dev = PRL_INVALID_HANDLE;
+}
+}
+
+PrlHandle_Free(devList);
+return 0;
+
+ error:
+if (dev != PRL_INVALID_HANDLE)
+PrlHandle_Free(dev);
+
+if (devList != PRL_INVALID_HANDLE)
+PrlHandle_Free(devList);
+
+return -1;
+}
+
static int prlsdkCheckGraphicsUnsupportedParams(virDomainDefPtr def)
{
virDomainGraphicsDefPtr gr;
@@ -3159,9 +3231,7 @@ static int prlsdkDelDisk(PRL_HANDLE sdkdom, int idx)
}
static int prlsdkAddDisk(PRL_HANDLE sdkdom,
- virDomainDiskDefPtr disk,
- bool bootDisk,
- bool isCt)
+ virDomainDiskDefPtr disk)
{
PRL_RESULT pret;
PRL_HANDLE sdkdisk = PRL_INVALID_HANDLE;
@@ -3170,7 +3240,6 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
PRL_MASS_STORAGE_INTERFACE_TYPE sdkbus;
int idx;
virDomainDeviceDriveAddressPtr drive;
-PRL_UINT32 devIndex;
PRL_DEVICE_TYPE devType;
char *dst = NULL;
@@ -3319,21 +3388,6 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
goto cleanup;
}
-if (bootDisk) {
-pret = PrlVmDev_GetIndex(sdkdisk, &devIndex);
-prlsdkCheckRetGoto(pret, cleanup);
-
-if (prlsdkAddDeviceToBootList(sdkdom, devIndex, devType, 0) < 0)
-goto cleanup;
-
-/* If we add physical device as a boot disk to container
- * we have to specify mount point for it */
-if (isCt) {
-pret = PrlVmDevHd_SetMountPoint(sdkdisk, "/");
-prlsdkCheckRetGoto(pret, cleanup);
-}
-}
-
return 0;
cleanup:
PrlHandle_Free(sdkdisk);
@@ -3352,7 +3406,7 @@ prlsdkAttachVolume(virDomainObjPtr dom,
virDomainDiskDefPtr disk)
if (PRL_FAILED(waitJob(job)))
goto cleanup;
-ret = prlsdkAddDisk(privdom->sdkdom, disk, false, IS_CT(dom->def));
+ret = prlsdkAddDisk(privdom->sdkdom, disk);
if (ret == 0) {
job = PrlVm_CommitEx(privdom->sdkdom, PVCF_DETACH_HDD_BUNDLE);
if (PRL_FAILED(waitJob(job))) {
@@ -3490,7 +3544,7 @@ prlsdkDoApplyConfig(virConnectPtr conn,
PRL_RESULT pret;
size_t i;
char uuidstr[VIR_UUID_STRING_BUFLEN + 2];
-bool needBoot = true;
+bool rootfsFound = false;
char *mask = NULL;
if (prlsdkCheckUnsupportedParams(sdkdom, def) < 0)
@@ -3576,21 +3630,18 @@ prlsdkDoApplyConfig(virConnectPtr conn,
goto
[libvirt] [PATCH 1/3 v2] vz: allow to create container based on template
We shouldn't delete disk from default config if we create container based on
template,
because we don't have the new disk from XML, only template name.
And don't add template section from XML as new filesystem,
we use PrlVmCfg_SetOsTemplate function to set template name.
Do not set PRNVM_PRESERVE_DISK flag in PrlVm_RegEx() call,
because this will cause an error during CT startup.
---
diff from v1:
Remove unusable variable (PRL_VM_DEV_EMULATION_TYPE emul)
Add parameter useCtTemplateFs in prlsdkDoApplyConfig() function
Allow only one fs with "template" type and only for CT creation
Move this commit to patch series
src/vz/vz_sdk.c | 41 +++--
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 2b031c9..c5f8edd 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2107,12 +2107,13 @@ prlsdkCheckUnsupportedParams(PRL_HANDLE sdkdom,
virDomainDefPtr def)
return 0;
}
-static int prlsdkClearDevices(PRL_HANDLE sdkdom)
+static int prlsdkClearDevices(PRL_HANDLE sdkdom, bool skipdisk)
{
PRL_RESULT pret;
PRL_UINT32 n, i;
PRL_HANDLE devList;
PRL_HANDLE dev;
+PRL_DEVICE_TYPE devType;
int ret = -1;
pret = PrlVmCfg_SetVNCMode(sdkdom, PRD_DISABLED);
@@ -2128,6 +2129,15 @@ static int prlsdkClearDevices(PRL_HANDLE sdkdom)
pret = PrlHndlList_GetItem(devList, i, &dev);
prlsdkCheckRetGoto(pret, cleanup);
+if (skipdisk) {
+pret = PrlVmDev_GetType(dev, &devType);
+prlsdkCheckRetGoto(pret, cleanup);
+
+if (devType == PDE_HARD_DISK) {
+PrlHandle_Free(dev);
+continue;
+}
+}
pret = PrlVmDev_Remove(dev);
PrlHandle_Free(dev);
}
@@ -3470,7 +3480,8 @@ static int
prlsdkDoApplyConfig(virConnectPtr conn,
PRL_HANDLE sdkdom,
virDomainDefPtr def,
-virDomainDefPtr olddef)
+virDomainDefPtr olddef,
+bool useCtTemplateFs)
{
PRL_RESULT pret;
size_t i;
@@ -3526,7 +3537,7 @@ prlsdkDoApplyConfig(virConnectPtr conn,
}
prlsdkCheckRetGoto(pret, error);
-if (prlsdkClearDevices(sdkdom) < 0)
+if (prlsdkClearDevices(sdkdom, useCtTemplateFs) < 0)
goto error;
if (prlsdkRemoveBootDevices(sdkdom) < 0)
@@ -3554,6 +3565,12 @@ prlsdkDoApplyConfig(virConnectPtr conn,
}
for (i = 0; i < def->nfss; i++) {
+if (def->fss[i]->type == VIR_DOMAIN_FS_TYPE_TEMPLATE) {
+if(useCtTemplateFs)
+continue;
+else
+goto error;
+}
if (STREQ(def->fss[i]->dst, "/"))
needBoot = false;
if (prlsdkAddFS(sdkdom, def->fss[i]) < 0)
@@ -3602,7 +3619,7 @@ prlsdkApplyConfig(virConnectPtr conn,
if (PRL_FAILED(waitJob(job)))
return -1;
-ret = prlsdkDoApplyConfig(conn, sdkdom, new, dom->def);
+ret = prlsdkDoApplyConfig(conn, sdkdom, new, dom->def, false);
if (ret == 0) {
job = PrlVm_CommitEx(sdkdom, PVCF_DETACH_HDD_BUNDLE);
@@ -3642,7 +3659,7 @@ prlsdkCreateVm(virConnectPtr conn, virDomainDefPtr def)
pret = PrlVmCfg_SetOfflineManagementEnabled(sdkdom, 0);
prlsdkCheckRetGoto(pret, cleanup);
-ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL);
+ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL, false);
if (ret)
goto cleanup;
@@ -3665,8 +3682,9 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
PRL_HANDLE result = PRL_INVALID_HANDLE;
PRL_RESULT pret;
int ret = -1;
-int useTemplate = 0;
+bool useTemplate = false;
size_t i;
+PRL_UINT32 flags = 0;
if (def->nfss > 1) {
/* Check all filesystems */
@@ -3679,7 +3697,7 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
}
} else if (def->nfss == 1) {
if (def->fss[0]->type == VIR_DOMAIN_FS_TYPE_TEMPLATE) {
-useTemplate = 1;
+useTemplate = true;
} else if (def->fss[0]->type != VIR_DOMAIN_FS_TYPE_FILE) {
virReportError(VIR_ERR_INVALID_ARG, "%s",
_("Unsupported filesystem type."));
@@ -3704,12 +3722,15 @@ prlsdkCreateCt(virConnectPtr conn, virDomainDefPtr def)
}
-ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL);
+ret = prlsdkDoApplyConfig(conn, sdkdom, def, NULL, useTemplate);
if (ret)
goto cleanup;
-job = PrlVm_RegEx(sdkdom, "",
- PACF_NON_INTERACTIVE_MODE | PRNVM_PRESERVE_DISK);
+flags = PACF_NON_INTERACTIVE_MODE;
+if (!useTemplate)
+flags = flags | PRNVM_PRESERVE_DISK;
+
+job = PrlVm_RegEx(sdkdom, "", flags);
if (PRL_FAILED(waitJob(job)))
ret = -1;
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3 v2] vz: allow to boot VM from cdrom
If user creates virtual machine via virt-manager and select "boot from ISO"
then in libvirt we can see the following devices section
These devices don't have disk->format parameter, so we should
allow to add disks with format = VIR_STORAGE_FILE_NONE.
If user select boot from HDD and add new Cdrom device then we see
Cdrom device doesn't have disk->source parameter,
it means that user did select "attach to real device" or "use ISO".
So we should not return error if we get device with empty source path.
---
diff from v1:
Add commit description
Move this commit to patch series
src/vz/vz_sdk.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index c5f8edd..1fcfb2e 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2026,8 +2026,9 @@ prlsdkCheckUnsupportedParams(PRL_HANDLE sdkdom,
virDomainDefPtr def)
}
if (!IS_CT(def)) {
-if (def->os.nBootDevs != 1 ||
-def->os.bootDevs[0] != VIR_DOMAIN_BOOT_DISK ||
+if (def->os.nBootDevs == 0 ||
+(def->os.bootDevs[0] != VIR_DOMAIN_BOOT_DISK &&
+def->os.bootDevs[0] != VIR_DOMAIN_BOOT_CDROM) ||
def->os.init != NULL || def->os.initargv != NULL) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
@@ -3192,11 +3193,12 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
if (disk->src->type == VIR_STORAGE_TYPE_FILE) {
if (disk->device == VIR_DOMAIN_DISK_DEVICE_DISK &&
-virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_PLOOP) {
+(virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_PLOOP &&
+ virDomainDiskGetFormat(disk) != VIR_STORAGE_FILE_NONE)) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Invalid format of "
- "disk %s, vz driver
supports only "
- "images in ploop
format."), disk->src->path);
+ "disk %s, it should
be either not set or "
+ "ploop format."),
disk->src->path);
goto cleanup;
}
@@ -3218,11 +3220,13 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom,
pret = PrlVmDev_SetEmulatedType(sdkdisk, emutype);
prlsdkCheckRetGoto(pret, cleanup);
-pret = PrlVmDev_SetSysName(sdkdisk, disk->src->path);
-prlsdkCheckRetGoto(pret, cleanup);
+if (disk->src->path != NULL) {
+pret = PrlVmDev_SetSysName(sdkdisk, disk->src->path);
+prlsdkCheckRetGoto(pret, cleanup);
-pret = PrlVmDev_SetFriendlyName(sdkdisk, disk->src->path);
-prlsdkCheckRetGoto(pret, cleanup);
+pret = PrlVmDev_SetFriendlyName(sdkdisk, disk->src->path);
+prlsdkCheckRetGoto(pret, cleanup);
+}
drive = &disk->info.addr.drive;
if (drive->controller > 0) {
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] vz: allow to create CT from template and boot VM from cdrom
Mikhail Feoktistov (3): vz: allow to create container based on template vz: allow to boot VM from cdrom vz: implementation of boot device order src/vz/vz_sdk.c | 174 1 file changed, 125 insertions(+), 49 deletions(-) -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 4/4] qemu: Implement shared memory device hot-unplug
On 12/10/2015 09:43 AM, John Ferlan wrote:
On 11/26/2015 04:07 AM, Luyao Huang wrote:
Signed-off-by: Luyao Huang
---
src/qemu/qemu_driver.c | 4 ++-
src/qemu/qemu_hotplug.c | 94 -
src/qemu/qemu_hotplug.h | 3 ++
3 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 3c25c07..9e7429a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7881,6 +7881,9 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_MEMORY:
ret = qemuDomainDetachMemoryDevice(driver, vm, dev->data.memory);
break;
+case VIR_DOMAIN_DEVICE_SHMEM:
+ret = qemuDomainDetachShmemDevice(driver, vm, dev->data.shmem);
+break;
case VIR_DOMAIN_DEVICE_FS:
case VIR_DOMAIN_DEVICE_INPUT:
@@ -7892,7 +7895,6 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_SMARTCARD:
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
-case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_REDIRDEV:
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_TPM:
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index c5e544d..4ab05f3 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -3347,6 +3347,45 @@ qemuDomainRemoveRNGDevice(virQEMUDriverPtr driver,
}
+static int
+qemuDomainRemoveShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem)
+{
+virObjectEventPtr event;
+char *charAlias = NULL;
+qemuDomainObjPrivatePtr priv = vm->privateData;
+ssize_t idx;
+int rc = 0;
+
+VIR_DEBUG("Removing shared memory device %s from domain %p %s",
+ shmem->info.alias, vm, vm->def->name);
+
+if (shmem->server.enabled) {
+if (virAsprintf(&charAlias, "char%s", shmem->info.alias) < 0)
+return -1;
+
+qemuDomainObjEnterMonitor(driver, vm);
+rc = qemuMonitorDetachCharDev(priv->mon, charAlias);
+VIR_FREE(charAlias);
+if (qemuDomainObjExitMonitor(driver, vm) < 0)
+return -1;
+}
+
Auditing code?
I have removed them since i remember @Martin will finish the audit part.
+if (rc < 0)
+return -1;
+
I know this is a copy of the RemoveRNGDevice; however, this code doesn't
remove an 'obj'. In fact, if !shmem->server.enabled, then we don't enter
the monitor at all.
Thus the following event probably won't happen...
I am not sure what your mean is ... i guess your mean the device remove
event we get from qmp monitor won't happen ? we will get that event if
qemu remove shmem device success, it should always happen if qemu really
remove it and there is no bugs on qemu :)
+if ((event = virDomainEventDeviceRemovedNewFromObj(vm, shmem->info.alias)))
+qemuDomainEventQueue(driver, event);
+
+if ((idx = virDomainShmemFind(vm->def, shmem, true)) >= 0)
+virDomainShmemRemove(vm->def, idx);
+qemuDomainReleaseDeviceAddress(vm, &shmem->info, NULL);
+virDomainShmemDefFree(shmem);
+return 0;
+}
+
+
int
qemuDomainRemoveDevice(virQEMUDriverPtr driver,
virDomainObjPtr vm,
@@ -3378,6 +3417,10 @@ qemuDomainRemoveDevice(virQEMUDriverPtr driver,
ret = qemuDomainRemoveMemoryDevice(driver, vm, dev->data.memory);
break;
+case VIR_DOMAIN_DEVICE_SHMEM:
+ret = qemuDomainRemoveShmemDevice(driver, vm, dev->data.shmem);
+break;
+
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_LEASE:
case VIR_DOMAIN_DEVICE_FS:
@@ -3391,7 +3434,6 @@ qemuDomainRemoveDevice(virQEMUDriverPtr driver,
case VIR_DOMAIN_DEVICE_SMARTCARD:
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
-case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_LAST:
@@ -4378,3 +4420,53 @@ qemuDomainDetachMemoryDevice(virQEMUDriverPtr driver,
qemuDomainResetDeviceRemoval(vm);
return ret;
}
+
+
+int
+qemuDomainDetachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem)
+{
+qemuDomainObjPrivatePtr priv = vm->privateData;
+ssize_t idx;
+virDomainShmemDefPtr tmpshmem;
+int rc;
+int ret = -1;
+
+if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) {
+virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("qemu does not support -device"));
+return -1;
+}
Well it's here, but not in AttachShmemDevice...
I must forgot add it in the AttachShmemDevice, thanks for pointing out.
+
+if ((idx = virDomainShmemFind(vm->def, shmem, true)) < 0) {
Again we could use a 'flags' argument instead... Of course there isn't
a "false" argument to any of
[libvirt] [PATCH] qemuMonitorJSONEjectMedia: don't stringify the replay at all
Commit 256496e1 introduced a detection if "is locked" in error replay
from qemu monitor. Commit c4073657 fixed a memory leak, but it was
pointed out by Peter, that this could be done cleaner without
stringifing the replay.
Signed-off-by: Pavel Hrdina
---
src/qemu/qemu_monitor_json.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 4ae63cf..d4b6514 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -2223,11 +2223,12 @@ int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon,
ret = qemuMonitorJSONCheckError(cmd, reply);
if (ret < 0) {
-char *replyStr = virJSONValueToString(reply, false);
-
-if (c_strcasestr(replyStr, "is locked"))
-ret = -2;
-VIR_FREE(replyStr);
+virJSONValuePtr error = virJSONValueObjectGet(reply, "error");
+if (error) {
+const char *errorStr = virJSONValueObjectGetString(error, "desc");
+if (errorStr && c_strcasestr(errorStr, "is locked"))
+ret = -2;
+}
}
virJSONValueFree(cmd);
--
2.6.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On 15 December 2015 at 09:36, Martin Kletzander wrote: > We do pass some options, for example, you can restrict the GIC to v2: > https://libvirt.org/formatdomain.html#elementsFeatures > > That could be modified to work for your purpose IIUC, right? What does that option do to the QEMU command line? The documentation doesn't seem to say. thanks -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] pci: Use 'addr' instead of 'dev' for virPCIDeviceAddressPtr
On Tue, Dec 15, 2015 at 10:01:23AM +0100, Andrea Bolognani wrote:
The name 'dev' is more appropriate for virPCIDevicePtr.
---
src/util/virpci.c | 7 ---
src/util/virpci.h | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
ACK, trivial.
You could also fix the virPCIDeviceAddressGetIOMMUGroupNum() in the
header file, so it is the same as the .c file.
diff --git a/src/util/virpci.c b/src/util/virpci.c
index bb874ac..9cc4613 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -2655,12 +2655,13 @@ virPCIGetSysfsFile(char *virPCIDeviceName, char
**pci_sysfs_device_link)
}
int
-virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr dev,
+virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr addr,
char **pci_sysfs_device_link)
{
if (virAsprintf(pci_sysfs_device_link,
-PCI_SYSFS "devices/%04x:%02x:%02x.%x", dev->domain,
-dev->bus, dev->slot, dev->function) < 0)
+PCI_SYSFS "devices/%04x:%02x:%02x.%x",
+addr->domain, addr->bus,
+addr->slot, addr->function) < 0)
return -1;
return 0;
}
diff --git a/src/util/virpci.h b/src/util/virpci.h
index 6516f05..f3d5676 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -159,7 +159,7 @@ virPCIDeviceListPtr
virPCIDeviceGetIOMMUGroupList(virPCIDevicePtr dev);
int virPCIDeviceAddressGetIOMMUGroupAddresses(virPCIDeviceAddressPtr devAddr,
virPCIDeviceAddressPtr
**iommuGroupDevices,
size_t *nIommuGroupDevices);
-int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddressPtr dev);
+int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddressPtr addr);
char *virPCIDeviceGetIOMMUGroupDev(virPCIDevicePtr dev);
int virPCIDeviceIsAssignable(virPCIDevicePtr dev,
@@ -180,7 +180,7 @@ int virPCIGetVirtualFunctionIndex(const char
*pf_sysfs_device_link,
const char *vf_sysfs_device_link,
int *vf_index);
-int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr dev,
+int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr addr,
char **pci_sysfs_device_link);
int virPCIGetNetName(char *device_link_sysfs_path, char **netname);
--
2.5.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuMonitorJSONEjectMedia: Don't leak stringified reply
On Tue, Dec 15, 2015 at 10:17:23AM +0100, Michal Privoznik wrote: > The return value of virJSONValueToString() should be freed when > no longer needed. This is not the case after 256496e1. > > ==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of > 1,239 > ==26902==at 0x4C29F80: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so) > ==26902==by 0x552BAD9: virStrdup (virstring.c:726) > ==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790) > ==26902==by 0x1DF6EBB9: qemuMonitorJSONEjectMedia > (qemu_monitor_json.c:2225) > ==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) > ==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia > (qemu_hotplug.c:199) > ==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) > ==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) > ==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) > ==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) > ==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags > (remote_dispatch.h:10966) > > ==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of > 1,239 > ==26902==at 0x4C29F80: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so) > ==26902==by 0x552BAD9: virStrdup (virstring.c:726) > ==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790) > ==26902==by 0x1DF6EC0C: qemuMonitorJSONEjectMedia > (qemu_monitor_json.c:2227) > ==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985) > ==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia > (qemu_hotplug.c:199) > ==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985) > ==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030) > ==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677) > ==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559) > ==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags > (remote_dispatch.h:10966) > > Signed-off-by: Michal Privoznik > --- > src/qemu/qemu_monitor_json.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) ACK Jan signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] ARM KVM GICv3 Support
On Mon, Dec 14, 2015 at 10:47:26AM -0600, Andrew Jones wrote: On Mon, Dec 14, 2015 at 12:31:59PM +0100, Christoffer Dall wrote: Hi all, I'm trying to figure out what the correct solution for libvirt support for ARM KVM guests with GICv3 is. The challenge is that QEMU's virt machine model defaults to GICv2 unless you specify an additional "-machine gic-version=host" parameter to QEMU, in which case your VM gets the same GIC version as your host. Now, I'm told that this is inconvenient for libvirt, because it typically does not pass any -machine options, is that correct? We do pass some options, for example, you can restrict the GIC to v2: https://libvirt.org/formatdomain.html#elementsFeatures That could be modified to work for your purpose IIUC, right? If that is correct, then my guess is that that's because it's used to the qemu machine model automatically selecting appropriate defaults, and for pc, due to versioning, there are several machine model types to choose from. mach-virt hasn't started versioning yet. Further, there are two additional complications: First, some guest images may not include GICv3 support. For Linux, this is relatively old kernels (prior to v3.17), but other guests may only support GICv2. Second, some hardware platforms only support GICv2 guests, some only support GICv3 guests, and some support both GICv2 and GICv3 guests (those hosts with a GICv3 with the backwards compatibility support). It is unclear to me how libvirt users will relate to these constraints. For example, in an OpenStack deployment, will it somehow be easy to tell which nodes support which GIC version such that administrators can choose compatible VM images, or how does that work? libvirt has the concept of capabilities that it can negotiate. I know this is used heavily with x86 cpu features that some guests depend on. I think a guest dependency on gic version could fit here. The end goal here is to determine if we need to add any functionality to QEMU to better support libvirt, and what kind of features/glue need to be added to libvirt for this to work. I've been starting to wonder if we should consider breaking mach-virt into multiple types. For example, one that focuses on big, enterprise-y type configs (only 64-bit guests, only virtio-pci, extending the size of main memory beyond 30G, for sure, and possibly even moving the PCIE_MMIO_HIGH mapping to extend beyond 511G. It'd even be good to remap the redistributor space to get more than 123 vcpus. Making new mach-virt types and versioning those types would probably avoid needing much libvirt changes, but teaching libvirt (if it doesn't know already) how to manage machine parameters to effectively create new types as needed, also sounds good to me. Thanks, drew -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemuMonitorJSONEjectMedia: Don't leak stringified reply
On Tue, Dec 15, 2015 at 10:17:23AM +0100, Michal Privoznik wrote:
> The return value of virJSONValueToString() should be freed when
> no longer needed. This is not the case after 256496e1.
>
> ==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of
> 1,239
> ==26902==at 0x4C29F80: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
> ==26902==by 0x552BAD9: virStrdup (virstring.c:726)
> ==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790)
> ==26902==by 0x1DF6EBB9: qemuMonitorJSONEjectMedia
> (qemu_monitor_json.c:2225)
> ==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
> ==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia
> (qemu_hotplug.c:199)
> ==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
> ==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
> ==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
> ==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
> ==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags
> (remote_dispatch.h:10966)
>
> ==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of
> 1,239
> ==26902==at 0x4C29F80: malloc (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
> ==26902==by 0x552BAD9: virStrdup (virstring.c:726)
> ==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790)
> ==26902==by 0x1DF6EC0C: qemuMonitorJSONEjectMedia
> (qemu_monitor_json.c:2227)
> ==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
> ==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia
> (qemu_hotplug.c:199)
> ==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
> ==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
> ==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
> ==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
> ==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags
> (remote_dispatch.h:10966)
>
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_monitor_json.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
> index 84c0be2..4ae63cf 100644
> --- a/src/qemu/qemu_monitor_json.c
> +++ b/src/qemu/qemu_monitor_json.c
> @@ -,10 +,13 @@ int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon,
> if (ret == 0)
> ret = qemuMonitorJSONCheckError(cmd, reply);
>
> -VIR_DEBUG("%s", virJSONValueToString(reply, false));
> +if (ret < 0) {
> +char *replyStr = virJSONValueToString(reply, false);
>
> -if (ret < 0 && c_strcasestr(virJSONValueToString(reply, false), "is
> locked"))
> -ret = -2;
> +if (c_strcasestr(replyStr, "is locked"))
> +ret = -2;
> +VIR_FREE(replyStr);
> +}
>
> virJSONValueFree(cmd);
> virJSONValueFree(reply);
> --
> 2.4.10
ACK, Pavel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2 3/4] qemu: Implement share memory device hot-plug
On 12/10/2015 09:23 AM, John Ferlan wrote:
$SUBJ
s/share/shared
thanks for pointing out this
On 11/26/2015 04:06 AM, Luyao Huang wrote:
Signed-off-by: Luyao Huang
---
src/qemu/qemu_driver.c | 10 -
src/qemu/qemu_hotplug.c | 58 +
src/qemu/qemu_hotplug.h | 3 +++
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 5ded9ef..3c25c07 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -7784,6 +7784,15 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
dev->data.memory = NULL;
break;
+case VIR_DOMAIN_DEVICE_SHMEM:
+ret = qemuDomainAttachShmemDevice(driver, vm,
+ dev->data.shmem);
+if (!ret) {
+alias = dev->data.shmem->info.alias;
+dev->data.shmem = NULL;
+}
+break;
+
case VIR_DOMAIN_DEVICE_NONE:
case VIR_DOMAIN_DEVICE_FS:
case VIR_DOMAIN_DEVICE_INPUT:
@@ -7795,7 +7804,6 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
case VIR_DOMAIN_DEVICE_SMARTCARD:
case VIR_DOMAIN_DEVICE_MEMBALLOON:
case VIR_DOMAIN_DEVICE_NVRAM:
-case VIR_DOMAIN_DEVICE_SHMEM:
case VIR_DOMAIN_DEVICE_TPM:
case VIR_DOMAIN_DEVICE_PANIC:
case VIR_DOMAIN_DEVICE_LAST:
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 8804d3d..c5e544d 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1882,6 +1882,64 @@ qemuDomainAttachMemory(virQEMUDriverPtr driver,
}
It seems this is modeled after qemuDomainAttachRNGDevice, right?
Right :)
+int
+qemuDomainAttachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem)
+{
+int ret = -1;
+qemuDomainObjPrivatePtr priv = vm->privateData;
+char *devstr = NULL;
+char *charAlias = NULL;
+
+if (virAsprintf(&shmem->info.alias, "shmem%zu", vm->def->nshmems) < 0)
+return -1;
+
+if (VIR_REALLOC_N(vm->def->shmems, vm->def->nshmems + 1) < 0)
+return -1;
+
+if ((shmem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE ||
+ shmem->info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) &&
+ (virDomainPCIAddressEnsureAddr(priv->pciaddrs, &shmem->info) < 0))
+return -1;
+
+if (!(devstr = qemuBuildShmemDevStr(vm->def, shmem, priv->qemuCaps)))
+goto cleanup;
+
+if (virAsprintf(&charAlias, "char%s", shmem->info.alias) < 0)
+goto cleanup;
+
This seems to be up to a 2 stage process "if" server.enabled" is true"
Indeed, i will fix it in next version
+qemuDomainObjEnterMonitor(driver, vm);
+
+if (shmem->server.enabled &&
+qemuMonitorAttachCharDev(priv->mon, charAlias,
+ &shmem->server.chr) < 0) {
Instead of the following change to:
goto failchardev;
and the {} won't be necessary
...
Instead of the following change to
goto failadddevice;
and the {} won't be necessary
...
Again following RNG model - this should have a
if (*Exit*() < 0) {
vm = NULL;
goto cleanup
}
...
And of course the auditing change as well.
...
Following RNG the && vm would be used here... See your patch commits
'0ed3b3353' and '980b265d0'
...
failadddevice:
if (shmem->server.enabled)
ignore_value(qemuMonitorDetachCharDev(priv->mon, charAlias));
failchardev:
ignore_value(qemuDomainObjExitMonitor(driver, vm));
goto cleanup;
Nice improve, i must forgot a old problem that the &vm will be changed
after qemu unexpected exit during enter the monitor.
Hope this all makes sense (it's been a long day ;-))
Thanks a lot for your review and suggestion, and i am sorry that i
didn't reply your mails when i saw them (I'm kind of overwhelmed lately :) )
Have a nice day !
Luyao
John
+}
+
+
static int
qemuDomainAttachHostUSBDevice(virQEMUDriverPtr driver,
virDomainObjPtr vm,
diff --git a/src/qemu/qemu_hotplug.h b/src/qemu/qemu_hotplug.h
index 4140da3..60137a6 100644
--- a/src/qemu/qemu_hotplug.h
+++ b/src/qemu/qemu_hotplug.h
@@ -109,6 +109,9 @@ int qemuDomainAttachRNGDevice(virQEMUDriverPtr driver,
int qemuDomainDetachRNGDevice(virQEMUDriverPtr driver,
virDomainObjPtr vm,
virDomainRNGDefPtr rng);
+int qemuDomainAttachShmemDevice(virQEMUDriverPtr driver,
+virDomainObjPtr vm,
+virDomainShmemDefPtr shmem);
int
qemuDomainChrInsert(virDomainDefPtr vmdef,
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemuMonitorJSONEjectMedia: Don't leak stringified reply
The return value of virJSONValueToString() should be freed when
no longer needed. This is not the case after 256496e1.
==26902== 138 bytes in 2 blocks are definitely lost in loss record 1,051 of
1,239
==26902==at 0x4C29F80: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902==by 0x552BAD9: virStrdup (virstring.c:726)
==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902==by 0x1DF6EBB9: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2225)
==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags
(remote_dispatch.h:10966)
==26902== 106 bytes in 1 blocks are definitely lost in loss record 1,033 of
1,239
==26902==at 0x4C29F80: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26902==by 0xAA5F599: strdup (in /lib64/libc-2.21.so)
==26902==by 0x552BAD9: virStrdup (virstring.c:726)
==26902==by 0x54F60A7: virJSONValueToString (virjson.c:1790)
==26902==by 0x1DF6EC0C: qemuMonitorJSONEjectMedia (qemu_monitor_json.c:2227)
==26902==by 0x1DF57A4C: qemuMonitorEjectMedia (qemu_monitor.c:1985)
==26902==by 0x1DF1EF2D: qemuDomainChangeEjectableMedia (qemu_hotplug.c:199)
==26902==by 0x1DF90314: qemuDomainChangeDiskLive (qemu_driver.c:7985)
==26902==by 0x1DF90476: qemuDomainUpdateDeviceLive (qemu_driver.c:8030)
==26902==by 0x1DF91ED7: qemuDomainUpdateDeviceFlags (qemu_driver.c:8677)
==26902==by 0x561785F: virDomainUpdateDeviceFlags (libvirt-domain.c:8559)
==26902==by 0x134210: remoteDispatchDomainUpdateDeviceFlags
(remote_dispatch.h:10966)
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_monitor_json.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 84c0be2..4ae63cf 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -,10 +,13 @@ int qemuMonitorJSONEjectMedia(qemuMonitorPtr mon,
if (ret == 0)
ret = qemuMonitorJSONCheckError(cmd, reply);
-VIR_DEBUG("%s", virJSONValueToString(reply, false));
+if (ret < 0) {
+char *replyStr = virJSONValueToString(reply, false);
-if (ret < 0 && c_strcasestr(virJSONValueToString(reply, false), "is
locked"))
-ret = -2;
+if (c_strcasestr(replyStr, "is locked"))
+ret = -2;
+VIR_FREE(replyStr);
+}
virJSONValueFree(cmd);
virJSONValueFree(reply);
--
2.4.10
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] pci: Use virPCIDeviceAddress in virPCIDevice
Instead of replicating the information (domain, bus, slot, function)
inside the virPCIDevice structure, use the already-existing
virPCIDeviceAddress structure.
Outside of the module, the only visible change is that the return value
of virPCIDeviceGetAddress() must no longer be freed by the caller.
---
Changes in v2:
* use virPCIDeviceAddress instead of virPCIDeviceAddressPtr to avoid
extra allocations
src/util/virhostdev.c | 4 ---
src/util/virpci.c | 95 +++
2 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c
index de029a0..173ac58 100644
--- a/src/util/virhostdev.c
+++ b/src/util/virhostdev.c
@@ -585,7 +585,6 @@ virHostdevPreparePCIDevices(virHostdevManagerPtr
hostdev_mgr,
goto cleanup;
}
-VIR_FREE(devAddr);
if (!(devAddr = virPCIDeviceGetAddress(dev)))
goto cleanup;
@@ -728,7 +727,6 @@ virHostdevPreparePCIDevices(virHostdevManagerPtr
hostdev_mgr,
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnref(pcidevs);
-VIR_FREE(devAddr);
return ret;
}
@@ -1581,7 +1579,6 @@ virHostdevPCINodeDeviceDetach(virHostdevManagerPtr
hostdev_mgr,
out:
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
-VIR_FREE(devAddr);
return ret;
}
@@ -1613,7 +1610,6 @@ virHostdevPCINodeDeviceReAttach(virHostdevManagerPtr
hostdev_mgr,
out:
virObjectUnlock(hostdev_mgr->inactivePCIHostdevs);
virObjectUnlock(hostdev_mgr->activePCIHostdevs);
-VIR_FREE(devAddr);
return ret;
}
diff --git a/src/util/virpci.c b/src/util/virpci.c
index bececb5..bb874ac 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -56,10 +56,7 @@ VIR_ENUM_IMPL(virPCIELinkSpeed, VIR_PCIE_LINK_SPEED_LAST,
"", "2.5", "5", "8")
struct _virPCIDevice {
-unsigned int domain;
-unsigned int bus;
-unsigned int slot;
-unsigned int function;
+virPCIDeviceAddress address;
char name[PCI_ADDR_LEN]; /* domain:bus:slot.function */
char id[PCI_ID_LEN]; /* product vendor */
@@ -655,10 +652,10 @@ virPCIDeviceSharesBusWithActive(virPCIDevicePtr dev,
virPCIDevicePtr check, void
virPCIDeviceList *inactiveDevs = data;
/* Different domain, different bus, or simply identical device */
-if (dev->domain != check->domain ||
-dev->bus != check->bus ||
-(dev->slot == check->slot &&
- dev->function == check->function))
+if (dev->address.domain != check->address.domain ||
+dev->address.bus != check->address.bus ||
+(dev->address.slot == check->address.slot &&
+ dev->address.function == check->address.function))
return 0;
/* same bus, but inactive, i.e. about to be assigned to guest */
@@ -689,7 +686,7 @@ virPCIDeviceIsParent(virPCIDevicePtr dev, virPCIDevicePtr
check, void *data)
int ret = 0;
int fd;
-if (dev->domain != check->domain)
+if (dev->address.domain != check->address.domain)
return 0;
if ((fd = virPCIDeviceConfigOpen(check, false)) < 0)
@@ -713,7 +710,7 @@ virPCIDeviceIsParent(virPCIDevicePtr dev, virPCIDevicePtr
check, void *data)
/* if the secondary bus exactly equals the device's bus, then we found
* the direct parent. No further work is necessary
*/
-if (dev->bus == secondary) {
+if (dev->address.bus == secondary) {
ret = 1;
goto cleanup;
}
@@ -722,10 +719,12 @@ virPCIDeviceIsParent(virPCIDevicePtr dev, virPCIDevicePtr
check, void *data)
* In this case, what we need to do is look for the "best" match; i.e.
* the most restrictive match that still satisfies all of the conditions.
*/
-if (dev->bus > secondary && dev->bus <= subordinate) {
+if (dev->address.bus > secondary && dev->address.bus <= subordinate) {
if (*best == NULL) {
-*best = virPCIDeviceNew(check->domain, check->bus, check->slot,
-check->function);
+*best = virPCIDeviceNew(check->address.domain,
+check->address.bus,
+check->address.slot,
+check->address.function);
if (*best == NULL) {
ret = -1;
goto cleanup;
@@ -745,8 +744,10 @@ virPCIDeviceIsParent(virPCIDevicePtr dev, virPCIDevicePtr
check, void *data)
if (secondary > best_secondary) {
virPCIDeviceFree(*best);
-*best = virPCIDeviceNew(check->domain, check->bus, check->slot,
-check->function);
+*best = virPCIDeviceNew(check->address.domain,
+check->address.bus,
+
[libvirt] [PATCH] pci: Use 'addr' instead of 'dev' for virPCIDeviceAddressPtr
The name 'dev' is more appropriate for virPCIDevicePtr.
---
src/util/virpci.c | 7 ---
src/util/virpci.h | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index bb874ac..9cc4613 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -2655,12 +2655,13 @@ virPCIGetSysfsFile(char *virPCIDeviceName, char
**pci_sysfs_device_link)
}
int
-virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr dev,
+virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr addr,
char **pci_sysfs_device_link)
{
if (virAsprintf(pci_sysfs_device_link,
-PCI_SYSFS "devices/%04x:%02x:%02x.%x", dev->domain,
-dev->bus, dev->slot, dev->function) < 0)
+PCI_SYSFS "devices/%04x:%02x:%02x.%x",
+addr->domain, addr->bus,
+addr->slot, addr->function) < 0)
return -1;
return 0;
}
diff --git a/src/util/virpci.h b/src/util/virpci.h
index 6516f05..f3d5676 100644
--- a/src/util/virpci.h
+++ b/src/util/virpci.h
@@ -159,7 +159,7 @@ virPCIDeviceListPtr
virPCIDeviceGetIOMMUGroupList(virPCIDevicePtr dev);
int virPCIDeviceAddressGetIOMMUGroupAddresses(virPCIDeviceAddressPtr devAddr,
virPCIDeviceAddressPtr
**iommuGroupDevices,
size_t *nIommuGroupDevices);
-int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddressPtr dev);
+int virPCIDeviceAddressGetIOMMUGroupNum(virPCIDeviceAddressPtr addr);
char *virPCIDeviceGetIOMMUGroupDev(virPCIDevicePtr dev);
int virPCIDeviceIsAssignable(virPCIDevicePtr dev,
@@ -180,7 +180,7 @@ int virPCIGetVirtualFunctionIndex(const char
*pf_sysfs_device_link,
const char *vf_sysfs_device_link,
int *vf_index);
-int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr dev,
+int virPCIDeviceAddressGetSysfsFile(virPCIDeviceAddressPtr addr,
char **pci_sysfs_device_link);
int virPCIGetNetName(char *device_link_sysfs_path, char **netname);
--
2.5.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
