[libvirt] ANNOUNCE: Oz 0.16.0 release
by Chris Lalancette
All,
I'm pleased to announce release 0.16.0 of Oz. Oz is a program for
doing automated installation of guest operating systems with limited input
from the user. Release 0.16.0 is a bugfix and feature release for Oz.
Some of the highlights between Oz 0.15.0 and 0.16.0 are:
* Windows 10 and 2016 support
* All timeouts are now configurable
* Ubuntu 16.04, 16.10, 17.04 support
* Mageia 2, 3, 4, 5 support
* Properly find UEFI firmware, which should fix aarch64 installs
* Fedora 24, 25, 26 support
* FreeBSD 11 support
* Replace internal use of pycurl with requests
* OpenSUSE Leap support
* Timeouts are now based on time, not the number of iterations of the loop
* Modern Fedora and RHEL guests will print out a lot more anaconda
debugging information to the terminal that oz-install was launched from
A tarball and zipfile of this release is available on the Github releases
page: https://github.com/clalancette/oz/releases . Packages for Fedora
rawhide and 26 have been built in Koji and will eventually make their way
to stable. Instructions on how to get and use Oz are available at
http://github.com/clalancette/oz/wiki .
If you have questions or comments about Oz, please feel free to contact me
at clalancette at gmail.com, or open up an issue on the github page:
http://github.com/clalancette/oz/issues .
Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.
Chris Lalancette
7 years, 4 months
[libvirt] [PATCH] docs: Add "PCI topology and hotplug" guidelines
by Andrea Bolognani
For all machine types except i440fx, making a guest hotplug
capable requires some sort of planning. Add some information
to help users make educated choices when defining the PCI
topology of guests.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
docs/formatdomain.html.in | 4 +-
docs/pci-hotplug.html.in | 164 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 docs/pci-hotplug.html.in
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index bceddd2..7c4450c 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -3505,7 +3505,9 @@
appear more than once, with a group of virtual devices tied to a
virtual controller. Normally, libvirt can automatically infer such
controllers without requiring explicit XML markup, but sometimes
- it is necessary to provide an explicit controller element.
+ it is necessary to provide an explicit controller element, notably
+ when planning the <a href="pci-hotplug.html">PCI topology</a>
+ for guests where device hotplug is expected.
</p>
<pre>
diff --git a/docs/pci-hotplug.html.in b/docs/pci-hotplug.html.in
new file mode 100644
index 0000000..f3d1610
--- /dev/null
+++ b/docs/pci-hotplug.html.in
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <body>
+ <h1>PCI topology and hotplug</h1>
+
+ <ul id="toc"></ul>
+
+ <p>
+ Perhaps surprisingly, most libvirt guests support only limited PCI
+ device hotplug out of the box, or even none at all.
+ </p>
+ <p>
+ The reason for this apparent limitation is the fact that each
+ hotplugged PCI device might require additional PCI controllers to
+ be added to the guest, and libvirt has no way of knowing in advance
+ how many devices will be hotplugged during the guest's lifetime,
+ thus making it impossible to automatically provide the right amount
+ of PCI controllers: any arbitrary number would end up being too big
+ for some users, and too small for others.
+ </p>
+ <p>
+ Ultimately, the user is the only one who knows how much the guest
+ will need to grow dynamically, so the responsability of planning
+ a suitabile PCI topology in advance falls on them.
+ </p>
+ <p>
+ This document aims at providing all the information needed to
+ successfully plan the PCI topology of a guest. Note that the
+ details can vary a lot between architectures and even machine
+ types, hence the way it's organized.
+ </p>
+
+ <h2><a name="x86_64">x86_64 architecture</a></h2>
+
+ <h3><a name="x86_64-q35">q35 machine type</a></h3>
+
+ <p>
+ This is a PCI Express native machine type. The default PCI topology
+ looks like
+ </p>
+
+<pre>
+<controller type='pci' index='0' model='pcie-root'/>
+<controller type='pci' index='1' model='pcie-root-port'>
+ <model name='pcie-root-port'/>
+ <target chassis='1' port='0x10'/>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
+</controller></pre>
+
+ <p>
+ and supports hotplugging a single PCI Express device, either
+ emulated or assigned from the host.
+ </p>
+ <p>
+ Slots on the <code>pcie-root</code> controller do not support
+ hotplug, so the device will be hotplugged into the
+ <code>pcie-root-port</code> controller. If you plan to hotplug
+ more than a single PCI Express device, you should add a suitable
+ number of <code>pcie-root-port</code> controllers when defining
+ the guest: for example, add
+ </p>
+
+<pre>
+<controller type='pci' model='pcie-root-port'/>
+<controller type='pci' model='pcie-root-port'/>
+<controller type='pci' model='pcie-root-port'/></pre>
+
+ <p>
+ if you expect to hotplug up to three PCI Express devices,
+ either emulated or assigned from the host. That's all the
+ information you need to provide: libvirt will fill in the
+ remaining details automatically.
+ </p>
+ <p>
+ If you expect to hotplug legacy PCI devices, then you will need
+ specialized controllers, since all those mentioned above are
+ intended for PCI Express devices only: add
+ </p>
+
+<pre>
+<controller type='pci' model='dmi-to-pci-bridge'/>
+<controller type='pci' model='pci-bridge'/></pre>
+
+ <p>
+ and you'll be able to hotplug up to 31 legacy PCI devices,
+ either emulated or assigned from the host.
+ </p>
+
+ <h3><a name="x86_64-i440fx">i440fx (pc) machine type</a></h3>
+
+ <p>
+ This is a legacy PCI native machine type. The default PCI
+ topology looks like
+ </p>
+
+<pre>
+<controller type='pci' index='0' model='pci-root'/></pre>
+
+ <p>
+ where each of the 31 slots on the <code>pci-root</code>
+ controller is hotplug capable and can accept a legacy PCI
+ device, either emulated or assigned from the guest.
+ </p>
+
+ <h2><a name="ppc64">ppc64 architecture</a></h2>
+
+ <h3><a name="ppc64-pseries">pseries machine type</a></h3>
+
+ <p>
+ The default PCI topology for the <code>pseries</code> machine
+ type looks like
+ </p>
+
+<pre>
+<controller type='pci' index='0' model='pcie-root'>
+ <model name='spapr-pci-host-bridge'/>
+ <target index='0'/>
+</controller></pre>
+
+ <p>
+ The 31 slots on a <code>pci-root</code> controller are all
+ hotplug capable and, despite the name suggesting otherwise,
+ starting with QEMU 2.9 all of them can accept PCI Express
+ devices in addition to legacy PCI devices; however,
+ libvirt will only place emulated devices on the default
+ <code>pci-root</code> controller.
+ </p>
+ <p>
+ In order to take advantage of improved error reporting and
+ recovering capabilities, PCI devices assigned from the
+ host need to be isolated by placing each on a separate
+ <code>pci-root</code> controller, which has to be prepared
+ in advance for hotplug to work: for example, add
+ </p>
+
+<pre>
+<controller type='pci' model='pci-root'/>
+<controller type='pci' model='pci-root'/>
+<controller type='pci' model='pci-root'/></pre>
+
+ <p>
+ if you expect to hotplug up to three PCI devices assigned
+ from the host.
+ </p>
+
+ <h2><a name="aarch64">aarch64 architecture</a></h2>
+
+ <h3><a name="aarch64-virt">mach-virt (virt) machine type</a></h3>
+
+ <p>
+ This machine type mostly behaves the same as the
+ <a href="#x86_64-q35">q35 machine type</a>, so you can just
+ refer to that section for information.
+ </p>
+ <p>
+ The only difference worth mentioning is that using legacy
+ PCI for <code>mach-virt</code> guests is extremely uncommon,
+ so you'll probably never need to add controllers other than
+ <code>pcie-root-port</code>.
+ </p>
+
+ </body>
+</html>
--
2.7.5
7 years, 4 months
Re: [libvirt] [RFC]Add new mdev interface for QoS
by Alex Williamson
[cc +libvir-list]
On Wed, 26 Jul 2017 21:16:59 +0800
"Gao, Ping A" <ping.a.gao(a)intel.com> wrote:
> The vfio-mdev provide the capability to let different guest share the
> same physical device through mediate sharing, as result it bring a
> requirement about how to control the device sharing, we need a QoS
> related interface for mdev to management virtual device resource.
>
> E.g. In practical use, vGPUs assigned to different quests almost has
> different performance requirements, some guests may need higher priority
> for real time usage, some other may need more portion of the GPU
> resource to get higher 3D performance, corresponding we can define some
> interfaces like weight/cap for overall budget control, priority for
> single submission control.
>
> So I suggest to add some common attributes which are vendor agnostic in
> mdev core sysfs for QoS purpose.
I think what you're asking for is just some standardization of a QoS
attribute_group which a vendor can optionally include within the
existing mdev_parent_ops.mdev_attr_groups. The mdev core will
transparently enable this, but it really only provides the standard,
all of the support code is left for the vendor. I'm fine with that,
but of course the trouble with and sort of standardization is arriving
at an agreed upon standard. Are there QoS knobs that are generic
across any mdev device type? Are there others that are more specific
to vGPU? Are there existing examples of this that we can steal their
specification?
Also, mdev devices are not necessarily the exclusive users of the
hardware, we can have a native user such as a local X client. They're
not an mdev user, so we can't support them via the mdev_attr_group.
Does there need to be a per mdev parent QoS attribute_group standard
for somehow defining the QoS of all the child mdev devices, or perhaps
representing the remaining host QoS attributes?
Ultimately libvirt and upper level management tools would be the
consumer of these control knobs, so let's immediately get libvirt
involved in the discussion. Thanks,
Alex
7 years, 4 months
[libvirt] [PATCH] docs: force content in <script> element
by Daniel P. Berrange
If there's no content in <script></script>, the XSTL generator
will turn it into <script/> which is not permitted in XHTML.
Adding a single whitespace is enough to guarantee an explicit
closing tag. Without this, the scripts never get loaded by
the browser.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Pushed as trivial fix
docs/index.html.in | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/index.html.in b/docs/index.html.in
index 8333cf6bb..c0c55cb14 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -2,9 +2,9 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <script type="text/javascript" src="js/jquery-3.1.1.min.js"></script>
- <script type="text/javascript" src="js/moment.min.js"></script>
- <script type="text/javascript" src="js/jquery.rss.min.js"></script>
+ <script type="text/javascript" src="js/jquery-3.1.1.min.js"> </script>
+ <script type="text/javascript" src="js/moment.min.js"> </script>
+ <script type="text/javascript" src="js/jquery.rss.min.js"> </script>
<script type="text/javascript">
<!--
--
2.13.3
7 years, 4 months
[libvirt] [PATCH] conf: check rombar against VIR_DOMAIN_TRISTATE_SWITCH_ABSENT
by Ján Tomko
Make the comparison explicit.
---
src/conf/domain_conf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 3cdb5e348..b5ce2ecd9 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -5359,10 +5359,10 @@ virDomainDeviceInfoFormat(virBufferPtr buf,
}
if ((flags & VIR_DOMAIN_DEF_FORMAT_ALLOW_ROM) &&
- (info->rombar || info->romfile)) {
+ (info->rombar != VIR_TRISTATE_SWITCH_ABSENT || info->romfile)) {
virBufferAddLit(buf, "<rom");
- if (info->rombar) {
+ if (info->rombar != VIR_TRISTATE_SWITCH_ABSENT) {
const char *rombar = virTristateSwitchTypeToString(info->rombar);
if (rombar)
--
2.13.0
7 years, 4 months
[libvirt] RFC: support for configuring all ports of a multiport SRIOV VF when assigning to guest
by Laine Stump
("No matter how far you've gone down the wrong road, turn back." -
paraphrase of a Turkish proverb that is apropos to this discussion)
Several years ago, when I was apparently naive and narrow in my thinking
and someone wanted us support setting the MAC address and vlan tag for
SRIOV VFs when assigning them to a guest with PCI device assignment
(this was before VFIO existed), I had the idea to do this by creating a
new type of <interface> device:
<interface type='hostdev'>
....
My thinking was that <interface> already had elements for mac address,
802.11Qb[gh] virtualport config, and vlan tag (or maybe it was that we
were *going to add* support for vlan tag), so by just adding a <source>
that was a PCI address, we would have everything we needed. Basically,
there is some amount of config that needs to be applied to the device
before it's assigned to the guest, and since the device ends up being a
netdev in the guest, all that config is already present in an
<interface>. As a bonus, because it was an <interface> we could easily
re-use the recently added "pool of devices" network type (with some
minor adjustment) to avoid needing to hardcode the host-side PCI address
of the VF.
At the time Dan Berrange countered (I think - correct me if I'm wrong!)
that we should instead do this with modifications to <hostdev>, but
somehow I managed to either convince him, or maybe he just finally tired
of my stubbornness and decided it was easier to deal with the after
effects of giving in rather than continuing to debate with me :-)
So right now if you want to assign an SRIOV VF network device to a guest
with VFIO, you need something like this (ignoring network device pools
for the moment):
<interface type='hostdev'>
<source>
<address type='pci' slot='0x08' function='0x4'/>
</source>
<mac address='52:54:00:01:01:01'/>
<vlan>
<tag id='42'/>
</vlan>
</interface>
(or in place of <vlan>, you could have a <virtualport> element for
802.11Qb[gh]).
The SRIOV cards that we had around when we were doing this work had
multiple physical ports on them (either 2 or 4), but each physical port
was associated with its own PCI Physical Function (PF), and each of the
PCI Virtual Functions associated with a PF was tied to a single netdev,
i.e. in all cases there was always a 1:1 correspondence between a netdev
and a PCI device. All of libvirt's code dealing with SRIOV VFs and PFs
assumes this 1:1 relationship.
And then came Mellanox "dual port" SRIOV cards....
A Mellanox SRIOV NIC doesn't necessarily do that. Instead, it can
operate in "dual port" mode, where it has a single PCI PF device for
both physical ports; the single PF PCI device has 2 separate netdevs
associated with it (so when you look in the "net" subdirectory for the
PCI device, you'll see two netdevs listed, and when you look in the
"device" subdirectory of those two netdevs in sysfs, they both point
back to the same PCI device). VFs associated with that PF will also each
have two netdevs associated with them. This means that when you assign a
VF to a guest, the guest is getting a single PCI device, but it's
getting two netdevs. (I've been told that the advantage of doing both
ports with a single PCI device is that each Mellanox PCI device uses a
huge amount of MMIO space, two ports on each device cuts the MMIO usage
in half).
In order for this to be useful, libvirt needs to set the mac address and
vlan tag of *both* netdevs prior to starting the guest. But we have no
way to represent that in our configuration. In the past it's been
suggested that we just do something like this:
<interface type='hostdev'>
<mac address='blah'/>
<mac2 address='blah'/>
...
</interface>
but I have two problems with that:
1) <interface> is supposed to represent a single network device, but
this is trying to make it represent 2 network devices (and what if
someone else comes up with a card that puts *4* netdevs on the same PCI
device?)
2) We would need to do the same thing for <vlan> tag. It starts to get ugly.
Alternately we could add a new <port number='2'> subelement, like this:
<interface type='hostdev'>
<source>
<address type='pci' slot='0x08' function='0x4'/>
</source>
<mac address='52:54:00:01:01:01'/>
<vlan>
<tag id='42'/>
</vlan>
<port number='2'>
<mac address='52:54:00:01:01:01'/>
<vlan>
<tag id='42'/>
</vlan>
</port>
</interface>
(or some variation of that) just so that all the stuff for the 2nd port
is grouped together. But I don't like that the config for port 1 is at a
different level in the hierarchy than the config for port 2, and we
still have the problem that we're trying to describe *2* netdevs with a
single <interface> element, which just feels wrong.
- OR -
what if we admit that <interface type='hostdev'> was a bad idea, and try
doing it all with <hostdev>, something like this:
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x06' slot='0x02' function='0x0'/>
</source>
<netdev port='1'>
<mac address='52:54:00:01:02:03'/>
<vlan>
<tag id='42'/>
</vlan>
</netdev>
<netdev port='2'>
<mac address='52:54:00:01:02:03'/>
<vlan>
<tag id='43'/>
</vlan>
</netdev>
</hostdev>
The downsides are:
1) It's providing a 2nd way of describing single port VFs, which could
confuse people (my recommendation would be to deprecate usage of
<interface type='hostdev'> in the documentation, while still allowing
it; i.e. we'd still have to maintain that code while discouraging its use).
2) This wouldn't be able to take advantage of the pools of devices
maintained by libvirt networks. (This isn't a problem for Openstack,
since they don't use that anyway, but ovirt does use it).
3) It's an explicit admission that I made a bad decision in 2011 :-P
The upsides?
1) it models the hardware more correctly. (it really is a PCI device
that has two subordinate netdevs, *not* a netdev that is part of a PCI
device, "oh and that PCI device also has another netdev")
2) it could be more logically and easily expanded if there were more
ports, or if there were other types of PCI devices that had different
kinds of device-type-specific config that needed to be setup.
3) we could eliminate "downside (2)" by enhancing the nodedevice driver
to provide and manage more generalized pools of devices (if desired by
anyone - Openstack's opinion seems to be that libvirt shouldn't be doing
this anyway).
So does anyone have an opinion about this? An alternate proposal? (e.g.
Should we instead just tell everyone to run their Mellanox cards in
single port mode and ignore/avoid all this complexity?)
7 years, 4 months
[libvirt] A bug that libvirt lxc can't destroy all container process.
by 曹远志
Hello all,
This is my first mail to this list, so let me introduce myself. My name is yuanzhi cao, and I work in the oVirt team. Currently We are using libvirt lxc in large-scale and found that libvirt can't destroy container process normally .
Environments:
System: zesty
libvirt version: 2.5.0-3ubuntu5
vm rootfs release: ubuntu:16.04
Reproduce:
1. Run command "virsh -c lxc:// start vm" and the release of vm is xenial
2. Run command "pa aux|grep init" ,you would find the pid of init launch by vm.
3. Run command "virsh -c lxc:// destroy vm".
4. Run command "virsh -c lxc:// list --all" and "ps aux|grep init" ,you could find that vm is shutoff, but the init process launch by vm is still running.
Infact I have found the case of this bug, there is a patch after 1.3.1 that import this bug.
-------------------------------------------------------------
Commit: dc576025c360a1d2c89da410d0f3f0da55d0143f [dc57602]
Parents: 511e7c5bba
Author: Daniel P. Berrange <berrange(a)redhat.com>
Date: 2016年1月23日 GMT+8 上午12:07:18
Commit Date: 2016年1月27日 GMT+8 上午12:11:32
lxc: don't try to hide parent cgroups inside container
-------------------------------------------------------------
Cgroups inside container does't hide parent, so the process of container can change it own cgroup to another cgroup.
lxc destroy process by read cgroup tasks file,if process change it own cgroup,it can't destroy container process normally.
7 years, 4 months
[libvirt] [PATCH] hyperv: Reduce usage of libxml API functions
by Sri Ramanujam
Slight refactor of the WMI serialization code to minimize mixing
openwsman and libxml2 APIs. The only usage of libxml2 APIs now is in
creating CDATA blocks, because the openwsman API does not provide that
functionality.
---
src/hyperv/hyperv_wmi.c | 65 ++++++++++++-------------------------------------
1 file changed, 16 insertions(+), 49 deletions(-)
diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c
index 57125ae..99efa1c 100644
--- a/src/hyperv/hyperv_wmi.c
+++ b/src/hyperv/hyperv_wmi.c
@@ -489,17 +489,14 @@ hypervSerializeSimpleParam(hypervParamPtr p, const char *resourceUri,
static int
hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv,
- const char *resourceUri, WsXmlDocH doc, WsXmlNodeH *methodNode)
+ const char *resourceUri, WsXmlNodeH *methodNode)
{
int result = -1;
WsXmlNodeH xmlNodeParam = NULL,
xmlNodeTemp = NULL,
xmlNodeAddr = NULL,
xmlNodeRef = NULL;
- xmlNodePtr xmlNodeAddrPtr = NULL,
- xmlNodeRefPtr = NULL;
WsXmlDocH xmlDocResponse = NULL;
- xmlDocPtr docPtr = (xmlDocPtr) doc->parserDoc;
WsXmlNsH ns = NULL;
client_opt_t *options = NULL;
filter_t *filter = NULL;
@@ -573,11 +570,6 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv,
goto cleanup;
}
- if (!(xmlNodeAddrPtr = xmlDocCopyNode((xmlNodePtr) xmlNodeAddr, docPtr, 1))) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Could not copy EPR address"));
- goto cleanup;
- }
-
if (!(xmlNodeRef = ws_xml_get_child(xmlNodeTemp, 0, XML_NS_ADDRESSING,
WSA_REFERENCE_PARAMETERS))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
@@ -585,17 +577,11 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv,
goto cleanup;
}
- if (!(xmlNodeRefPtr = xmlDocCopyNode((xmlNodePtr) xmlNodeRef, docPtr, 1))) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not copy EPR item reference parameters"));
- goto cleanup;
- }
-
/* now build a new xml doc with the EPR node children */
if (!(xmlNodeParam = ws_xml_add_child(*methodNode, resourceUri,
p->epr.name, NULL))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not add child node to xmlNodeParam"));
+ _("Could not add child node to methodNode"));
goto cleanup;
}
@@ -613,23 +599,8 @@ hypervSerializeEprParam(hypervParamPtr p, hypervPrivate *priv,
goto cleanup;
}
- if (xmlAddChild((xmlNodePtr) *methodNode, (xmlNodePtr) xmlNodeParam) == NULL) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not add child to xml parent node"));
- goto cleanup;
- }
-
- if (xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeAddrPtr) == NULL) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not add child to xml parent node"));
- goto cleanup;
- }
-
- if (xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeRefPtr) == NULL) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not add child to xml parent node"));
- goto cleanup;
- }
+ ws_xml_duplicate_tree(xmlNodeParam, xmlNodeAddr);
+ ws_xml_duplicate_tree(xmlNodeParam, xmlNodeRef);
/* we did it! */
result = 0;
@@ -656,8 +627,7 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri,
xmlNodeArray = NULL;
WsXmlDocH xmlDocTemp = NULL,
xmlDocCdata = NULL;
- xmlBufferPtr xmlBufferNode = NULL;
- const xmlChar *xmlCharCdataContent = NULL;
+ char *xmlCharCdataContent = NULL;
xmlNodePtr xmlNodeCdata = NULL;
hypervWmiClassInfoPtr classInfo = p->embedded.info;
virHashKeyValuePairPtr items = NULL;
@@ -761,25 +731,22 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri,
}
/* create CDATA node */
- xmlBufferNode = xmlBufferCreate();
- if (xmlNodeDump(xmlBufferNode, (xmlDocPtr) xmlDocTemp->parserDoc,
- (xmlNodePtr) xmlNodeInstance, 0, 0) < 0) {
- virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
- _("Could not get root of temp XML doc"));
- goto cleanup;
- }
+ ws_xml_dump_memory_node_tree(xmlNodeInstance, &xmlCharCdataContent, &len);
- len = xmlBufferLength(xmlBufferNode);
- xmlCharCdataContent = xmlBufferContent(xmlBufferNode);
if (!(xmlNodeCdata = xmlNewCDataBlock((xmlDocPtr) xmlDocCdata,
- xmlCharCdataContent, len))) {
+ (xmlChar *)xmlCharCdataContent, len))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Could not create CDATA element"));
goto cleanup;
}
- /* Add CDATA node to the doc root */
- if (!(xmlAddChild((xmlNodePtr) xmlNodeParam, xmlNodeCdata))) {
+ /*
+ * Add CDATA node to the doc root
+ *
+ * FIXME: there is no openwsman wrapper for xmlNewCDataBlock, so instead
+ * silence clang by casting to a void pointer first
+ */
+ if (!(xmlAddChild((xmlNodePtr)(void *)xmlNodeParam, xmlNodeCdata))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Could not add CDATA to doc root"));
goto cleanup;
@@ -792,7 +759,7 @@ hypervSerializeEmbeddedParam(hypervParamPtr p, const char *resourceUri,
VIR_FREE(items);
ws_xml_destroy_doc(xmlDocCdata);
ws_xml_destroy_doc(xmlDocTemp);
- xmlBufferFree(xmlBufferNode);
+ ws_xml_free_memory(xmlCharCdataContent);
return result;
}
@@ -854,7 +821,7 @@ hypervInvokeMethod(hypervPrivate *priv, hypervInvokeParamsListPtr params,
break;
case HYPERV_EPR_PARAM:
if (hypervSerializeEprParam(p, priv, params->resourceUri,
- paramsDocRoot, &methodNode) < 0)
+ &methodNode) < 0)
goto cleanup;
break;
case HYPERV_EMBEDDED_PARAM:
--
2.9.4
7 years, 4 months
[libvirt] [PATCH] hyperv: Correct number of milliseconds in five minutes
by Sri Ramanujam
---
src/hyperv/hyperv_wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hyperv/hyperv_wmi.c b/src/hyperv/hyperv_wmi.c
index 57125ae..33ad964 100644
--- a/src/hyperv/hyperv_wmi.c
+++ b/src/hyperv/hyperv_wmi.c
@@ -42,7 +42,7 @@
#define VIR_FROM_THIS VIR_FROM_HYPERV
-#define HYPERV_JOB_TIMEOUT_MS 5000
+#define HYPERV_JOB_TIMEOUT_MS 300000
VIR_LOG_INIT("hyperv.hyperv_wmi");
--
2.9.4
7 years, 4 months
[libvirt] [PATCH] introduce virConfReadString
by Ján Tomko
Rewrite virConfReadMem to take a null-terminated string.
All the callers were calling strlen on it anyway.
---
daemon/libvirtd-config.c | 2 +-
src/libvirt_private.syms | 2 +-
src/libxl/libxl_driver.c | 4 ++--
src/lxc/lxc_native.c | 2 +-
src/util/virconf.c | 16 ++++++++--------
src/util/virconf.h | 4 ++--
src/vmx/vmx.c | 4 ++--
src/xen/xen_driver.c | 2 +-
tests/virconftest.c | 8 ++++----
tests/xlconfigtest.c | 2 +-
tests/xmconfigtest.c | 2 +-
11 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/daemon/libvirtd-config.c b/daemon/libvirtd-config.c
index 6c0f00ed8..db283a41f 100644
--- a/daemon/libvirtd-config.c
+++ b/daemon/libvirtd-config.c
@@ -433,7 +433,7 @@ int daemonConfigLoadData(struct daemonConfig *data,
virConfPtr conf;
int ret;
- conf = virConfReadMem(filedata, strlen(filedata), 0);
+ conf = virConfReadString(filedata, 0);
if (!conf)
return -1;
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 32ac0835e..183a9194d 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1520,7 +1520,7 @@ virConfGetValueULLong;
virConfLoadConfig;
virConfNew;
virConfReadFile;
-virConfReadMem;
+virConfReadString;
virConfSetValue;
virConfTypeFromString;
virConfTypeToString;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 907f1776f..c261e2155 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -2605,14 +2605,14 @@ libxlConnectDomainXMLFromNative(virConnectPtr conn,
goto cleanup;
if (STREQ(nativeFormat, XEN_CONFIG_FORMAT_XL)) {
- if (!(conf = virConfReadMem(nativeConfig, strlen(nativeConfig), 0)))
+ if (!(conf = virConfReadString(nativeConfig, 0)))
goto cleanup;
if (!(def = xenParseXL(conf,
cfg->caps,
driver->xmlopt)))
goto cleanup;
} else if (STREQ(nativeFormat, XEN_CONFIG_FORMAT_XM)) {
- if (!(conf = virConfReadMem(nativeConfig, strlen(nativeConfig), 0)))
+ if (!(conf = virConfReadString(nativeConfig, 0)))
goto cleanup;
if (!(def = xenParseXM(conf,
diff --git a/src/lxc/lxc_native.c b/src/lxc/lxc_native.c
index 7bcdf1fb0..5fc6e7cda 100644
--- a/src/lxc/lxc_native.c
+++ b/src/lxc/lxc_native.c
@@ -1000,7 +1000,7 @@ lxcParseConfigString(const char *config,
virConfPtr properties = NULL;
virConfValuePtr value;
- if (!(properties = virConfReadMem(config, 0, VIR_CONF_FLAG_LXC_FORMAT)))
+ if (!(properties = virConfReadString(config, VIR_CONF_FLAG_LXC_FORMAT)))
return NULL;
if (!(vmdef = virDomainDefNew()))
diff --git a/src/util/virconf.c b/src/util/virconf.c
index c1f41b7e1..e505848f1 100644
--- a/src/util/virconf.c
+++ b/src/util/virconf.c
@@ -807,27 +807,27 @@ virConfReadFile(const char *filename, unsigned int flags)
}
/**
- * virConfReadMem:
+ * virConfReadString:
* @memory: pointer to the content of the configuration file
- * @len: length in byte
* @flags: combination of virConfFlag(s)
*
- * Reads a configuration file loaded in memory. The string can be
- * zero terminated in which case @len can be 0
+ * Reads a configuration file loaded in memory. The string must be
+ * zero terminated.
*
* Returns a handle to lookup settings or NULL if it failed to
* parse the content, use virConfFree() to free the data.
*/
virConfPtr
-virConfReadMem(const char *memory, int len, unsigned int flags)
+virConfReadString(const char *memory, unsigned int flags)
{
- if ((memory == NULL) || (len < 0)) {
+ size_t len;
+
+ if (memory == NULL) {
virConfError(NULL, VIR_ERR_INVALID_ARG, __FUNCTION__);
return NULL;
}
- if (len == 0)
- len = strlen(memory);
+ len = strlen(memory);
return virConfParse("memory conf", memory, len, flags);
}
diff --git a/src/util/virconf.h b/src/util/virconf.h
index 23fea4900..f7d9a369c 100644
--- a/src/util/virconf.h
+++ b/src/util/virconf.h
@@ -79,8 +79,8 @@ typedef int (*virConfWalkCallback)(const char* name,
virConfPtr virConfNew(void);
virConfPtr virConfReadFile(const char *filename, unsigned int flags);
-virConfPtr virConfReadMem(const char *memory,
- int len, unsigned int flags);
+virConfPtr virConfReadString(const char *memory,
+ unsigned int flags);
int virConfFree(virConfPtr conf);
void virConfFreeValue(virConfValuePtr val);
virConfValuePtr virConfGetValue(virConfPtr conf,
diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
index 96507f10f..3e2f4c3e1 100644
--- a/src/vmx/vmx.c
+++ b/src/vmx/vmx.c
@@ -1312,7 +1312,7 @@ virVMXParseConfig(virVMXContext *ctx,
return NULL;
}
- conf = virConfReadMem(vmx, strlen(vmx), VIR_CONF_FLAG_VMX_FORMAT);
+ conf = virConfReadString(vmx, VIR_CONF_FLAG_VMX_FORMAT);
if (conf == NULL)
return NULL;
@@ -1332,7 +1332,7 @@ virVMXParseConfig(virVMXContext *ctx,
if (utf8 == NULL)
goto cleanup;
- conf = virConfReadMem(utf8, strlen(utf8), VIR_CONF_FLAG_VMX_FORMAT);
+ conf = virConfReadString(utf8, VIR_CONF_FLAG_VMX_FORMAT);
VIR_FREE(utf8);
diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
index b5cd47e02..dae0f4f28 100644
--- a/src/xen/xen_driver.c
+++ b/src/xen/xen_driver.c
@@ -1553,7 +1553,7 @@ xenUnifiedConnectDomainXMLFromNative(virConnectPtr conn,
}
if (STREQ(format, XEN_CONFIG_FORMAT_XM)) {
- conf = virConfReadMem(config, strlen(config), 0);
+ conf = virConfReadString(config, 0);
if (!conf)
goto cleanup;
diff --git a/tests/virconftest.c b/tests/virconftest.c
index 1f4b561bb..9d43465a7 100644
--- a/tests/virconftest.c
+++ b/tests/virconftest.c
@@ -89,7 +89,7 @@ static int testConfParseInt(const void *opaque ATTRIBUTE_UNUSED)
"string = \"foo\"\n";
int ret = -1;
- virConfPtr conf = virConfReadMem(srcdata, strlen(srcdata), 0);
+ virConfPtr conf = virConfReadString(srcdata, 0);
int iv;
unsigned int ui;
size_t s;
@@ -238,7 +238,7 @@ static int testConfParseBool(const void *opaque ATTRIBUTE_UNUSED)
"string = \"foo\"\n";
int ret = -1;
- virConfPtr conf = virConfReadMem(srcdata, strlen(srcdata), 0);
+ virConfPtr conf = virConfReadString(srcdata, 0);
bool f = true;
bool t = false;
@@ -302,7 +302,7 @@ static int testConfParseString(const void *opaque ATTRIBUTE_UNUSED)
"string = \"foo\"\n";
int ret = -1;
- virConfPtr conf = virConfReadMem(srcdata, strlen(srcdata), 0);
+ virConfPtr conf = virConfReadString(srcdata, 0);
char *str = NULL;
if (!conf)
@@ -342,7 +342,7 @@ static int testConfParseStringList(const void *opaque ATTRIBUTE_UNUSED)
"string = \"foo\"\n";
int ret = -1;
- virConfPtr conf = virConfReadMem(srcdata, strlen(srcdata), 0);
+ virConfPtr conf = virConfReadString(srcdata, 0);
char **str = NULL;
if (!conf)
diff --git a/tests/xlconfigtest.c b/tests/xlconfigtest.c
index 3fe42988d..30468c905 100644
--- a/tests/xlconfigtest.c
+++ b/tests/xlconfigtest.c
@@ -146,7 +146,7 @@ testCompareFormatXML(const char *xlcfg, const char *xml, bool replaceVars)
if (virTestLoadFile(xlcfg, &xlcfgData) < 0)
goto fail;
- if (!(conf = virConfReadMem(xlcfgData, strlen(xlcfgData), 0)))
+ if (!(conf = virConfReadString(xlcfgData, 0)))
goto fail;
if (!(def = xenParseXL(conf, caps, xmlopt)))
diff --git a/tests/xmconfigtest.c b/tests/xmconfigtest.c
index 345223ffe..d8455da66 100644
--- a/tests/xmconfigtest.c
+++ b/tests/xmconfigtest.c
@@ -115,7 +115,7 @@ testCompareFormatXML(const char *xmcfg, const char *xml)
priv.caps = caps;
conn->privateData = &priv;
- if (!(conf = virConfReadMem(xmcfgData, strlen(xmcfgData), 0)))
+ if (!(conf = virConfReadString(xmcfgData, 0)))
goto fail;
if (!(def = xenParseXM(conf, caps, xmlopt)))
--
2.13.0
7 years, 4 months