March 2011 - Devel - libvirt List Archives

[libvirt] [PATCH] do not return -1 when human-monitor-command is not supported
by Wen Congyang 17 Mar '11

17 Mar '11

It is not a fatal error if some monitor command is not supported. So we should not return -1 when human-monitor-command is not supported. Set reply_str to "unknown command: 'human-monitor-command'", and the caller can deal this error the same as the command that we want to run by human-monitor-command. Signed-off-by: Wen Congyang <wency(a)cn.fujitsu.com> --- src/qemu/qemu_monitor_json.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 13d12c8..7ec4ce7 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -694,6 +694,16 @@ qemuMonitorJSONHumanCommandWithFd(qemuMonitorPtr mon, if (!cmd || qemuMonitorJSONCommandWithFd(mon, cmd, scm_fd, &reply) < 0) goto cleanup; + if (qemuMonitorJSONHasError(reply, "CommandNotFound")) { + *reply_str = strdup("unknown command: 'human-monitor-command'"); + if (!*reply_str) { + virReportOOMError(); + goto cleanup; + } + ret = 0; + goto cleanup; + } + if (qemuMonitorJSONCheckError(cmd, reply)) goto cleanup; -- 1.7.1

2 1

[libvirt] [PATCH] spec: Guess rhel/fedora macros from dist
by Jiri Denemark 17 Mar '11

17 Mar '11

--- If anyone knows how to make rpm to evaluate %(...) immediately and not at every appearance of rhel/fedora, that would be really cool. libvirt.spec.in | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 02be928..bfc9206 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1,5 +1,11 @@ # -*- rpm-spec -*- +# if neither fedora nor rhel was defined, try to guess them from %{dist} +%if !0%{?rhel} && !0%{?fedora} +%define rhel %(echo "%{?dist}" | sed -ne 's/^\\.el\\([0-9]\\+\\).*/\\1/p') +%define fedora %(echo "%{?dist}" | sed -ne 's/^\\.fc\\?\\([0-9]\\+\\).*/\\1/p') +%endif + # A client only build will create a libvirt.so only containing # the generic RPC driver, and test driver and no libvirtd # Default to a full server + client build -- 1.7.4.1

3 10

[libvirt] /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file or directory (was: Re: Need help with virt_install)
by Richard W.M. Jones 17 Mar '11

17 Mar '11

On Wed, Mar 16, 2011 at 12:12:24PM -0700, JD wrote: > /virt-install \ > --connect qemu:///system \ > --name Fedora_14_i386 \ > --ram 500 \ > --disk path=/dev/sdc \ > --network network:default \ > --arch i386 \ > --os-variant fedora14 \ > --vnc \ > --location > http://mirrors.kernel.org/fedora/releases/14/Fedora/i386/os/ > > Starting install.../ / > Retrieving file .treeinfo... | 2.4 kB > 00:00 ... > Retrieving file vmlinuz... | 7.1 MB > 00:05 ... > Retrieving file initrd.img... | 60 MB > 00:45 ... > ERROR internal error Process exited while reading console log output: > libvir: error : cannot open > /sys/devices/system/cpu/cpu0/topology/physical_package_id: No such file > or directory > > Domain installation does not appear to have been > successful. If it was, you can restart your domain > by running 'virsh start Fedora_14_i386'; otherwise, please > restart your installation./ > > > is the missing /sys/devices/system/cpu/cpu0/topology/physical_package_id > caused by kernel configuration settings? > > > The relevant installed packages are: > > libguestfs-tools-1.6.2-1.fc13.4.i686 > python-virtinst-0.500.4-1.fc13.noarch > python-virtinst-0.500.4-1.fc13.noarch > virt-ctrl-1.0.1-4.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-mem-0.3.1-9.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-mem-0.3.1-9.fc12.i686 > python-virtinst-0.500.4-1.fc13.noarch > libguestfs-tools-1.6.2-1.fc13.4.i686 > python-virtinst-0.500.4-1.fc13.noarch > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-manager-0.8.5-1.fc13.noarch > virt-mem-0.3.1-9.fc12.i686 > libvirt-client-0.8.2-2.fc13.i686 > virt-mem-0.3.1-9.fc12.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > virt-top-1.0.4-3.fc13.i686 > virt-mem-0.3.1-9.fc12.i686 > virt-viewer-0.2.1-1.fc13.i686 > libguestfs-tools-1.6.2-1.fc13.4.i686 > libvirt-client-0.8.2-2.fc13.i686 (CCing libvir-list) I would say that this is a bug in libvirt. Since you are using quite an old version, can you try upgrading to the new libvirt in Fedora 14/15 and see if that fixes it? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

1 0

Re: [libvirt] [Qemu-devel] KVM call minutes for Mar 15
by Chris Wright 17 Mar '11

17 Mar '11

* Anthony Liguori (anthony(a)codemonkey.ws) wrote: > On 03/15/2011 09:53 AM, Chris Wright wrote: > > QAPI <snip> > >- c library implementation is critical to have unit tests and test > > driven development > > - thread safe? > > - no shared state, no statics. > > - threading model requires lock for the qmp session > > - licensiing? > > - LGPL > > - forwards/backwards compat? > > - designed with that in mind see wiki: > > > > http://wiki.qemu.org/Features/QAPI > > One neat feature of libqmp is that once libvirt has a better QMP > passthrough interface, we can create a QmpSession that uses libvirt. > > It would look something like: > > QmpSession *libqmp_session_new_libvirt(virDomainPtr dom); Looks like you mean this? -> request QmpSession -> client libvirt <- return QmpSession <- client -> QmpSession -> QMP -> QEMU So bypassing libvirt completely to actually use the session? Currently, it's more like: client -> QemuMonitorCommand -> libvirt -> QMP -> QEMU > The QmpSession returned by this call can then be used with all of > the libqmp interfaces. This means we can still exercise our test > suite with a guest launched through libvirt. It also should make > the libvirt pass through interface a bit easier to consume by third > parties. This sounds like it's something libvirt folks should be involved with. At the very least, this mode is there now and considered basically unstable/experimental/developer use: "Qemu monitor command '%s' executed; libvirt results may be unpredictable!" So likely some concern about making it easier to use, esp. assuming that third parties above are mgmt apps, not just developers. thanks, -chris

3 2

[libvirt] Network Interface: How to disable virbr0 correctly?
by Jake Xu 17 Mar '11

17 Mar '11

Hi all, Recently, I have been using libvirt to create virtual machines on ESX servers. It has been very well until to the point where I couldn't find any way to disable/remove the virbr0 interface properly. We use static configuration for VMs on ESX so we do not need to use virbr0 interface and we do not want libvirt to configure iptables as a result of the newly created virbr0 interface. I have tried to remove/rename the /etc/libvirt/qemu/networks/autostart.xml file, and that prevents virbr0 being installed. However, that also seems to prevent the second interface eth1 being configured properly. After libvirt defines a VM, eth0 and eht1 are both installed, but only eth0 is configured properly. The eth1 does not appear in the /etc/sysconfig/network-script/ifcfg-xxx file. It seems to me that the 'autostart.xml' file interrupts the configuration of the eth1 interface. Can anyone please advise how I can do this properly? Thanks a lot, Jake

3 6

[libvirt] attach/detach device in json mode
by Wen Congyang 17 Mar '11

17 Mar '11

Hi, all The qemu does not support monitor_command drive_add and drive_del in json mode. These two commands are important because attaching/detaching commands need them. AFAIK, if we use libvirt provided by RHEL6(not upstream), we connect to qemu in json mode. So, it is important to make qemu to support these monitor commands in json mode. Markus Armbruster(armbru(a)redhat.com) said these commands are designed badly, and he has started to work on saner commands some time ago: http://lists.nongnu.org/archive/html/qemu-devel/2011-02/msg02042.html He suggested us to use human monitor passthrough in the meantime. Should we modify libvirt to use human monitor passthrough command to support attaching/detaching device before the saner commands are ready?

5 11

[libvirt] [PATCH] macvtap: log an error if on failure to connect to netlink socket
by Laine Stump 16 Mar '11

16 Mar '11

A bug in libnl (see https://bugzilla.redhat.com/show_bug.cgi?id=677724 and https://bugzilla.redhat.com/show_bug.cgi?id=677725) makes it very easy to create a failure to connect to the netlink socket when trying to open a macvtap network device ("type='direct'" in domain interface XML). When that error occurred, there was no log message, leading virsh (for example) to report "unknown error". This patch logs a message which will hopefully be more useful. (All other error exits from the same function were already logging a message). --- src/util/macvtap.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/util/macvtap.c b/src/util/macvtap.c index a71db86..66bdc73 100644 --- a/src/util/macvtap.c +++ b/src/util/macvtap.c @@ -127,6 +127,8 @@ int nlComm(struct nl_msg *nl_msg, return -1; if (nl_connect(nlhandle, NETLINK_ROUTE) < 0) { + virReportSystemError(errno, + "%s", _("cannot connect to netlink socket")); rc = -1; goto err_exit; } -- 1.7.3.4

3 5

[libvirt] [PATCH] storage: Fix a problem which will cause libvirtd crashed
by Osier Yang 16 Mar '11

16 Mar '11

--- src/conf/storage_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 6e3fe0e..13a3622 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -396,7 +396,7 @@ virStoragePoolDefParseSource(xmlXPathContextPtr ctxt, char *authType = NULL; int nsource, i; virStoragePoolOptionsPtr options; - char *port; + char *port = NULL; relnode = ctxt->node; ctxt->node = node; -- 1.7.4

2 2

[libvirt] [PATCH 0/5] libvirt/qemu - allow modification of devices in inactive domain
by KAMEZAWA Hiroyuki 16 Mar '11

16 Mar '11

Now, Xen supports at(de)tach-disk, at(de)tach-interface for inactive domains with --perisitent option. (Using --persisten against live domain will cause error.) Now, virsh attach-xxx/detach-xxx cannot modify inactive domains in qemu and --persistent option just returns error. This series adds support for modification of inactive domain's disk, interfaces. Short description 1 ... clean up for Xen's driver 2 ... add my name to AUTHORS 3 ... add --persistent modification support, just a wrapper function. 4 ... add disk support 5 ... add nics support Thanks, -Kame

4 28

[libvirt] Possibly addition to python api binding virDomain class
by Russell Ballestrini 16 Mar '11

16 Mar '11

*In the python bindings of libvirt, could we please add the following code to the virDomain class? * def state(self): """return the state of the dom object""" return self.info()[0] *This helper function would make the world of difference when coding against the libvirt api. * -- *Russell J Ballestrini*

1 0