search for: virdomainsetmemori

Displaying 12 results from an estimated 12 matches for "virdomainsetmemori".

Did you mean: virdomainsetmemory
2020 Sep 17
0
Re: KVM/QEMU Memory Ballooning
On Thu, Sep 17, 2020 at 09:06:51AM +0000, Sprencz, Pal Csongor (GE Healthcare) wrote: > In short we have a ScientificLinux7 base host OS system, on top of > that I would want to run a KVM/QEMU virtual machine. > The kvm version is used on the host OS is the following. > qemu-kvm-common-1.5.3-173.el7_8.1.x86_64 > libvirt-daemon-driver-qemu-4.5.0-23.el7_7.6.x86_64 >
2020 Sep 17
0
RE: EXT: Re: KVM/QEMU Memory Ballooning
What about running tasks/containers directly on the host? -----Original Message----- To: Daniel P. Berrangé Cc: libvirt-users@redhat.com Subject: RE: EXT: Re: KVM/QEMU Memory Ballooning Hi Daniel, Thank you very much for the quick answer. Now it is clear how this memballooning driver works, and how it can be managed manually. I really appreciate your answer. Regards, Csongor -----Original
2020 Jan 10
2
Re: [PATCH Fedora libguestfs] Don't depend on libvirt-daemon-kvm monolith.
On Fri, Jan 10, 2020 at 02:15:10PM +0000, Daniel P. Berrangé wrote: > Do you use the libvirt "secret" APIs at all (disk encryption, network > disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" > too. How about any other libvirt sub-driver APIs ? Networking ? Host > dev, etc ? The full list of APIs we use is attached, assuming I got my
2020 Jan 10
5
[PATCH Fedora libguestfs] Don't depend on libvirt-daemon-kvm monolith.
libguestfs usually needs qemu. However it only requires an emulator for the same architecture, not for all architectures. libvirt-daemon-kvm pulls in qemu which pulls in emulators for all architectures, as well as a bunch of other stuff we don't need at all like network interface support and nwfilter. There are no Fedora TCG-only arches, so drop the conditional section. I also made support
2011 May 05
0
Release of libvirt-0.9.1
As planned and after most of the clang detected problems got fixed (thanks Eric !) the new release is available at: ftp://libvirt.org/libvirt/ It's a mixed release, it includes a number of improvements as well as many bug fixes and a few new features: Features: - support various persistent domain updates (KAMEZAWA Hiroyuki) - improvements on memory APIs (Taku Izumi) - Add
2019 Apr 08
0
[PATCH v4 2/7] common: Bundle the libvirt-ocaml library for use by virt-v2v
Add a copy of the libvirt-ocaml library, currently available at: https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary This is a snapshot at commit d3ed8dcf1b0a6a8a855ceecbe0bb97f21e6665e3, which has all the features we need (and that builds fine). It is expected to stay synchronized with upstream, until there is a new upstream release, and it will be widespread enough. --- .gitignore
2019 Dec 16
3
[v2v PATCH 0/2] Move libvirt-ocaml copy to v2v repo
libvirt-ocaml is used only by virt-v2v, so move it to this repository, instead of having it around in the common submodule. The removal from common will happen later. Pino Toscano (2): common: Bundle the libvirt-ocaml library for use by virt-v2v build: switch embedded copy of libvirt-ocaml .gitignore | 2 + 3rdparty/libvirt-ocaml/Makefile.am |
2018 Aug 30
8
[PATCH 0/7] RFC: switch v2v to ocaml-libvirt
Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not
2018 Nov 27
8
[PATCH v2 0/7] RFC: switch v2v to ocaml-libvirt
Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not
2019 Jan 30
8
[PATCH v3 0/7] RFC: switch v2v to ocaml-libvirt
Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not
2019 May 20
8
[PATCH v5 0/7] v2v: switch to ocaml-libvirt
Hi, this series switches virt-2v to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not test all
2019 Apr 08
12
[PATCH 43 0/7] v2v: switch to ocaml-libvirt
Hi, this series switches virt-2v to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not test all