- Devel - libvirt List Archives

[libvirt] [PATCH] nodeinfo: fix to parse present cpus rather than possible cpus
by Kothapally Madhu Pavan 12 Jun '15

12 Jun '15

Currently we are parsing all the possible cpus to get the nodeinfo. This fix will perform a check for present cpus before parsing. Signed-off-by: Kothapally Madhu Pavan <kmp(a)linux.vnet.ibm.com> --- src/nodeinfo.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/nodeinfo.c b/src/nodeinfo.c index 2fafe2d..9e6684f 100644 --- a/src/nodeinfo.c +++ b/src/nodeinfo.c @@ -57,6 +57,7 @@ #define VIR_FROM_THIS VIR_FROM_NONE VIR_LOG_INIT("nodeinfo"); +virBitmapPtr nodeGetPresentCPUBitmap(void); #if defined(__FreeBSD__) || defined(__APPLE__) static int @@ -418,6 +419,7 @@ virNodeParseNode(const char *node, int processors = 0; DIR *cpudir = NULL; struct dirent *cpudirent = NULL; + virBitmapPtr present_cpumap = NULL; int sock_max = 0; cpu_set_t sock_map; int sock; @@ -438,12 +440,17 @@ virNodeParseNode(const char *node, goto cleanup; } + present_cpumap = nodeGetPresentCPUBitmap(); + /* enumerate sockets in the node */ CPU_ZERO(&sock_map); while ((direrr = virDirRead(cpudir, &cpudirent, node)) > 0) { if (sscanf(cpudirent->d_name, "cpu%u", &cpu) != 1) continue; + if (!(virBitmapIsBitSet(present_cpumap, cpu))) + continue; + if ((online = virNodeGetCpuValue(node, cpu, "online", 1)) < 0) goto cleanup; @@ -477,6 +484,9 @@ virNodeParseNode(const char *node, if (sscanf(cpudirent->d_name, "cpu%u", &cpu) != 1) continue; + if (!(virBitmapIsBitSet(present_cpumap, cpu))) + continue; + if ((online = virNodeGetCpuValue(node, cpu, "online", 1)) < 0) goto cleanup;

2 1

[libvirt] Accessing libvirtd remotely as non-root user
by Dan Mossor 12 Jun '15

12 Jun '15

I manage libvirtd on a few remote machines, and my security policies require me to disable root login via SSH. Up to this point, I've been using root due to the systems being in staging, but this is the final step before they're moved to production. What is the current proscribed method of connecting virt-manager or virsh to a remote system with a non-root account? I keep getting "authentication failed: no agent is available to authenticate" with a user that is in the kvm and qemu groups on the systems I've tried using the ssh transport. Thanks in advance Dan -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA

3 5

[libvirt] [PATCH] virsysinfo: s/system/sysdef/
by Michal Privoznik 12 Jun '15

12 Jun '15

A variable can't be named system, obviously. Well, it can if the compiler is new enough to distinguish a variable named system and a function call system(). And some older systems, don't have wise compiler. Whatever. CC util/libvirt_util_la-virsysinfo.lo cc1: warnings being treated as errors ../../src/util/virsysinfo.c: In function 'virSysinfoParseSystem': ../../src/util/virsysinfo.c:649: error: declaration of 'system' shadows a global declaration [-Wshadow] /usr/include/stdlib.h:717: error: shadowed declaration is here [-Wshadow] make[3]: *** [util/libvirt_util_la-virsysinfo.lo] Error 1 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virsysinfo.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 692c921..42cd946 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -150,7 +150,7 @@ void virSysinfoDefFree(virSysinfoDefPtr def) #if defined(__powerpc__) static int -virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) +virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *sysdef) { int ret = -1; char *eol = NULL; @@ -193,7 +193,7 @@ virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) def = NULL; } - *system = def; + *sysdef = def; def = NULL; ret = 0; cleanup: @@ -280,7 +280,7 @@ virSysinfoRead(void) #elif defined(__arm__) || defined(__aarch64__) static int -virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) +virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *sysdef) { int ret = -1; char *eol = NULL; @@ -323,7 +323,7 @@ virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) def = NULL; } - *system = def; + *sysdef = def; def = NULL; ret = 0; cleanup: @@ -452,7 +452,7 @@ virSysinfoParseLine(const char *base, const char *name, char **value) } static int -virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) +virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *sysdef) { int ret = -1; virSysinfoSystemDefPtr def; @@ -478,7 +478,7 @@ virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) def = NULL; } - *system = def; + *sysdef = def; def = NULL; ret = 0; cleanup: @@ -646,7 +646,7 @@ virSysinfoParseBIOS(const char *base, virSysinfoBIOSDefPtr *bios) } static int -virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) +virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *sysdef) { int ret = -1; const char *cur, *eol = NULL; @@ -708,7 +708,7 @@ virSysinfoParseSystem(const char *base, virSysinfoSystemDefPtr *system) def = NULL; } - *system = def; + *sysdef = def; def = NULL; ret = 0; cleanup: -- 2.3.6

2 1

[libvirt] [PATCH 0/2] Introduce new net-list switches
by Michal Privoznik 12 Jun '15

12 Jun '15

I think they might be helpful. Michal Privoznik (2): cmdNetworkList: switch to FILTER cmdNetworkList: Introduce --name, --uuid, --table tools/virsh-network.c | 93 ++++++++++++++++++++++++++++++++++----------------- tools/virsh.pod | 7 ++++ 2 files changed, 70 insertions(+), 30 deletions(-) -- 2.3.6

2 3

[libvirt] [PATCH] virQEMUCapsArch: openrisc vs or32
by Michal Privoznik 12 Jun '15

12 Jun '15

With a few exceptions, we assume that qemu binary for given architecture has form of qemu-system-$arch. Well, openrisc is yet another exception. It's binary is called qemu-system-or32. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_capabilities.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index c519aec..8a64422 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -358,6 +358,8 @@ static virArch virQEMUCapsArchFromString(const char *arch) return VIR_ARCH_I686; if (STREQ(arch, "arm")) return VIR_ARCH_ARMV7L; + if (STREQ(arch, "or32")) + return VIR_ARCH_OR32; return virArchFromString(arch); } @@ -369,6 +371,8 @@ static const char *virQEMUCapsArchToString(virArch arch) return "i386"; else if (arch == VIR_ARCH_ARMV7L) return "arm"; + else if (arch == VIR_ARCH_OR32) + return "or32"; return virArchToString(arch); } -- 2.3.6

2 1

[libvirt] [PATCH] qemuBuildDriveStr: s/virBufferEscapeString/virBufferAsprintf/
by Michal Privoznik 12 Jun '15

12 Jun '15

We are using it to print a value that can't be NULL and does not need any escaping anyway. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 61faa57..b8cdd3c 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3724,7 +3724,7 @@ qemuBuildDriveStr(virConnectPtr conn, disk->geometry.sectors); if (disk->geometry.trans != VIR_DOMAIN_DISK_TRANS_DEFAULT) - virBufferEscapeString(&opt, ",trans=%s", trans); + virBufferAsprintf(&opt, ",trans=%s", trans); } if (disk->serial && -- 2.3.6

2 1

[libvirt] [PATCH] scsi: Need to translate disk source pool in config attach path
by John Ferlan 12 Jun '15

12 Jun '15

https://bugzilla.redhat.com/show_bug.cgi?id=1228007 When attaching a scsi volume lun via the attach-device --config or --persistent options, there was no translation of the source pool like there was for the live path, thus the attempt to modify the config would fail since not enough was known about the disk. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/qemu/qemu_driver.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 34e5581..6bb8549 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -8016,7 +8016,8 @@ qemuDomainUpdateDeviceLive(virConnectPtr conn, static int qemuDomainAttachDeviceConfig(virQEMUCapsPtr qemuCaps, virDomainDefPtr vmdef, - virDomainDeviceDefPtr dev) + virDomainDeviceDefPtr dev, + virConnectPtr conn) { virDomainDiskDefPtr disk; virDomainNetDefPtr net; @@ -8033,6 +8034,8 @@ qemuDomainAttachDeviceConfig(virQEMUCapsPtr qemuCaps, _("target %s already exists"), disk->dst); return -1; } + if (virStorageTranslateDiskSourcePool(conn, disk) < 0) + return -1; if (qemuCheckDiskConfig(disk) < 0) return -1; if (virDomainDiskInsert(vmdef, disk)) @@ -8501,7 +8504,8 @@ static int qemuDomainAttachDeviceFlags(virDomainPtr dom, const char *xml, VIR_DOMAIN_DEVICE_ACTION_ATTACH) < 0) goto endjob; - if ((ret = qemuDomainAttachDeviceConfig(qemuCaps, vmdef, dev)) < 0) + if ((ret = qemuDomainAttachDeviceConfig(qemuCaps, vmdef, dev, + dom->conn)) < 0) goto endjob; } -- 2.1.0

2 4

[libvirt] [RFC] get guest OS infos
by zhang bo 12 Jun '15

12 Jun '15

Different OSes have different capabilities and behaviors sometimes. We have to distinguish them then. For example, our clients want to send NMI interrupts to certain guests(eg.Linux distributions), but not others(eg.Windows guests). They want to acquire the list below: guest1: RHEL 7 guest2: RHEL 7 guest3: Ubuntu 12 guest4: Ubuntu 13 guest5: Windows 7 ...... AFAIK, neither libvirt nor openstack, nor qemu, have such capbility of showing these guest OS infos. Libvirt now supports to show host capabilities and driver capability, but not an individual guest OS's capibility. We may refer to http://libvirt.org/formatdomaincaps.html for more information. So, what's your opinion on adding such feature in libvirt and qemu? ----------------------------------------------------------------------- The solution I can see is: 1 add a new qga command in qemu agent, 'guest-get-osinfo', which gets the os infos by qemu-agent inside the guest. { 'command': 'guest-get-osinfo', 'returns': ['GuestOSInfo'] } { 'struct': 'GuestOSInfo', 'data': {'distribution': 'GuestOSDistribution', 'version': 'int', 'arch': 'GuestOSArchType'} } an example Json result: {"return": {"distribution": "RHEL", "version": "7", "arch": "x86_64" } } 2 add new helper APIs for that qga command in libvirt. qemuAgentGetOSInfo() 3 When the guest starts up and its qemu-agent is running, call qemuAgentGetOSINfo() in libvirt. 4 set the osinfo, which is got at step 3, into the guest's status and config file. <domainCapabilities> <path>/usr/bin/qemu-system-x86_64</path> <domain>kvm</domain> <machine>pc-i440fx-2.1</machine> <arch>x86_64</arch> <distribution> <type>RHEL</type> <version>7</version> </distribution> ... </domainCapabilities> This feature is added into the xml node 'domainCapabilities' here. If there's any other better choice, please let me know. -- Oscar oscar.zhangbo(a)huawei.com

5 9

[libvirt] [PATCH] tests: Distribute virnetserverdata
by Michal Privoznik 12 Jun '15

12 Jun '15

Fairly recently we've introduced virnetservertest. This test has some input data stored under tests/virnetserverdata which unfortunately was not distributed among with the test. Therefore 'make distcheck' failed. Fix this by adding the directory into EXTRA_DIST. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Pushed under trivial and build-breaker rules. tests/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index c9e2c8a..b3a0e4b 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -138,6 +138,7 @@ EXTRA_DIST = \ vircgroupdata \ virfiledata \ virnetdevtestdata \ + virnetserverdata \ virpcitestdata \ virscsidata \ virusbtestdata \ -- 2.3.6

1 0

Re: [libvirt] Problem with setting up KVM guests to use HugePages
by Michal Privoznik 11 Jun '15

11 Jun '15

[please keep the list CC'ed] On 10.06.2015 20:09, Clarylin L wrote: > Hi Michal, > > Thanks a lot. > > If 100 hugepages are pre-allocated, the guest can start without decreasing > number of hugepages. Since the guest requires 128 hugepages, it's kind of > expected that the guest would not take memory from hugepages. > > Before guest start, > > [root@local ~]# cat /proc/meminfo | grep uge > > AnonH*uge*Pages: 0 kB > > H*uge*Pages_Total: 100 > > H*uge*Pages_Free: 100 > > H*uge*Pages_Rsvd: 0 > > H*uge*Pages_Surp: 0 > H*uge*pagesize: 1048576 kB > > After: > > [root@local ~]# cat /proc/meminfo | grep uge > > AnonH*uge*Pages: 134254592 kB > > H*uge*Pages_Total: 100 > > H*uge*Pages_Free: 100 > > H*uge*Pages_Rsvd: 0 > > H*uge*Pages_Surp: 0 > H*uge*pagesize: 1048576 kB > > There is no -mem-prealloc and -mem-path options in qemu command And there can't be. From the command line below, you are defining 2 NUMA nodes for your guest. In order to instruct qemu to back their memory by huge pages you need it to support memory-backend-file object which was introduced in qemu-2.1.0. The other option you have is to not use guest NUMA nodes, in which case global -mem-path can be used. > > [root@local ~]# ps -ef | grep qemu > > *qemu* 3403 1 99 17:42 ? 00:36:42 /usr/libexec/*qemu*-kvm > -name qvpc-di-03-sf -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -cpu > host -m 131072 -realtime mlock=off -smp 32,sockets=2,cores=16,threads=1 > -numa node,nodeid=0,cpus=0-15,mem=65536 -numa > node,nodeid=1,cpus=16-31,mem=65536 -uuid > e1b72349-4a0b-4b91-aedc-fd34e92251e4 -smbios type=1,serial=SCALE-SLOT-03 > -no-user-config -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/*qemu*/qvpc-di-03-sf.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown > -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive > file=/var/lib/libvirt/images/asr5700/qvpc-di-03-sf-hda.img,if=none,id=drive-ide0-0-0,format=qcow2 > -device > ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 -drive > if=none,id=drive-ide0-1-0,readonly=on,format=raw -device > ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 > -chardev pty,id=charserial0 -device > isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 > -device isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:0 -vga > cirrus -device i6300esb,id=watchdog0,bus=pci.0,addr=0x3 -watchdog-action > reset -device vfio-pci,host=08:00.0,id=hostdev0,bus=pci.0,addr=0x5 -device > vfio-pci,host=09:00.0,id=hostdev1,bus=pci.0,addr=0x6 -device > vfio-pci,host=0a:00.0,id=hostdev2,bus=pci.0,addr=0x7 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on > > > If 140 hugepages are preallocated, the guest cannot start and it complained > not enough memory. > > > The libvirt version is shown as follows: > > virsh # version > > Compiled against library: libvirt 1.2.8 > > Using library: libvirt 1.2.8 > > Using API: QEMU 1.2.8 > > Running hypervisor: QEMU 1.5.3 > > > Also in guest configuration contains numa session. The hugepages are > uniformly distributed to two nodes. In this case, do I need to make > additional configurations to enable usage of hugepages? > > <numatune> > > <memory mode='strict' nodeset='0-1'/> > > </numatune> > This says that all the memory for you guests should be pinned onto host nodes 0-1. If you want to be more specific, you can explicitly wire guest NUMA nodes onto host NUMA nodes in 1:N relationship (where N can be even 1, in which case you will get 1:1), e.g.: <memnode cellid='0' mode='preferred' nodeset='0'/> Michal

2 3