similar to: Detecting of features of VMs

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

Hi. Since the update to libvirt-1.3.2, virsh keeps disconnecting from qemu:///session. Weirdly enough, qemu:///session works fine for root, and qemu:///system works for both the user and the root. With the same configuration(tarball with files from /etc/libvirt attached), libvirt-1.3.1 works without problems. From the virsh debug log(attached): --- grep error virsh.log.1.3.2 2016-03-03

Hi all, I have been trying to find out cpu topology using libvirt. When I do 'virsh capabilites', I find this inside <topology> tag: <topology>       <cells num='1'>         <cell id='0'>           <memory unit='KiB'>3908488</memory>           <cpus num='4'>             <cpu id='0' socket_id='0'

Test libvirt-users-request@redhat.com schrieb: >Send libvirt-users mailing list submissions to > libvirt-users@redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/libvirt-users >or, via email, send a message with subject or body 'help' to > libvirt-users-request@redhat.com > >You can reach the

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

On Tue, Sep 17, 2013 at 05:41:12PM +0800, Peeyush Gupta wrote: > Hi all, > > I have been trying to find out cpu topology using libvirt. When > I do 'virsh capabilites', I find this inside <topology> tag: > > > <topology> >       <cells num='1'> >         <cell id='0'> >           <memory

Hi, Are there some kind of UUIDs for Host and Guest ? If yes , how may I retrieve them programmatically ? My goal is to trace GUEST migrations. Thx for help. Regards, J.P. Ribeauville P: +33.(0).1.47.17.27.87 Puteaux 3 Etage 5 Bureau 4 jpribeauville@axway.com<mailto:jpribeauville@axway.com> http://www.axway.com<http://www.axway.com/> P Pensez à l'environnement avant

On 04.03.2016 16:24, Predrag Ivanovic wrote: > Hi. > > Since the update to libvirt-1.3.2, virsh keeps disconnecting from qemu:///session. > Weirdly enough, qemu:///session works fine for root, and qemu:///system works for both the user and the root. > With the same configuration(tarball with files from /etc/libvirt attached), libvirt-1.3.1 works without problems. > > From

In the fake <domain type='physical'> libvirt XML that we create to describe the physical host, we did not accurately pass any information about the host CPU except the number of cores (<vcpu/>). This commit extracts detailed information about the vendor, model and topology of the host CPU and adds that to the libvirt XML for virt-v2v. Conveniently we can use libvirt

Don't get the CPU information from libvirt, because including libvirt and all dependencies in the virt-p2v ISO bloats everything. Instead get most of the information we need from the util-linux program 'lscpu'. Unfortunately the CPU model cannot be retrieved. Example output: $ ./run virt-p2v --cmdline="p2v.dump_config_and_exit" [...] cpu vendor . . . Intel cpu

I am doing an experiment which involves detecting co-resident VMs (testing if 2 VMs are on the same physical machine) on KVM. I have tried using cache covert channel, but this test does not work if the VMs are on different processors within the same host as the caches are not shared then. If I use the tools netperf and iperf to differentiate using network channels, I am not getting clear results.

This function was kind of like debug(), except that it didn't check the g->verbose flag and it only worked in the library (it would crash if used after fork). It also wasn't very useful. The sort of boot analysis done by tests/qemu/boot-analysis.c means that timestamping (some) messages is even less interesting than before. Remove it and replace calls with debug() instead. ---

Hi Is there a php api version for this? Regards Smon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20230107/e8b93ba9/attachment.htm>

On 1/7/23 16:15, Simon Fairweather wrote: > Hi > > Is there a php api version for this? There is now: https://gitlab.com/libvirt/libvirt-php/-/commit/af33dcf01243b81fe1d9b23ab105c1ba157cd9af Michal

Hi, some custom CPU models are reported from virConnectGetDomainCapabilities as usable='yes' on a physical machine while as usable='no' inside a VM running on the same machine. That's not completely surprising. But what surprises me is that those models are still reported from virConnectCompareCPU as supported (VIR_CPU_COMPARE_SUPERSET) in the nested environment and VMs can

https://bugzilla.redhat.com/show_bug.cgi?id=889082

On some architectures a certain machine type is used, so use it when querying the libvirt domain capabilities. --- lib/launch-libvirt.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c index 864eae314..f2cad9300 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -431,7 +431,12 @@ launch_libvirt (guestfs_h *g, void

lstopo, lstopo --output-format xml These commands might be helpful > On Mar 21, 2017, at 10:35 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > > > For virt-p2v we want to get the host CPU model, topology etc, and the > best way we found to do that was to pull it from libvirt > capabilities[1]. Since libvirt is already parsing the host CPU > information, and

Jiri Denemark <jdenemar@redhat.com> writes: > On Fri, Dec 07, 2018 at 11:52:38 +0100, Milan Zamazal wrote: >> Hi, some custom CPU models are reported from >> virConnectGetDomainCapabilities as usable='yes' on a physical machine > >> while as usable='no' inside a VM running on the same machine. That's >> not completely surprising. >>

<resending as I don't think I was in the mailing list yet when I sent first time... apologies if you receive this twice> Hello, I'm facing some strange behavior, and I hope you can provide a clarification. Consider the following code: virDomainPtr dom = virDomainLookupByName(virt, domain_name); if (dom) { printf("domain already