[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson
In the python bindings, all vir* classes expect to be
passed a virConnect object when instantiated. Before
the storage stuff, these classes were only instantiated
in virConnect methods, so the generator is hardcoded to
pass 'self' as the connection instance to these classes.
Problem is there are some methods that return pool or vol
instances which aren't called from virConnect: you can
lookup a storage volume's associated pool, and can lookup
volumes from a pool. In these cases passing 'self' doesn't
give the vir* instance a connection, so when it comes time
to raise an exception crap hits the fan.
Rather than rework the generator to accomodate this edge
case, I just fixed the init functions for virStorage* to
pull the associated connection out of the passed value
if it's not a virConnect instance.
Thanks,
Cole
diff --git a/python/generator.py b/python/generator.py
index 01a17da..c706b19 100755
--- a/python/generator.py
+++ b/python/generator.py
@@ -962,8 +962,12 @@ def buildWrappers():
list = reference_keepers[classname]
for ref in list:
classes.write(" self.%s = None\n" % ref[1])
- if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]:
+ if classname in [ "virDomain", "virNetwork" ]:
classes.write(" self._conn = conn\n")
+ elif classname in [ "virStorageVol", "virStoragePool" ]:
+ classes.write(" self._conn = conn\n" + \
+ " if not isinstance(conn, virConnect):\n" + \
+ " self._conn = conn._conn\n")
classes.write(" if _obj != None:self._o = _obj;return\n")
classes.write(" self._o = None\n\n");
destruct=None
1 month, 3 weeks
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year, 6 months
[libvirt] [PATCH] qemu: add PCI-multibus support for ppc
by Olivia Yin
Signed-off-by: Olivia Yin <hong-hua.yin(a)freescale.com>
---
src/qemu/qemu_capabilities.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 7bc1ebc..7d7791d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2209,6 +2209,11 @@ virQEMUCapsInitHelp(virQEMUCapsPtr qemuCaps, uid_t runUid, gid_t runGid)
virQEMUCapsClear(qemuCaps, QEMU_CAPS_NO_ACPI);
}
+ /* ppc support PCI-multibus */
+ if (qemuCaps->arch == VIR_ARCH_PPC) {
+ virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS);
+ }
+
/* virQEMUCapsExtractDeviceStr will only set additional caps if qemu
* understands the 0.13.0+ notion of "-device driver,". */
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE) &&
@@ -2450,6 +2455,11 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI);
}
+ /* ppc support PCI-multibus */
+ if (qemuCaps->arch == VIR_ARCH_PPC) {
+ virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS);
+ }
+
if (virQEMUCapsProbeQMPCommands(qemuCaps, mon) < 0)
goto cleanup;
if (virQEMUCapsProbeQMPEvents(qemuCaps, mon) < 0)
--
1.6.4
11 years, 1 month
[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang)
Hi,
When I changed code as following:
public class Connect {
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback());
}
The server will generate the following core dump:
Program terminated with signal 6, Aborted.
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
#1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6
#2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6
#3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6
#4 0x0000003f9b07276b in free () from /lib64/libc.so.6
#5 0x00002aaaacf46868 in ?? ()
#6 0x0000000000000000 in ?? ()
The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback object. But when GC is executed, the object is GCed. But even I change code as following.
When GC is excuted, the callback object will be moved. Then C can't find this object. Both of scenarios will cause core dump. It seems that JNA mustn't provide ErrorCallback Class,
Because nobody can use this.
Please correct me.
public class Connect {
+ private static final ErrorCallback callback = new ErrorCallback();
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, callback);
}
B.R.
Benjamin Wang
11 years, 4 months
[libvirt] [PATCH 0/2] qemu: Rework CD/DVD changing
by Michal Privoznik
The first patch is bare bug fix (without any bug reported though).
The second is again a bug fix, but not so easy to spot. Basically, when we
change a media, we should issue 'eject' first, then wait until the tray gets
open, after which we can finally issue 'change' command. Even for bare 'eject'
we ought to check status, shouldn't we?
Michal Privoznik (2):
qemu_monitor: Fix tray-open attribute in query-block
qemu_hotplug: Rework media changing process
src/qemu/qemu_hotplug.c | 51 +++++++++++++++++++++++++++++++++++++++++---
src/qemu/qemu_monitor_json.c | 2 +-
src/qemu/qemu_monitor_text.c | 6 +++---
3 files changed, 52 insertions(+), 7 deletions(-)
--
1.8.0.2
11 years, 11 months
[libvirt] New application
by Maciej Nabożny
Hello,
I'm developer of CC1 project in Institute of Nuclear Physics in
Cracow. We are creating cloud computing system based on Libvirt. Is it
possible to add link to our project at yours website in applications
section?
Title: CC1 Project (http://cc1.ifj.edu.pl)
Description: The Cloud Computing for Science and Economy project
At this time we are using version 0.8.3, but as soon as debian 7 will
we stable, we are going to migrate to newer version of Libvirt.
Regards,
Maciej Nabożny
11 years, 11 months
[libvirt] [PATCH] Update to COPYING.LIB to latest LGPLv2.1 copy
by Christophe Fergeau
The text version
of LGPLv2.1 available at
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.txt is slightly
different from COPYING.LIB:
- several paragraphs were rewrapped
- the FSF address has changed, so the license has been changed to
indicate the newer address
I've checked that there are no changes in the license text apart from
the updated address, which is what I want to fix with this commit.
---
COPYING.LIB | 82 ++++++++++++++++++++++++++++---------------------------------
1 file changed, 38 insertions(+), 44 deletions(-)
diff --git a/COPYING.LIB b/COPYING.LIB
index 89d4489..4362b49 100644
--- a/COPYING.LIB
+++ b/COPYING.LIB
@@ -1,9 +1,8 @@
-
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
@@ -23,8 +22,7 @@ specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
-strategy to use in any particular case, based on the explanations
-below.
+strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
not price. Our General Public Licenses are designed to make sure that
@@ -57,7 +55,7 @@ modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
-^L
+
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
@@ -89,9 +87,9 @@ libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
-encourage the widest possible use of a certain library, so that it
-becomes a de-facto standard. To achieve this, non-free programs must
-be allowed to use the library. A more frequent case is that a free
+encourage the widest possible use of a certain library, so that it becomes
+a de-facto standard. To achieve this, non-free programs must be
+allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.
@@ -113,7 +111,7 @@ modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
-^L
+
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@@ -138,8 +136,8 @@ included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
-interface definition files, plus the scripts used to control
-compilation and installation of the library.
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
@@ -218,7 +216,7 @@ instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
-^L
+
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
@@ -269,7 +267,7 @@ Library will still fall under Section 6.)
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
-^L
+
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
@@ -305,10 +303,10 @@ of these things:
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
- c) Accompany the work with a written offer, valid for at least
- three years, to give the same user the materials specified in
- Subsection 6a, above, for a charge no more than the cost of
- performing this distribution.
+ c) Accompany the work with a written offer, valid for at
+ least three years, to give the same user the materials
+ specified in Subsection 6a, above, for a charge no more
+ than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
@@ -331,7 +329,7 @@ restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
-^L
+
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
@@ -372,7 +370,7 @@ subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
-^L
+
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
@@ -386,10 +384,9 @@ all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply, and the section as a whole is intended to apply in other
-circumstances.
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
@@ -407,11 +404,11 @@ be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Library under this License
-may add an explicit geographical distribution limitation excluding those
-countries, so that distribution is permitted only in or among
-countries not thus excluded. In such case, this License incorporates
-the limitation as if written in the body of this License.
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded. In such case, this License incorporates the limitation as if
+written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
@@ -425,7 +422,7 @@ conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
-^L
+
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
@@ -459,21 +456,19 @@ SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
-^L
+
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
-redistribution under these terms (or, alternatively, under the terms
-of the ordinary General Public License).
-
- To apply these terms, attach the following notices to the library.
-It is safest to attach them to the start of each source file to most
-effectively convey the exclusion of warranty; and each file should
-have at least the "copyright" line and a pointer to where the full
-notice is found.
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+ To apply these terms, attach the following notices to the library. It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
@@ -490,17 +485,16 @@ notice is found.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
-You should also get your employer (if you work as a programmer) or
-your school, if any, to sign a "copyright disclaimer" for the library,
-if necessary. Here is a sample; alter the names:
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
- library `Frob' (a library for tweaking knobs) written by James
- Random Hacker.
+ library `Frob' (a library for tweaking knobs) written by James Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice
--
1.8.1.4
11 years, 11 months
[libvirt] Bug in DOMINFO command when balloon driver is used on a vm with more then 8 GB of MaxMemory ?
by fc lists
Hi ,
I have been banging my head on this for the last 8 hours ... and i really
need to know if is really a bug or i am doing something wrong.
Description of the problem:
When the virsh setmem command is used to inflate the balloon on a VM to
which 8GB of MaxMemory or more are allocated then the information reported
with virsh dominfo , virsh dumpxml after the balloon change has been
performed are wrong.
The actual balloon is inflated correctly though and that is verifiable both
in the vm itself and through the "virsh dommemstat" commands.
I *think* that is because the dommestat command will perform a proper query
to find out the amount of ram currently used (and i can see that in the
logs when issuing a dommestat command)
2013-03-22 21:22:41.820+0000: 23181: debug : virJSONValueToString:1133 :
result={"execute":"query-balloon","id":"libvirt-9"}
2013-03-22 21:22:41.820+0000: 23181: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"query-balloon","id":"libvirt-9"}' for write with FD -1
2013-03-22 21:22:41.820+0000: 23181: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d643eb5a0
msg={"execute":"query-balloon","id":"libvirt-9"}
2013-03-22 21:22:41.820+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d643eb5a0
buf={"execute":"query-balloon","id":"libvirt-9"}
but no entries are shown in the log for qemu-monitor when virsh dominfo is
run, how does dominfo gather those informations?
I am going to raise a ticket on RED HAT bugzilla for this but was hoping to
get some feedback here first to avoid raising a ticket for something that
maybe i just misunderstood.
Platform is Centos 6.4 (problem was present in 6.3 as well starting
with libvirt-0.9.10-21.el6.3.7 )
The patch that actually is causing the problem is patch number 398 in the
src rpm for libvirt-0.9.10-21.el6.3.7 :
libvirt-Wire-up-handling-for-QMP-s-BALLOON_EVENT.patch (
https://bugzilla.redhat.com/show_bug.cgi?id=884713)
And i verified it by removing the patch and recompiling the rpm , that
indeed worked perfectly after that.
The problem exists in every version up to the latest (that is what i am
running now) but now the patch is part of the libvirt source code in itself
and not a patch in the rpm anymore.
Software used:
# yum list installed | egrep -i "qemu|libvirt"
gpxe-roms-qemu.noarch 0.9.7-6.9.el6 @base
libvirt.x86_64 0.10.2-18.el6_4.2 @updates
libvirt-client.x86_64 0.10.2-18.el6_4.2 @updates
libvirt-python.x86_64 0.10.2-18.el6_4.2 @updates
qemu-img.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.2 @updates
qemu-kvm.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.2 @updates
qemu-kvm-tools.x86_64 2:0.12.1.2-2.355.0.1.el6.centos.2 @updates
Full example ( long and include debug logs ) :
1) Start VM with 12GB of MAX and CURRENT (12582912)
(tail -f libvirtd.log | grep -i balloon)
2013-03-22 21:06:34.438+0000: 23180: debug : qemuMonitorSetBalloon:1690 :
mon=0x7f3d6c1789e0 newmem=12582912
2013-03-22 21:06:34.438+0000: 23180: debug : virJSONValueToString:1133 :
result={"execute":"balloon","arguments":{"value":12884901888},"id":"libvirt-6"}
2013-03-22 21:06:34.438+0000: 23180: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"balloon","arguments":{"value":12884901888},"id":"libvirt-6"}'
for write with FD -1
2013-03-22 21:06:34.438+0000: 23180: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d6c1789e0
msg={"execute":"balloon","arguments":{"value":12884901888},"id":"libvirt-6"}
2013-03-22 21:06:34.439+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d6c1789e0
buf={"execute":"balloon","arguments":{"value":12884901888},"id":"libvirt-6"}
# dominfo 2
Id: 2
Name: centos_jt
UUID: bc25a6c4-ba34-a593-47c7-6372999946d6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 26.6s
Max memory: 12582912 KiB
Used memory: 12582912 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
2) set mem to 8GB
# setmem 2 --live --config --size 8388608
2013-03-22 21:13:45.522+0000: 23183: debug : qemuMonitorSetBalloon:1690 :
mon=0x7f3d6c1789e0 newmem=8388608
2013-03-22 21:13:45.522+0000: 23183: debug : virJSONValueToString:1133 :
result={"execute":"balloon","arguments":{"value":8589934592},"id":"libvirt-9"}
2013-03-22 21:13:45.522+0000: 23183: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"balloon","arguments":{"value":8589934592},"id":"libvirt-9"}'
for write with FD -1
2013-03-22 21:13:45.522+0000: 23183: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d6c1789e0
msg={"execute":"balloon","arguments":{"value":8589934592},"id":"libvirt-9"}
2013-03-22 21:13:45.523+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d6c1789e0
buf={"execute":"balloon","arguments":{"value":8589934592},"id":"libvirt-9"}
2013-03-22 21:13:45.528+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d6c1789e0 buf={"timestamp": {"seconds":
1363986825, "microseconds": 528314}, "event": "BALLOON_CHANGE", "data":
{"actual": 12883853312}}
2013-03-22 21:13:45.528+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363986825, "microseconds": 528314}, "event": "BALLOON_CHANGE", "data":
{"actual": 12883853312}}]
2013-03-22 21:13:45.528+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363986825, "microseconds": 528314},
"event": "BALLOON_CHANGE", "data": {"actual": 12883853312}}
2013-03-22 21:13:45.528+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d6c1789e0 event={"timestamp": {"seconds": 1363986825,
"microseconds": 528314}, "event": "BALLOON_CHANGE", "data": {"actual":
12883853312}}
2013-03-22 21:13:45.528+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1685ce0
2013-03-22 21:13:45.528+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d6c1789e0
2013-03-22 21:13:45.528+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 12582912 to
12581888 kb
2013-03-22 21:13:46.528+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d6c1789e0 buf={"timestamp": {"seconds":
1363986826, "microseconds": 352941}, "event": "BALLOON_CHANGE", "data":
{"actual": 12884901888}}
2013-03-22 21:13:46.528+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363986826, "microseconds": 352941}, "event": "BALLOON_CHANGE", "data":
{"actual": 12884901888}}]
2013-03-22 21:13:46.528+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363986826, "microseconds": 352941},
"event": "BALLOON_CHANGE", "data": {"actual": 12884901888}}
2013-03-22 21:13:46.528+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d6c1789e0 event={"timestamp": {"seconds": 1363986826,
"microseconds": 352941}, "event": "BALLOON_CHANGE", "data": {"actual":
12884901888}}
2013-03-22 21:13:46.528+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1686770
2013-03-22 21:13:46.528+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d6c1789e0
2013-03-22 21:13:46.528+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 12581888 to
12582912 kb
virsh # dominfo 2
Id: 2
Name: centos_jt
UUID: bc25a6c4-ba34-a593-47c7-6372999946d6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 41.6s
Max memory: 12582912 KiB
Used memory: 12582912 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
virsh # dommemstat 2
actual 8388608
rss 599916
The Balloon was actually inflated , and in the VM i can see 8GB of Ram
available with free
3) setmem to to 3000000
2013-03-22 21:18:19.182+0000: 23181: debug : qemuMonitorSetBalloon:1690 :
mon=0x7f3d6c1789e0 newmem=3000000
2013-03-22 21:18:19.182+0000: 23181: debug : virJSONValueToString:1133 :
result={"execute":"balloon","arguments":{"value":3072000000},"id":"libvirt-63"}
2013-03-22 21:18:19.182+0000: 23181: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"balloon","arguments":{"value":3072000000},"id":"libvirt-63"}'
for write with FD -1
2013-03-22 21:18:19.182+0000: 23181: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d6c1789e0
msg={"execute":"balloon","arguments":{"value":3072000000},"id":"libvirt-63"}
2013-03-22 21:18:19.183+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d6c1789e0
buf={"execute":"balloon","arguments":{"value":3072000000},"id":"libvirt-63"}
2013-03-22 21:18:19.184+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d6c1789e0 buf={"timestamp": {"seconds":
1363987099, "microseconds": 184245}, "event": "BALLOON_CHANGE", "data":
{"actual": 12883853312}}
2013-03-22 21:18:19.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363987099, "microseconds": 184245}, "event": "BALLOON_CHANGE", "data":
{"actual": 12883853312}}]
2013-03-22 21:18:19.184+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363987099, "microseconds": 184245},
"event": "BALLOON_CHANGE", "data": {"actual": 12883853312}}
2013-03-22 21:18:19.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d6c1789e0 event={"timestamp": {"seconds": 1363987099,
"microseconds": 184245}, "event": "BALLOON_CHANGE", "data": {"actual":
12883853312}}
2013-03-22 21:18:19.184+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1688320
2013-03-22 21:18:19.184+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d6c1789e0
2013-03-22 21:18:19.191+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 12582912 to
12581888 kb
2013-03-22 21:18:20.184+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d6c1789e0 buf={"timestamp": {"seconds":
1363987100, "microseconds": 184128}, "event": "BALLOON_CHANGE", "data":
{"actual": 11874074624}}
2013-03-22 21:18:20.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363987100, "microseconds": 184128}, "event": "BALLOON_CHANGE", "data":
{"actual": 11874074624}}]
2013-03-22 21:18:20.184+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363987100, "microseconds": 184128},
"event": "BALLOON_CHANGE", "data": {"actual": 11874074624}}
2013-03-22 21:18:20.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d6c1789e0 event={"timestamp": {"seconds": 1363987100,
"microseconds": 184128}, "event": "BALLOON_CHANGE", "data": {"actual":
11874074624}}
2013-03-22 21:18:20.184+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1685ce0
2013-03-22 21:18:20.184+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d6c1789e0
2013-03-22 21:18:20.184+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 12581888 to
11595776 kb
2013-03-22 21:18:21.184+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d6c1789e0 buf={"timestamp": {"seconds":
1363987100, "microseconds": 224930}, "event": "BALLOON_CHANGE", "data":
{"actual": 11661934592}}
2013-03-22 21:18:21.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363987100, "microseconds": 224930}, "event": "BALLOON_CHANGE", "data":
{"actual": 11661934592}}]
2013-03-22 21:18:21.184+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363987100, "microseconds": 224930},
"event": "BALLOON_CHANGE", "data": {"actual": 11661934592}}
2013-03-22 21:18:21.184+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d6c1789e0 event={"timestamp": {"seconds": 1363987100,
"microseconds": 224930}, "event": "BALLOON_CHANGE", "data": {"actual":
11661934592}}
2013-03-22 21:18:21.184+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1686770
2013-03-22 21:18:21.184+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d6c1789e0
2013-03-22 21:18:21.184+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 11595776 to
11388608
virsh # dominfo 2
Id: 2
Name: centos_jt
UUID: bc25a6c4-ba34-a593-47c7-6372999946d6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 53.0s
Max memory: 12582912 KiB
Used memory: 11388608 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
virsh # dommemstat 2
actual 3000000
rss 599036
4) Restart vm with 4GB of Current and Max (4194304)
2013-03-22 21:20:58.894+0000: 23182: debug : qemuMonitorSetBalloon:1690 :
mon=0x7f3d643eb5a0 newmem=4194304
2013-03-22 21:20:58.894+0000: 23182: debug : virJSONValueToString:1133 :
result={"execute":"balloon","arguments":{"value":4294967296},"id":"libvirt-6"}
2013-03-22 21:20:58.894+0000: 23182: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"balloon","arguments":{"value":4294967296},"id":"libvirt-6"}'
for write with FD -1
2013-03-22 21:20:58.894+0000: 23182: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d643eb5a0
msg={"execute":"balloon","arguments":{"value":4294967296},"id":"libvirt-6"}
2013-03-22 21:20:58.894+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d643eb5a0
buf={"execute":"balloon","arguments":{"value":4294967296},"id":"libvirt-6"}
virsh # dominfo 3
Id: 3
Name: centos_jt
UUID: bc25a6c4-ba34-a593-47c7-6372999946d6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 15.4s
Max memory: 4194304 KiB
Used memory: 4194304 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
virsh # dommemstat 3
actual 4194304
rss 431384
5) reduce ram to 1GB
virsh # setmem 3 --live --config --size 1048576
2013-03-22 21:26:08.783+0000: 23183: debug : qemuMonitorSetBalloon:1690 :
mon=0x7f3d643eb5a0 newmem=1048576
2013-03-22 21:26:08.783+0000: 23183: debug : virJSONValueToString:1133 :
result={"execute":"balloon","arguments":{"value":1073741824},"id":"libvirt-11"}
2013-03-22 21:26:08.783+0000: 23183: debug :
qemuMonitorJSONCommandWithFd:265 : Send command
'{"execute":"balloon","arguments":{"value":1073741824},"id":"libvirt-11"}'
for write with FD -1
2013-03-22 21:26:08.783+0000: 23183: debug : qemuMonitorSend:903 :
QEMU_MONITOR_SEND_MSG: mon=0x7f3d643eb5a0
msg={"execute":"balloon","arguments":{"value":1073741824},"id":"libvirt-11"}
2013-03-22 21:26:08.784+0000: 23179: debug : qemuMonitorIOWrite:461 :
QEMU_MONITOR_IO_WRITE: mon=0x7f3d643eb5a0
buf={"execute":"balloon","arguments":{"value":1073741824},"id":"libvirt-11"}
2013-03-22 21:26:08.789+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d643eb5a0 buf={"timestamp": {"seconds":
1363987568, "microseconds": 789570}, "event": "BALLOON_CHANGE", "data":
{"actual": 4293918720}}
2013-03-22 21:26:08.789+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363987568, "microseconds": 789570}, "event": "BALLOON_CHANGE", "data":
{"actual": 4293918720}}]
2013-03-22 21:26:08.789+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363987568, "microseconds": 789570},
"event": "BALLOON_CHANGE", "data": {"actual": 4293918720}}
2013-03-22 21:26:08.789+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d643eb5a0 event={"timestamp": {"seconds": 1363987568,
"microseconds": 789570}, "event": "BALLOON_CHANGE", "data": {"actual":
4293918720}}
2013-03-22 21:26:08.789+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x1686360
2013-03-22 21:26:08.789+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d643eb5a0
2013-03-22 21:26:08.789+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 4194304 to
4193280 kb
2013-03-22 21:26:09.789+0000: 23179: debug : qemuMonitorIOProcess:353 :
QEMU_MONITOR_IO_PROCESS: mon=0x7f3d643eb5a0 buf={"timestamp": {"seconds":
1363987569, "microseconds": 408889}, "event": "BALLOON_CHANGE", "data":
{"actual": 1073741824}}
2013-03-22 21:26:09.789+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:152 : Line [{"timestamp": {"seconds":
1363987569, "microseconds": 408889}, "event": "BALLOON_CHANGE", "data":
{"actual": 1073741824}}]
2013-03-22 21:26:09.789+0000: 23179: debug : virJSONValueFromString:975 :
string={"timestamp": {"seconds": 1363987569, "microseconds": 408889},
"event": "BALLOON_CHANGE", "data": {"actual": 1073741824}}
2013-03-22 21:26:09.789+0000: 23179: debug :
qemuMonitorJSONIOProcessLine:167 : QEMU_MONITOR_RECV_EVENT:
mon=0x7f3d643eb5a0 event={"timestamp": {"seconds": 1363987569,
"microseconds": 408889}, "event": "BALLOON_CHANGE", "data": {"actual":
1073741824}}
2013-03-22 21:26:09.789+0000: 23179: debug :
qemuMonitorJSONIOProcessEvent:138 : handle BALLOON_CHANGE handler=0x4b4de0
data=0x16826e0
2013-03-22 21:26:09.789+0000: 23179: debug :
qemuMonitorEmitBalloonChange:1151 : mon=0x7f3d643eb5a0
2013-03-22 21:26:09.789+0000: 23179: debug :
qemuProcessHandleBalloonChange:1248 : Updating balloon from 4193280 to
1048576 kb
virsh # dominfo 3
Id: 3
Name: centos_jt
UUID: bc25a6c4-ba34-a593-47c7-6372999946d6
OS Type: hvm
State: running
CPU(s): 1
CPU time: 28.6s
Max memory: 4194304 KiB
Used memory: 1048576 KiB
Persistent: yes
Autostart: disable
Managed save: no
Security model: none
Security DOI: 0
virsh # dommemstat 3
actual 1048576
rss 411740
11 years, 11 months
