- Devel - libvirt List Archives

[libvirt] virsh help keywords vs. command prefixes
by Paul Jenner 04 Jan '11

04 Jan '11

Hi all. >From a quick play with virsh from the 0.8.7 pre-release, as an end user I wonder if it may be more intuitive for the new help keywords to match the virsh command prefixes where they exist. For example "help nwfilter" would tell me about nwfilter- commands. Some keywords follow the prefix convention (nodedev, secret, snapshot, pool) but some do not (interface vs. iface-, filter vs nwfilter-, network vs. net-, volume vs. vol-). Minor observation and close to release but I thought I would send on feedback to see what people thought. Paul

5 4

[libvirt] virsh + ssh
by Daniel Huhardeaux 04 Jan '11

04 Jan '11

Hi, connecting to a remote server using qemu+ssh is always done with root user. The problem we face is that we don't allow root connection for ssh. Would it be possible to launch sudo on the remote server so we could connect with the console user? Regards -- Daniel

3 2

[libvirt] [PATCH] build: avoid compilation warnings
by Eric Blake 03 Jan '11

03 Jan '11

Detected on cygwin: util/util.c: In function 'virSetUIDGID': util/util.c:2824: warning: format '%d' expects type 'int', but argument 7 has type 'gid_t' [-Wformat] (and three other lines) * src/util/util.c (virSetUIDGID): Cast, as is done elsewhere in this file, to avoid printf type mismatch warnings. --- Pushing under the build-breaker rule. src/util/util.c | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/util/util.c b/src/util/util.c index 197c571..60feb79 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -1,7 +1,7 @@ /* * utils.c: common, generic utility functions * - * Copyright (C) 2006-2010 Red Hat, Inc. + * Copyright (C) 2006-2011 Red Hat, Inc. * Copyright (C) 2006 Daniel P. Berrange * Copyright (C) 2006, 2007 Binary Karma * Copyright (C) 2006 Shuveb Hussain @@ -2822,7 +2822,8 @@ virSetUIDGID(uid_t uid, gid_t gid) if (gid > 0) { if (setregid(gid, gid) < 0) { virReportSystemError(errno, - _("cannot change to '%d' group"), gid); + _("cannot change to '%d' group"), + (unsigned int) gid); return -1; } } @@ -2844,14 +2845,15 @@ virSetUIDGID(uid_t uid, gid_t gid) getpwuid_r(uid, &pwd, buf, bufsize, &pwd_result); if (!pwd_result) { virReportSystemError(errno, - _("cannot getpwuid_r(%d)"), uid); + _("cannot getpwuid_r(%d)"), + (unsigned int) uid); VIR_FREE(buf); return -1; } if (initgroups(pwd.pw_name, pwd.pw_gid) < 0) { virReportSystemError(errno, _("cannot initgroups(\"%s\", %d)"), - pwd.pw_name, pwd.pw_gid); + pwd.pw_name, (unsigned int) pwd.pw_gid); VIR_FREE(buf); return -1; } @@ -2859,7 +2861,8 @@ virSetUIDGID(uid_t uid, gid_t gid) # endif if (setreuid(uid, uid) < 0) { virReportSystemError(errno, - _("cannot change to uid to '%d'"), uid); + _("cannot change to uid to '%d'"), + (unsigned int) uid); return -1; } } -- 1.7.3.4

1 0

[libvirt] [PATCH] node_device: udev driver does not handle SR-IOV devices
by Chris Wright 03 Jan '11

03 Jan '11

The udev driver does not update a PCI device with its SR-IOV capabilities, when applicable, the way the hal driver does. As a result, dumping the device's XML will not include the relevant physical or virtual function information. With this patch, the XML is correct: # virsh nodedev-dumpxml pci_0000_09_00_0 <device> <name>pci_0000_09_00_0</name> <parent>pci_0000_00_1c_0</parent> <driver> <name>vxge</name> </driver> <capability type='pci'> <domain>0</domain> <bus>9</bus> <slot>0</slot> <function>0</function> <product id='0x5833'>X3100 Series 10 Gigabit Ethernet PCIe</product> <vendor id='0x17d5'>Neterion Inc.</vendor> <capability type='virt_functions'> <address domain='0x0000' bus='0x0a' slot='0x00' function='0x1'/> <address domain='0x0000' bus='0x0a' slot='0x00' function='0x2'/> <address domain='0x0000' bus='0x0a' slot='0x00' function='0x3'/> </capability> </capability> </device> # virsh nodedev-dumpxml pci_0000_0a_00_1 <device> <name>pci_0000_0a_00_1</name> <parent>pci_0000_00_1c_0</parent> <driver> <name>vxge</name> </driver> <capability type='pci'> <domain>0</domain> <bus>10</bus> <slot>0</slot> <function>1</function> <product id='0x5833'>X3100 Series 10 Gigabit Ethernet PCIe</product> <vendor id='0x17d5'>Neterion Inc.</vendor> <capability type='phys_function'> <address domain='0x0000' bus='0x09' slot='0x00' function='0x0'/> </capability> </capability> </device> Cc: Dave Allan <dallan(a)redhat.com> Signed-off-by: Chris Wright <chrisw(a)redhat.com> --- src/node_device/node_device_udev.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 02e44a1..379af86 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -419,11 +419,11 @@ out: static int udevProcessPCI(struct udev_device *device, virNodeDeviceDefPtr def) { - const char *devpath = NULL; + const char *syspath = NULL; union _virNodeDevCapData *data = &def->caps->data; int ret = -1; - devpath = udev_device_get_devpath(device); + syspath = udev_device_get_syspath(device); if (udevGetUintProperty(device, "PCI_CLASS", @@ -432,7 +432,7 @@ static int udevProcessPCI(struct udev_device *device, goto out; } - char *p = strrchr(devpath, '/'); + char *p = strrchr(syspath, '/'); if ((p == NULL) || (udevStrToLong_ui(p+1, &p, @@ -487,6 +487,9 @@ static int udevProcessPCI(struct udev_device *device, goto out; } + get_physical_function(syspath, data); + get_virtual_functions(syspath, data); + ret = 0; out:

3 3

[libvirt] libvirtd and listen_addr
by Daniel Huhardeaux 01 Jan '11

01 Jan '11

Hi, at first, best wishes to all for this new year. We have a request: would it be possible to start libvirtd listen_addr *after* the VM network is up? We have VPN through different libvirt+kvm servers and want to virsh connect to the private VM network address of each server instead of his VPN IP. The problem is that libvirt doesn't start with unknown IP address. If network would be already up, libvirt could listen on this address. Regards libvirtd (libvirt) 0.8.3 - Debian stable + backports -- Daniel

1 0

[libvirt] [PATCH] virExec: fix logic bug
by Eric Blake 31 Dec '10

31 Dec '10

As pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=659855#c9, commit c3568ec2 introduced a regression where we no longer close any fd's beyond FD_SETSIZE. * src/util/util.c (__virExec): Continue to close fd's beyond keepfd range. Reported by Stefan Praszalowicz. --- src/util/util.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/util.c b/src/util/util.c index d6fa81b..197c571 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -570,7 +570,7 @@ __virExec(const char *const*argv, i != null && i != childout && i != childerr && - (!keepfd || (i < FD_SETSIZE && !FD_ISSET(i, keepfd)))) { + (!keepfd || i >= FD_SETSIZE || !FD_ISSET(i, keepfd))) { tmpfd = i; VIR_FORCE_CLOSE(tmpfd); } -- 1.7.3.4

2 3

[libvirt] [PATCH 1/3] Virtual network cleanup/bugfixes
by Laine Stump 31 Dec '10

31 Dec '10

The first two patches remedy a bug found by Stefan Berger in the new brAddInetInterface() function that resulted in the broadcast address not being properly set. This is a regression from previous releases, so it should be pushed prior to the upcoming release. The third patch improves the API for a couple of functions that were recently added, but does not change any behavior. I'd be happy pushing it now or after the release.

2 9

[libvirt] [PATCHv2 00/13] IPv6 support for virtual networks using bridge driver
by Laine Stump 31 Dec '10

31 Dec '10

This is a resend of https://www.redhat.com/archives/libvir-list/2010-December/msg00765.html incorporating changes due to comments from Eric Blake and Paweł Krześniak. changes from v1 to v2 are noted in each individual mail ----- Most of this patchset is setup for patch 09/13, which updates the network XML parser to support IPv6, and 12/13, which turns on IPv6 in the bridge driver. In order to have each patch individually pass make check and (otherwise function properly in case someone is doing a bisect), there is a bit of extra code churn (lines that are changed in one patch, only to be changed again in a later patch); I tried to minimize this as much as possible. For for IPv6 to work correctly, target *and build* systems will now need to have ip6tables and radvd available. The way I added ip6tables into autoconfigure.ac is identical to existing iptables, and the way I added radvd is identical to dnsmasq. Unfortunately this doesn't communicate the requirement downstream in a programmatic fashion, so I guess we need to make sure that this is adequately reported in the next set of release notes.

4 39

[libvirt] subscribe
by Stefan Majer 30 Dec '10

30 Dec '10

subscribe -- Stefan Majer

1 0

[libvirt] potential bug in qemu snapshots
by Eric Blake 30 Dec '10

30 Dec '10

Right now, we create qemu snapshots to a file by using an exec: monitor command that passes 'compressor | { dd && dd; }' with stdout connected to the target file. However, since dd is using a larger bs= than PIPE_MAX, it is conceivable that under heavy machine load, that dd will get a short read from the pipe, and unless we use the GNU extension of iflag=fullblock, that short read will be padded out to the output block size and result in data corruption in the destination file. The possibility of corruption due to short reads when dd is fed input through a pipe but produces output through a large block size has occurred several times on the coreutils mailing list: http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00092.html Coreutils currently obeys the (non-intuitive) POSIX requirements for this short read behavior, and while it is being considered to make dd when POSIXLY_CORRECT is unset be more sensible, you can't rely on that being a default. Should we refuse to make snapshots if we don't detect the GNU extension of 'dd iflag=fullblock'? Probably safe to do on GNU/Linux machines, but I'm wondering if it will have negative effects on BSD machines where GNU coreutils is not installed. Is there a way to make monitor commands use fd: style migration, where we can avoid dd altogether by just passing an already open fd that has already positioned correctly via lseek()? Then again, it seems like fd: migration requires passing an open fd, which only seems possible on the command line at startup rather than something you can do on the fly with monitor commands. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

3 5