[libvirt] [PATCH] docs: Add mist.io as libvirt-based application
by Michal Privoznik
As reported on the libvirt-users list [1], there's new web
application called mist.io which uses libvirt as one of its
backends. Lets add it into our list of libivrt based
applications.
1: https://www.redhat.com/archives/libvirt-users/2015-February/msg00096.html
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/apps.html.in | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/docs/apps.html.in b/docs/apps.html.in
index 4403ce6..79ee73a 100644
--- a/docs/apps.html.in
+++ b/docs/apps.html.in
@@ -404,6 +404,14 @@
functions, such as live migration that allows for load
balancing between cluster nodes, monitoring CPU, memory.
</dd>
+ <dt><a href="http://mist.io/">mist.io</a></dt>
+ <dd>
+ Mist.io is an open source project and a service that can assist you in
+ managing your virtual machines on a unified way, providing a simple
+ interface for all of your infrastructure (multiple public cloud
+ providers, OpenStack based public/private clouds, Docker servers, bare
+ metal servers and now KVM hypervisors).
+ </dd>
</dl>
<h2><a name="mobile">Mobile applications</a></h2>
--
2.0.5
9 years, 9 months
[libvirt] new warning from ar on rawhide systems
by Eric Blake
When compiling libvirt (and probably other packages) on Fedora rawhide
systems, I'm seeing a new warning message on every link line.
# rpm -q libtool gcc binutils
libtool-2.4.6-1.fc23.x86_64
gcc-5.0.0-0.16.fc23.x86_64
binutils-2.25-6.fc23.x86_64
For an example of the warning during a 'make V=1':
> libtool: link: rm -fr .libs/libvirt_driver_qemu_impl.a .libs/libvirt_driver_qemu_impl.la
> libtool: link: ar cru .libs/libvirt_driver_qemu_impl.a qemu/.libs/libvirt_driver_qemu_impl_la-qemu_agent.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_capabilities.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_command.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_domain.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_cgroup.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hostdev.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_hotplug.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_conf.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_process.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_migration.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_text.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_monitor_json.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_driver.o qemu/.libs/libvirt_driver_qemu_impl_la-qemu_interface.o
> ar: `u' modifier ignored since `D' is the default (see `U')
> libtool: link: ranlib .libs/libvirt_driver_qemu_impl.a
Reading 'man ar', it looks like a relatively new binutils invention, one
that Fedora chose to flip on by default, but also one that might be
worth using even when ar is built with 'U' rather than 'D' as the default:
> D Operate in deterministic mode. When adding files and the archive
> index use zero for UIDs, GIDs, timestamps, and use consistent file
> modes for all files. When this option is used, if ar is used with
> identical options and identical input files, multiple runs will
> create identical output files regardless of the input files'
> owners, groups, file modes, or modification times.
>
> If binutils was configured with --enable-deterministic-archives,
> then this mode is on by default. It can be disabled with the U
> modifier, below.
Is it worth teaching libtool to change ARFLAGS to be 'crD' instead of
'cru' when it is detected that ar is new enough to support deterministic
libraries, in part to shut up the warning message being printed on every
single libtool link line? (Note that I would explicitly include 'D',
because even though Fedora chose to make 'D' the default, other distros
may choose to make 'U' the default). Or conversely, do we want ARFLAGS
to be 'cruU', to force non-deterministic mode, since any speedups made
possible by timestamp comparison ('u') are only possible in
non-deterministic mode? Does the use of 'u' buy us much measurable time
when repeatedly and incrementally linking large libraries, where the new
'D' mode is forced to link everything instead of just the new inputs?
And of course there's the question of how easy is it to detect that ar
is new enough to understand the 'D'/'U' dichotomy?
Is this something I should redirect to automake instead of libtool?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9 years, 9 months
[libvirt] [PATCH 0/3] Only talk to qemu guest agent when the domain is running
by Ján Tomko
Previously, only virDomainObjIsActive() was used to check domain liveness.
This includes states like 'VIR_DOMAIN_PMSUSPENDED', where QEMU is running,
but the guest is not.
Explicitly check the state against VIR_DOMAIN_RUNNING and refuse to
communicate with the agent if it does not match.
https://bugzilla.redhat.com/show_bug.cgi?id=872424
Ján Tomko (3):
Check for qemu guest agent availability after getting the job
Pass virDomainObjPtr to qemuDomainAgentAvailable
Check if domain is running in qemuDomainAgentIsAvailable
src/qemu/qemu_domain.c | 11 ++++++++++-
src/qemu/qemu_domain.h | 2 +-
src/qemu/qemu_driver.c | 49 +++++++++++++++++++++++++------------------------
3 files changed, 36 insertions(+), 26 deletions(-)
--
2.0.5
9 years, 9 months
Re: [libvirt] [Xen-devel] [xen-unstable test] 35257: regressions - FAIL
by Jim Fehlig
Ian Campbell wrote:
> On Thu, 2015-02-26 at 20:14 +0000, xen.org wrote:
>
>> flight 35257 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34629
>>
>
> logs:
> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-l...
>
> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-l...
> 2015-02-23 20:21:48 Z executing ssh ... root(a)10.80.229.106 virsh domxml-from-native xen-xl /etc/xen/debian.guest.osstest.cfg > /etc/xen/debian.guest.osstest.cfg.xml
> error: failed to connect to the hypervisor
> error: no valid connection
> error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Connection refused
>
> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-l...
> appears to show no libvirtd process.
>
> http://www.chiark.greenend.org.uk/~xensrcts/logs/35257/test-armhf-armhf-l...
> says:
> 2015-02-23 20:13:15.556+0000: 2133: info : libvirt version: 1.2.13
> 2015-02-23 20:13:15.556+0000: 2133: error : dnsmasqCapsRefreshInternal:726 : Cannot check dnsmasq binary dnsmasq: No such file or directory
>
> 2015-02-23 20:13:15.845+0000: 2133: error :
> virFirewallValidateBackend:193 : direct firewall backend requested,
> but /sbin/ebtables is not available: No such file or directory
Odd, since ebtables was found when building
checking for ebtables... /sbin/ebtables
But AFAICT, that wont prevent libvirtd from starting.
>
> I think these are just spurious.
>
> 2015-02-23 20:13:15.845+0000: 2133: error : virFirewallApply:936 : out of memory
>
>
> 2015-02-23 20:13:16.092+0000: 2133: error : virExec:491 : Cannot find 'pm-is-supported' in path: No such file or directory
> 2015-02-23 20:13:16.092+0000: 2133: warning : virQEMUCapsInit:999 : Failed to get host power management capabilities
>
> As are these two.
>
> 2015-02-23 20:13:16.400+0000: 2133: error : virFirewallApply:936 : out of memory
>
> Has these OOM messages resulted in libvirtd exiting?
No, I don't think so. The related code is
int
virFirewallApply(virFirewallPtr firewall)
{
size_t i, j;
int ret = -1;
virMutexLock(&ruleLock);
if (!firewall || firewall->err == ENOMEM) {
virReportOOMError();
goto cleanup;
...
}
I suspect 'firewall' is null, so OOM error is reported and the function
returns -1. But I also don't see this preventing libvirtd from
starting. I've cc'd the libvirt list for verification that these errors
won't prevent libvirtd from starting.
> I don't see any
> evidence of a crash elsewhere in the logs (i.e. no "process segfaulted"
> in dmesg, no OOM killing going on etc).
>
> We don't seem to collect dom0 freemem info, but that most likely
> wouldn't help given the libvirtd process has exited.
>
>
> Any ideas where to look next?
Can you access the test environment and try starting libvirtd in the
foreground? Or enable debug log level in /etc/libvirt/libvirtd.conf?
Regards,
Jim
9 years, 9 months
[libvirt] [PATCH] Really fix XML formatting flags in SaveImageUpdateDef
by Ján Tomko
Commit cf2d4c6 used a logical or instead of bitwise or,
effectively passing 1, that is VIR_DOMAIN_XML_INACTIVE.
Yep, that's right.
This was caught by a warning when building with clang.
https://bugzilla.redhat.com/show_bug.cgi?id=1183869
---
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 e9aa0b5..e282464 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5734,7 +5734,7 @@ qemuDomainSaveImageUpdateDef(virQEMUDriverPtr driver,
if (!(newdef_migr = qemuDomainDefCopy(driver,
newdef,
- QEMU_DOMAIN_FORMAT_LIVE_FLAGS ||
+ QEMU_DOMAIN_FORMAT_LIVE_FLAGS |
VIR_DOMAIN_XML_MIGRATABLE)))
goto cleanup;
--
2.0.5
9 years, 10 months
[libvirt] [PATCH 0/4] add support for graphics to get a IPv6 address
by Luyao Huang
https://bugzilla.redhat.com/show_bug.cgi?id=1192318
We already support add a IPv6 address to graphics listen address
and xml like this:
<graphics type='spice' port='5900' autoport='yes' listen='2001b8:ca2:2::1' keymap='en-us'>
<listen type='address' address='2001b8:ca2:2::1'/>
</graphics>
However we do not support get a IPv6 address for the network.
add some helpers and rework networkGetNetworkAddress to make it
can get a IPv6 address when we need.
Luyao Huang (4):
util: introduce a new helper for get interface IPv6 address
conf: introduce new family attribute in graphics listen for chose IP
family
network: rework networkGetNetworkAddress to make it can get IPv6
address
qemu: fix a error coverd issue in 2 place
docs/formatdomain.html.in | 10 +++-
docs/schemas/domaincommon.rng | 9 +++
src/conf/domain_conf.c | 21 +++++++
src/conf/domain_conf.h | 10 ++++
src/conf/network_conf.c | 2 +-
src/conf/network_conf.h | 1 +
src/libvirt_private.syms | 2 +
src/network/bridge_driver.c | 50 +++++++++++-----
src/network/bridge_driver.h | 6 +-
src/qemu/qemu_command.c | 18 ++----
src/util/virnetdev.c | 70 ++++++++++++++++++++++
src/util/virnetdev.h | 2 +
.../qemuxml2argv-graphics-listen-network.xml | 2 +-
.../qemuxml2argv-graphics-listen-network2.xml | 2 +-
.../qemuxml2xmlout-graphics-listen-network2.xml | 2 +-
15 files changed, 174 insertions(+), 33 deletions(-)
--
1.8.3.1
9 years, 10 months
[libvirt] [PATCH 0/5] Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flag
by Ján Tomko
Add a flag to virConnectBaselineCPU to filter out features
that block migration.
Ján Tomko (5):
Also store features blocking migration as CPUx86Data in the cpu map
Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flag
Implement VIR_CONNECT_BASELINE_CPU_MIGRATABLE in the x86 cpu driver
Trivially implement VIR_CONNECT_BASELINE_CPU_MIGRATABLE for non-x86
cpus
Add --migratable support to virsh cpu-baseline
include/libvirt/libvirt-host.h | 1 +
src/bhyve/bhyve_driver.c | 3 +-
src/cpu/cpu_aarch64.c | 3 +-
src/cpu/cpu_arm.c | 3 +-
src/cpu/cpu_generic.c | 3 +-
src/cpu/cpu_powerpc.c | 3 +-
src/cpu/cpu_x86.c | 47 ++++++++++++++++++++++++-
src/libvirt-host.c | 3 ++
src/qemu/qemu_driver.c | 3 +-
tests/cputest.c | 6 ++++
tests/cputestdata/x86-baseline-6-migratable.xml | 10 ++++++
tests/cputestdata/x86-baseline-6-result.xml | 11 ++++++
tests/cputestdata/x86-baseline-6.xml | 37 +++++++++++++++++++
tools/virsh-domain.c | 6 ++++
tools/virsh.pod | 5 +--
15 files changed, 135 insertions(+), 9 deletions(-)
create mode 100644 tests/cputestdata/x86-baseline-6-migratable.xml
create mode 100644 tests/cputestdata/x86-baseline-6-result.xml
create mode 100644 tests/cputestdata/x86-baseline-6.xml
--
2.0.5
9 years, 10 months
[libvirt] [PATCH] qemu: snapshot: post error when create internal system checkpoint snapshot with rbd backend
by Shanzhi Yu
When create internel system checkpoint snapshot with source file based
on rbd backend, libvirt miss to check if the format of source file
support internal snapshot.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1179533
Signed-off-by: Shanzhi Yu <shyu(a)redhat.com>
---
src/qemu/qemu_driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 26fc6a2..6dd0a5c 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13423,8 +13423,7 @@ qemuDomainSnapshotPrepare(virConnectPtr conn,
goto cleanup;
if (dom_disk->src->type == VIR_STORAGE_TYPE_NETWORK &&
- (dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_SHEEPDOG ||
- dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_RBD)) {
+ dom_disk->src->protocol == VIR_STORAGE_NET_PROTOCOL_SHEEPDOG) {
break;
}
if (vm->def->disks[i]->src->format > 0 &&
--
2.1.0
9 years, 10 months
[libvirt] [PATCH] Ignore listen attribute of <graphics> for type network listens
by Ján Tomko
Commit 6992994 started filling the listen attribute
of the parent <graphics> elements from type='network' listens.
When this XML is passed to UpdateDevice, parsing fails:
XML error: graphics listen attribute 10.20.30.40 must match
address attribute of first listen element (found none)
Ignore the address in the parent <graphics> attribute
when no type='address' listens are found,
the same we ignore the address for the <listen> subelements
when parsing inactive XML.
---
src/conf/domain_conf.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index d95dd3e..d458195 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -9614,12 +9614,16 @@ virDomainGraphicsDefParseXML(xmlNodePtr node,
break;
}
}
- if (!matched) {
+ if (found && !matched) {
virReportError(VIR_ERR_XML_ERROR,
_("graphics listen attribute %s must match address "
"attribute of first listen element (found %s)"),
- listenAddr, found ? found : "none");
+ listenAddr, found);
goto error;
+ } else if (!found && !matched) {
+ /* quietly ignore listen address if none of the listens
+ * are of type address */
+ VIR_FREE(listenAddr);
}
}
}
--
2.0.5
9 years, 10 months
[libvirt] [PATCH] qemu: forbid large value wraparound in balloon period collection
by Erik Skultety
We do parse and represent period collection as unsigned int in our
internal structures, however commit
d5c67e7f4523450023b89b69c16472582c85eeaf converts this to int, thus wrapping
around inputs greater than INT_MAX which results in an error from QEMU.
This patch adds a check into QEMU driver, because period attribute is
only supported by QEMU.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140958
---
src/qemu/qemu_driver.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index bec05d4..46bd880 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -2414,6 +2414,12 @@ static int qemuDomainSetMemoryStatsPeriod(virDomainPtr dom, int period,
/* Set the balloon driver collection interval */
priv = vm->privateData;
+ if (period < 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("invalid value for collection period"));
+ goto endjob;
+ }
+
if (flags & VIR_DOMAIN_AFFECT_LIVE) {
qemuDomainObjEnterMonitor(driver, vm);
--
1.9.3
9 years, 10 months