- Devel - libvirt List Archives

[libvirt] [PATCH] avoid using deprecated udev logging functions
by Daniel P. Berrange 17 Dec '14

17 Dec '14

In systemd >= 218, the udev_set_log_fn method has been marked deprecated and turned into a no-op. Nothing in the udev client library will print to stderr by default anymore, so we can just stop installing a logging hook for new enough udev. --- m4/virt-udev.m4 | 7 +++++++ src/node_device/node_device_udev.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/m4/virt-udev.m4 b/m4/virt-udev.m4 index 55673bf..0d785c4 100644 --- a/m4/virt-udev.m4 +++ b/m4/virt-udev.m4 @@ -24,6 +24,13 @@ AC_DEFUN([LIBVIRT_CHECK_UDEV],[ if test "$with_udev" = "yes" && test "$with_pciaccess" != "yes" ; then AC_MSG_ERROR([You must install the pciaccess module to build with udev]) fi + + if test "$with_udev" = "yes" ; then + PKG_CHECK_EXISTS(libudev >= 218, [with_udev_logging=no], [with_udev_logging=yes]) + if test "$with_udev_logging" = "yes" ; then + AC_DEFINE_UNQUOTED([HAVE_UDEV_LOGGING], 1, [whether libudev logging can be used]) + fi + fi ]) AC_DEFUN([LIBVIRT_RESULT_UDEV],[ diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 343ef85..1a35c07 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -340,7 +340,7 @@ static int udevGenerateDeviceName(struct udev_device *device, return ret; } - +#if HAVE_UDEV_LOGGING typedef void (*udevLogFunctionPtr)(struct udev *udev, int priority, const char *file, @@ -373,6 +373,7 @@ udevLogFunction(struct udev *udev ATTRIBUTE_UNUSED, VIR_FREE(format); } +#endif static int udevTranslatePCIIds(unsigned int vendor, @@ -1759,8 +1760,10 @@ static int nodeStateInitialize(bool privileged, * its return value. */ udev = udev_new(); +#if HAVE_UDEV_LOGGING /* cast to get rid of missing-format-attribute warning */ udev_set_log_fn(udev, (udevLogFunctionPtr) udevLogFunction); +#endif priv->udev_monitor = udev_monitor_new_from_netlink(udev, "udev"); if (priv->udev_monitor == NULL) { -- 2.1.0

3 4

[libvirt] [PATCH V2 0/5] support sending sysrq key
by Chunyan Liu 17 Dec '14

17 Dec '14

xend/libxl support sending sysrq key to guest kernel but not support sending any key sequence as virDomainSendKey is expected to do. To add equivalant sysrq functionality in libvirt for xen/libxl, add a new virDomainSendSysrq API and add related codes to virsh, remote driver, xen/libxl driver. Changes: * add new API virDomainSendSysrq instead of hacking virDomainSendKey. * add related changes according to new API, including libvirt API, remote protocol, virsh and libxl/xen driver. v1 is here: https://www.redhat.com/archives/libvir-list/2014-December/msg00480.html Chunyan Liu (5): Add public API virDomainSendSysrq implement remote protocol for domainSendSysrq virsh: add 'sysrq' command libxl: implement .domainSendSysrq method xen: add .domainSendSysrq method include/libvirt/libvirt-domain.h | 3 +++ src/driver-hypervisor.h | 4 +++ src/libvirt-domain.c | 38 ++++++++++++++++++++++++++++ src/libvirt_public.syms | 1 + src/libxl/libxl_driver.c | 23 +++++++++++++++++ src/remote/remote_driver.c | 2 +- src/remote/remote_protocol.x | 13 +++++++++- src/xen/xen_driver.c | 19 ++++++++++++++ src/xen/xend_internal.c | 20 +++++++++++++++ src/xen/xend_internal.h | 2 ++ tools/virsh-domain.c | 54 ++++++++++++++++++++++++++++++++++++++++ 11 files changed, 177 insertions(+), 2 deletions(-) -- 1.8.4.5

7 21

[libvirt] virDomainGetBlockInfo meanings
by Eric Blake 17 Dec '14

17 Dec '14

I'm really struggling with how to interpret the virDomainBlockInfo struct, and think that we may want to consider the current behavior buggy and offer improved behavior going forward. For starters, even though the stats reported by virDomainListGetStats are _supposed_ to mirror the older API of virDomainGetBlockInfo, they currently do not (the newer API reads values from qemu, the older API reads values from stat) - in order to make the two consistent, I need to share code - but in order to share code, I need to know WHICH values make the most sense. Here's the current documentation: /** virDomainBlockInfo: * * This struct provides information about the size of a block device * backing store * * Examples: * * - Fully allocated raw file in filesystem: * * capacity, allocation, physical: All the same * * - Sparse raw file in filesystem: * * capacity: logical size of the file * * allocation, physical: number of blocks allocated to file * * - qcow2 file in filesystem * * capacity: logical size from qcow2 header * * allocation, physical: logical size of the file / * highest qcow extent (identical) * * - qcow2 file in a block device * * capacity: logical size from qcow2 header * * allocation: highest qcow extent written for an active domain * * physical: size of the block device container */ typedef struct _virDomainBlockInfo virDomainBlockInfo; typedef virDomainBlockInfo *virDomainBlockInfoPtr; struct _virDomainBlockInfo { unsigned long long capacity; /* logical size in bytes of the block device backing image */ unsigned long long allocation; /* highest allocated extent in bytes of the block device backing image */ unsigned long long physical; /* physical size in bytes of the container of the backing image */ }; I interpret this to mean that 'capacity' is the size that the guest sees, that 'allocation' is how much host space is required to represent that to the guest, and 'physical' is the size of the container on the host. So there are at least two things that strike me as incorrect or confusing in that documentation. First, our usage of 'physical' in the examples _changes_ depending on whether the file is raw or a block device. I think that 'physical' should represent the size of a file that 'ls' would show, no matter what, while 'allocation' is what 'du' would show. That is, for the 'sparse raw file in filesystem', I think we want 'capacity == physical == size guest would see', and only 'allocation' would be smaller; our example of 'physical == allocation' for a sparse file sounds wrong, because 'physical' should be the size of the container (the host file) rather than the amount of host storage used. Second, when this struct was first introduced, it predated the ability of the kernel to punch holes in a file. But now qemu can do a very good job of reclaiming space in a qcow2 file by punching holes and making the file sparse. So I think that 'qcow2 file in filesystem' should allow for 'allocation < physical' - again, with the notion that 'physical' is the size of the qcow2 file in the host that 'ls' would show, and 'allocation' is the storage occupied on the host as 'du' would show. This would make things more consistent with the 'qcow2 file in a block device', where 'physical' is the size of the device (well, 'ls' doesn't show that, so you have to open/lseek the device to find it) and where 'allocation' is the amount of the device used (here, relying on qemu to tell us the highest extent written so far, since block devices don't have holes). Oh, and qemu has a limitation - it only reports highest extent written when it actually writes to an image; if a file is opened read-only (such as a backing file), qemu reports 0 as the highest extent written, even though that cannot be true (for a qcow2 file to exist, at least the first cluster must have been previously written with metadata) - so it would be nice if future qemu could be patched to determine the highest extent when opening an image, rather than on first write to the image. Also, it is annoying that qemu splits its reporting: 'capacity' is reported via 'query-block' (the "actual-size" value); this command also gives what appears to be a great 'physical' value for files (the "actual-size" parameter) although that size is always 0 for block devices; meanwhile, the highest extent written ('allocation' for block devices) is reported via 'query-blockstats' (the "wr_highest_offset" value). Can anyone give a reason why changing semantics of 'physical' and 'allocation' as mentioned above would negatively break backwards compatibility, rather than being considered a bug fix? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

2 2

[libvirt] [PATCH] Buffer size too small when reading sysinfo on S390
by Boris Fiuczynski 16 Dec '14

16 Dec '14

On a system with 160 CPUs the /proc/cpuinfo size grows beyond the currently set limit of 10KB causing an internal error. This patch increases the buffer size for S390 to 64KB. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- src/util/virsysinfo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 1bb6392..613bab9 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -377,6 +377,8 @@ virSysinfoRead(void) # pragma GCC diagnostic ignored "-Wlogical-op" # endif +# define S390_CPUINFO_FILE_LEN (64*1024) /* 64KB limit for /proc/cpuinfo file */ + static char * virSysinfoParseDelimited(const char *base, const char *name, char **value, char delim1, char delim2) @@ -471,7 +473,7 @@ virSysinfoRead(void) goto no_memory; /* Gather info from /proc/cpuinfo */ - if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) { + if (virFileReadAll(CPUINFO, S390_CPUINFO_FILE_LEN, &outbuf) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to open %s"), CPUINFO); return NULL; -- 1.9.3

3 3

[libvirt] How to use blockcopy in libvirt-java
by Star Guo 16 Dec '14

16 Dec '14

Hi, ALL, I just look for the class and method to use blockcopy in libvirt-java on this page: http://libvirt.org/sources/java/javadoc/ However, I can not find out. Libvirt-java Support blockcopy ? Thanks. Best Regards, Star Guo

2 1

[libvirt] [RFC] The Quest for Domain-IP Mapping Continues...
by Nehal J Wani 16 Dec '14

16 Dec '14

If you remember correctly, about 1.2 years ago, we had... https://www.redhat.com/archives/libvir-list/2013-September/msg00351.html In short, the patch proposed a generalized mechanism for finding out IP addresses, with flags for choosing method(s) (SNOOP|LEASE|AGENT). But since not all methods were supported (only qemu-ga worked), the API was deferred. After exploring a bit, it seems that in all, we can have: (i) Leases Method (ii) Qemu Guest Agent (iiI) DHCP Snooping (exists, but isn't publicly exposed?) (iv) ARP Snooping (we can ask the virtual network interfaces to share their arp tables with the public?) Now that we have the dhcp-leases API fully furnished, why not visit the qemu-guest-agent again? OP1. Should we have separate APIs + virsh commands for each one of these and then combine them together under virDomainInterfaceAddresses? - If each one has to be a different API and then combined later, then what should be the corresponding name for the virsh command for exposing the querying guest agent API? OP2. Implement virDomainInterfaceAddresses API with two flags, one for dhcp-leases and another for qemu-ga and keep adding others whenever they are completed? I would prefer OP1. What do you guys think? -- Nehal J Wani

3 5

[libvirt] [PATCH 0/3] Various build fixes
by Martin Kletzander 16 Dec '14

16 Dec '14

Fix some problems coverity and mingw build found out. Martin Kletzander (3): qemu: Add missing goto error in qemuRestoreCgroupState qemu: Free saved error in qemuDomainSetVcpusFlags util: Fix fallocate stubs for mingw build src/qemu/qemu_cgroup.c | 1 + src/qemu/qemu_driver.c | 1 + src/util/virfile.c | 38 +++++++++++++++++++++++++++++++------- 3 files changed, 33 insertions(+), 7 deletions(-) -- 2.2.0

2 9

[libvirt] [PATCH] conf: Fix invalid condition when parsing storage owner
by Martin Kletzander 16 Dec '14

16 Dec '14

In commit d2632d60 we agreed taht we want the parsed uid to properly overflow but only to -1, however the value was read into long and then wrapped into uid_t. That meaned it failed on 32-bit systems. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Notes: Pushed as build-breaker src/conf/storage_conf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index e1be064..e9aaa8a 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -734,7 +734,7 @@ virStorageDefParsePerms(xmlXPathContextPtr ctxt, int defaultmode) { char *mode; - long val; + long long val; int ret = -1; xmlNodePtr relnode; xmlNodePtr node; @@ -771,7 +771,7 @@ virStorageDefParsePerms(xmlXPathContextPtr ctxt, if (virXPathNode("./owner", ctxt) == NULL) { perms->uid = (uid_t) -1; } else { - if (virXPathLong("number(./owner)", ctxt, &val) < 0 || + if (virXPathLongLong("number(./owner)", ctxt, &val) < 0 || ((uid_t)val != val && val != -1)) { virReportError(VIR_ERR_XML_ERROR, "%s", @@ -785,7 +785,7 @@ virStorageDefParsePerms(xmlXPathContextPtr ctxt, if (virXPathNode("./group", ctxt) == NULL) { perms->gid = (gid_t) -1; } else { - if (virXPathLong("number(./group)", ctxt, &val) < 0 || + if (virXPathLongLong("number(./group)", ctxt, &val) < 0 || ((gid_t) val != val && val != -1)) { virReportError(VIR_ERR_XML_ERROR, "%s", -- 2.2.0

1 0

[libvirt] [PATCH 0/2] Use correct syntax for thin/sparse pool creation
by John Ferlan 16 Dec '14

16 Dec '14

https://bugzilla.redhat.com/show_bug.cgi?id=1166592 More recent versions of LVM have resulted in the inability to recognize a newly created thin logical volume using libvirt. Not sure exactly which lvm release resulted in the change, but it's some time between 2.02.106 and 2.02.113 or lvm library version 1.02.85 and 1.02.92. The short story is libvirt was not really creating thin logical volumes, instead libvirt was creating thin snapshot logical volumes. More recent changes in LVM seem to now differentiate the two and the way libvirt was creating it's logical volumes "now defaulted" to the thin logical volume, which libvirt was not able to parse properly. The commit message for patch 1 has the gory details - figured it was best to keep it in the commit message rather than be lost to some cover letter. The second patch adds the ability to get the allocation and capacity for logical volumes from a volResize callback. This will be important for the thin logical volumes in order to determine the capacity which is stored in the thin logical volume pool John Ferlan (2): logical: Use correct syntax for thin/sparse pool creation logical: Introduce virStorageBackendLogicalRefreshVol src/storage/storage_backend_logical.c | 216 +++++++++++++++++++++++++++++++--- src/util/virstoragefile.h | 1 + 2 files changed, 199 insertions(+), 18 deletions(-) -- 1.9.3

4 6

[libvirt] [PATCH 0/2] Refactor safezero and virStorageFileResize
by John Ferlan 16 Dec '14

16 Dec '14

Originally included as part of a series to fix a problem with file creation and resize within NFS storage pools that ended up being an issue somewhere lower in the stack of posix_fallocate or the setting of the block size in the meta data. The following two patches extract out the refactoring of safezero and reworking virStorageFileResize to utilize safezero instead. Original series and review comments for comparison: http://www.redhat.com/archives/libvir-list/2014-August/msg00491.html I figured rather than lose any of the code and there is some value in utilizing the same code in order to handle a similar function that I'd repost as a separate series. John Ferlan (2): virfile: Refactor safezero virstoragefile: Have virStorageFileResize use safezero src/locking/lock_driver_sanlock.c | 4 +-- src/storage/storage_backend.c | 2 +- src/util/virfile.c | 63 +++++++++++++++++++++++++++++++++------ src/util/virfile.h | 2 +- src/util/virstoragefile.c | 29 ++++++------------ 5 files changed, 67 insertions(+), 33 deletions(-) -- 1.9.3

2 3