March 2013 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

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

4 3

[libvirt] [PATCH] web docs -- macvtap mode explanation
by Stefan Berger 27 Oct '23

27 Oct '23

This adds more information about the different macvtap device modes. Regards, Stefan

3 2

[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori 27 Oct '23

27 Oct '23

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

8 26

[libvirt] [PATCH] qemu: add PCI-multibus support for ppc
by Olivia Yin 05 Mar '14

05 Mar '14

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

5 7

[libvirt] Warnings messages in logs from DHCP snooping code
by Daniel P. Berrange 31 Jan '14

31 Jan '14

I'm noticing that VMs which have nwfilters associated with them will apparently always cause the following errors to appear in the logs upon VM shutdown: 2013-02-27 17:02:18.709+0000: 9669: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet0" not in key map 2013-02-27 17:02:18.715+0000: 9669: error : virNetDevGetIndex:653 : Unable to get index for interface vnet0: No such device 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 :|

3 2

[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang) 20 Dec '13

20 Dec '13

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

2 4

[libvirt] [PATCH 0/2] qemu: Rework CD/DVD changing
by Michal Privoznik 20 May '13

20 May '13

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

6 22

[libvirt] New application
by Maciej Nabożny 17 May '13

17 May '13

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

3 7

[libvirt] [PATCH] Update to COPYING.LIB to latest LGPLv2.1 copy
by Christophe Fergeau 15 May '13

15 May '13

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

3 7

[libvirt] Bug in DOMINFO command when balloon driver is used on a vm with more then 8 GB of MaxMemory ?
by fc lists 07 May '13

07 May '13

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

2 1