[libvirt] Re: virt-manager and messages in /var/log/messages
On Thursday 19 November 2009 18:22:02 Chandru wrote: Apologies if this has been already discussed. While using virt-manager to create a vm-guest we see the following errors being logged in /var/log/messages. libvirtd: 22:40:57.675: error : Domain not found: no domain with matching name 'guest1' libvirtd: 22:42:22.039: error : invalid storage volume pointer in no storage vol with matching path libvirtd: 22:44:55.530: error : Domain not found: no domain with matching uuid While these errors are indeed harmless and we are able to create and use a vm-guest, why log them as error messages. Could we convert them into informational messages. Though they could mean errors in other scenarios, but could we tweak or change them in a way that they could be logged in as informational messages and not as error messages. A end user would not know what to do with them. Any comments on this mail sent earlier ? thanks, Chandru -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Improve the reliability of pty path parsing
The following are improve the reliability of libvirt's mapping of character devices to pty paths. When qemu starts up it will output one or more lines of the form: char device redirected to /dev/pts/5 Note that the character device this refers to is not indicated, so the only way to match this up is by knowing the order they're written in. This is not a well-defined interface, and is therefore voodoo-magic. The current code works against current versions of QEMU. However, when using the -chardev syntax of newer QEMU, the output order changes (putting chardev first). The first patch works by making all character devices use -chardev if it's available. As well as being a better syntax, this makes the output of the redirection lines again match the order they're specified on the command line. The second patch uses this ordering to parse the ptys for channel devices from the log output. The third patch (almost) obsoletes the log output parsing method. If QEMU's monitor supports 'info chardev', this gives structured information about character devices, including pty mappings. The log output parsing method is still required because QEMU may not support info chardev, and because the monitor itself can be on a pty. The danger of the third patch is that it will fix errors in the log output parsing code, which may then bitrot. Matt -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] Make QEMU driver use -chardev everywhere when it's available
Change -monitor, -serial and -parallel output to use -chardev if it is
available.
* src/qemu/qemu_conf.c: Update qemudBuildCommandLine to use -chardev where
available.
* tests/qemuxml2argvtest.c tests/qemuxml2argvdata/: Add -chardev equivalents for
all current serial and parallel tests.
---
src/qemu/qemu_conf.c | 93 ---
.../qemuxml2argv-channel-guestfwd.args |2 +-
.../qemuxml2argv-console-compat-chardev.args |1 +
.../qemuxml2argv-console-compat-chardev.xml| 28 ++
.../qemuxml2argv-parallel-tcp-chardev.args |1 +
.../qemuxml2argv-parallel-tcp-chardev.xml | 27 ++
.../qemuxml2argv-serial-dev-chardev.args |1 +
.../qemuxml2argv-serial-dev-chardev.xml| 30 ++
.../qemuxml2argv-serial-file-chardev.args |1 +
.../qemuxml2argv-serial-file-chardev.xml | 30 ++
.../qemuxml2argv-serial-many-chardev.args |1 +
.../qemuxml2argv-serial-many-chardev.xml | 32 +++
.../qemuxml2argv-serial-pty-chardev.args |1 +
.../qemuxml2argv-serial-pty-chardev.xml| 28 ++
.../qemuxml2argv-serial-tcp-chardev.args |1 +
.../qemuxml2argv-serial-tcp-chardev.xml| 32 +++
.../qemuxml2argv-serial-tcp-telnet-chardev.args|1 +
.../qemuxml2argv-serial-tcp-telnet-chardev.xml | 32 +++
.../qemuxml2argv-serial-udp-chardev.args |1 +
.../qemuxml2argv-serial-udp-chardev.xml| 32 +++
.../qemuxml2argv-serial-unix-chardev.args |1 +
.../qemuxml2argv-serial-unix-chardev.xml | 30 ++
.../qemuxml2argv-serial-vc-chardev.args|1 +
.../qemuxml2argv-serial-vc-chardev.xml | 28 ++
tests/qemuxml2argvtest.c | 12 +++
25 files changed, 431 insertions(+), 16 deletions(-)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-console-compat-chardev.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-console-compat-chardev.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-parallel-tcp-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-dev-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-dev-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-file-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-file-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-many-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-many-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-pty-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-pty-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-chardev.xml
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet-chardev.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-serial-tcp-telnet-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-udp-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-unix-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-unix-chardev.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-vc-chardev.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-serial-vc-chardev.xml
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index f26e94d..51d8515 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1858,12 +1858,27 @@ int qemudBuildCommandLine(virConnectPtr conn,
if (monitor_chr) {
virBuffer buf = VIR_BUFFER_INITIALIZER;
-qemudBuildCommandLineChrDevStr(monitor_chr, buf);
-if (virBufferError(buf))
-goto error;
+/* Use -chardev if it's available */
+if (qemuCmdFlags QEMUD_CMD_FLAG_CHARDEV) {
+qemudBuildCommandLineChrDevChardevStr(monitor_chr, monitor,
buf);
+if (virBufferError(buf))
+goto error;
+
+ADD_ARG_LIT(-chardev);
+ADD_ARG(virBufferContentAndReset(buf));
+
+ADD_ARG_LIT(-monitor);
+ADD_ARG_LIT(chardev:monitor);
+}
+
+else {
+qemudBuildCommandLineChrDevStr(monitor_chr, buf);
+if (virBufferError(buf))
+goto error;
-ADD_ARG_LIT(-monitor);
-ADD_ARG(virBufferContentAndReset(buf));
+ADD_ARG_LIT(-monitor);
+ADD_ARG(virBufferContentAndReset(buf));
+}
}
if (def-localtime)
@@ -2146,12 +2161,36 @@ int
[libvirt] [PATCH 2/3] Extract the assigned pty device for channels
* src/qemu/qemu_driver.c: Parse pty devices for channels
---
src/qemu/qemu_driver.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2c5086b..ebf44b0 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1271,6 +1271,16 @@ qemudFindCharDevicePTYs(virConnectPtr conn,
}
}
+/* then the channel devices */
+for (i = 0 ; i vm-def-nchannels ; i++) {
+virDomainChrDefPtr chr = vm-def-channels[i];
+if (chr-type == VIR_DOMAIN_CHR_TYPE_PTY) {
+if ((ret = qemudExtractTTYPath(conn, output, offset,
+ chr-data.file.path)) != 0)
+return ret;
+}
+}
+
return 0;
}
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] Get QEMU pty paths from the monitor
This change makes the QEMU driver get pty paths from the output of the monitor
'info chardev' command. This output is structured, and contains both the name of
the device and the path on the same line. This is considerably more reliable
than parsing the startup log output, which requires the parsing code to know
which order QEMU will print pty information in.
Note that we still need to parse the log output as the monitor itself may be on
a pty. This should be rare, however, and the new code will replace all pty paths
parsed by the log output method once the monitor is available.
* src/qemu/qemu_monitor.(c|h) src/qemu_monitor_text.(c|h): Implement
qemuMonitorGetPtyPaths().
* src/qemu/qemu_driver.c: Get pty path information using
qemuMonitorGetPtyPaths().
---
src/qemu/qemu_driver.c | 68 +++-
src/qemu/qemu_monitor.c |9 +
src/qemu/qemu_monitor.h |3 ++
src/qemu/qemu_monitor_text.c | 71 ++
src/qemu/qemu_monitor_text.h |4 ++
5 files changed, 153 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ebf44b0..90dd9cd 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1239,6 +1239,40 @@ qemudExtractTTYPath(virConnectPtr conn,
}
static int
+qemudFindCharDevicePTYsMonitor(virConnectPtr conn,
+ virDomainObjPtr vm,
+ virHashTablePtr paths)
+{
+int i;
+
+#define LOOKUP_PTYS(array, arraylen, idprefix) \
+for (i = 0 ; i (arraylen) ; i++) { \
+virDomainChrDefPtr chr = (array)[i]; \
+if (chr-type == VIR_DOMAIN_CHR_TYPE_PTY) { \
+char id[16]; \
+\
+if (snprintf(id, sizeof(id), idprefix %i, i) = sizeof(id)) \
+return -1; \
+\
+const char *path = (const char *) virHashLookup(paths, id); \
+if (path == NULL) { \
+qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, \
+ _(no assigned pty for device %s), id); \
+return -1; \
+} \
+\
+chr-data.file.path = strdup(path); \
+} \
+}
+
+LOOKUP_PTYS(vm-def-serials, vm-def-nserials, serial);
+LOOKUP_PTYS(vm-def-parallels, vm-def-nparallels, parallel);
+LOOKUP_PTYS(vm-def-channels, vm-def-nchannels, channel);
+
+return 0;
+}
+
+static int
qemudFindCharDevicePTYs(virConnectPtr conn,
virDomainObjPtr vm,
const char *output,
@@ -1284,6 +1318,11 @@ qemudFindCharDevicePTYs(virConnectPtr conn,
return 0;
}
+static void qemudFreePtyPath(void *payload, const char *name ATTRIBUTE_UNUSED)
+{
+free(payload);
+}
+
static int
qemudWaitForMonitor(virConnectPtr conn,
struct qemud_driver* driver,
@@ -1291,7 +1330,7 @@ qemudWaitForMonitor(virConnectPtr conn,
{
char buf[4096]; /* Plenty of space to get startup greeting */
int logfd;
-int ret;
+int ret = -1;
if ((logfd = qemudLogReadFD(conn, driver-logDir, vm-def-name, pos))
0)
@@ -1317,7 +1356,32 @@ qemudWaitForMonitor(virConnectPtr conn,
if (qemuConnectMonitor(vm) 0)
return -1;
-return 0;
+/* Try to get the pty path mappings again via the monitor. This is much
more
+ * reliable if it's available.
+ * Note that the monitor itself can be on a pty, so we still need to try
the
+ * log output method. */
+virHashTablePtr paths = virHashCreate(0);
+if (paths == NULL) {
+virReportOOMError(NULL);
+goto cleanup;
+}
+
+qemuDomainObjEnterMonitor(vm);
+qemuDomainObjPrivatePtr priv = vm-privateData;
+ret = qemuMonitorGetPtyPaths(priv-mon, paths);
+qemuDomainObjExitMonitor(vm);
+
+VIR_DEBUG(qemuMonitorGetPtyPaths returned %i, ret);
+if (ret == 0) {
+ret = qemudFindCharDevicePTYsMonitor(conn, vm, paths);
+}
+
+cleanup:
+if (paths) {
+virHashFree(paths, qemudFreePtyPath);
+}
+
+return ret;
}
static int
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index f0ef81b..92f005a 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -904,3 +904,12 @@ int qemuMonitorRemoveHostNetwork(qemuMonitorPtr mon,
return qemuMonitorTextRemoveHostNetwork(mon, vlan, netname);
}
+
+int qemuMonitorGetPtyPaths(qemuMonitorPtr mon,
+ virHashTablePtr paths)
+{
+DEBUG(mon=%p, fd=%d,
+ mon, mon-fd);
+
+return qemuMonitorTextGetPtyPaths(mon, paths);
+}
diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h
index 71688cb..dc14bbe 100644
--- a/src/qemu/qemu_monitor.h
+++ b/src/qemu/qemu_monitor.h
@@ -28,6 +28,7 @@
#include internal.h
#include domain_conf.h
+#include hash.h
typedef struct _qemuMonitor qemuMonitor;
typedef qemuMonitor *qemuMonitorPtr;
@@ -244,5 +245,7 @@ int
Re: [libvirt] [PATCH v2] Disk- and Controller Hotplug
On Mon, Nov 23, 2009 at 02:15:06PM +0100, Wolfgang Mauerer wrote: Hi, Daniel P. Berrange wrote: On Tue, Nov 17, 2009 at 12:53:31AM +0100, wolfgang.maue...@siemens.com wrote: Hi, this is the second revision of a patch series to improve disk hotadd support for libvirt. It focuses on the qemu backend, but is naturally designed to be compatible with other backends as well. The objective is two-fold: 1.) Split off controller from disk handling. This is done by introducing a new domain element controller that is used to describe disk controllers. Support for hotplugging such controllers is added. Support to reference controllers by name is also included. 2.) disks can now be associated with a specific controller; this is done by means of a controller subelemnt for disks. This patch addresses the questions that were raised during the review of the initial submission, massages the code by fixing some whitespace issues, gets static controller configurations to work, and adds documentation. Notice that in contrast to the first submission I did not include the patch that adds support for disk- and controller hot_remove_. Since the qemu codebase is still in bit of a flux wrt. the necessary patches required for this functionality, it will reappear some time later as a separate submission. What libvirt version / GIT changeset did you create these patches against ? The current libvirt QEMU driver code in GIT is quite different, so the patches here don't apply for me as is. sorry for the late reply, I could not access my eMail during the last couple of days. Patches are on top of 790f0b3057787bb64, I did not realise that this one was only in the middle of qemu refactoring, not at the end :-( Do you plan any more refactorings to the qemu base in the near future, and if yes, are these already available somewhere? I'd like to avoid another useless rebase... No, the monitor code for the QEMU driver is stable now. I'll only be adding extra functionality, not changing existing stuff, so it should be good to rebase against now. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] RE: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
Date: Fri, 20 Nov 2009 08:14:09 -0500, cole wrote: cc-ing libvirt-list On 11/19/2009 10:35 PM, Dustin Xiong wrote: Hi everyone! I am a newer to the virt-manager and maillist. I sent the mail just want to ask some questions about virt-manager running on Arch of Itanium 64. My itanium 64 cpu actualy support the VT. I compiled the kvm85 successful. Then I can use the binary /usr/local/bin/qemu-system-ia64 to create a vm and running. But in my /proc/cpuinfo , there doesn't have flags such as vmx or svm. So when I use the virt-manager to install a vm, the virt-manager will tell me my cpu doesn't support fully virtualization, then I can't install vm. In fact I can't get understand how the virt-manager find my cpu support the fully virtualization or not.In src, which file implements this. Just because qemu-kvm works doesn't mean virt is working on your box, since it can fall back to full emulation mode. If you are trying to use kvm, is the kvm module actually loaded? lsmod | grep kvm My kvm mod actually loaded. [r...@kvm bin]# lsmod | grep kvm kvm_intel 306104 4294967281 kvm 327544 1 kvm_intel [r...@kvm bin]# modinfo kvm filename: /lib/modules/2.6.28.9hzp/extra/kvm.ko license:GPL author: Qumranet version:kvm-85 srcversion: C399DD2D9B40BAAC05CD509 depends: vermagic: 2.6.28.9hzp SMP mod_unload modversions ia64gcc-4.1 If so, libvirt may need to be fixed. What's the output of 'virsh --connect qemu:///system capabilities' [r...@kvm bin]# virsh --connect qemu:///system capabilities capabilities host cpu archia64/arch /cpu topology cells num='1' cell id='0' cpus num='16' cpu id='0'/ cpu id='1'/ cpu id='2'/ cpu id='3'/ cpu id='4'/ cpu id='5'/ cpu id='6'/ cpu id='7'/ cpu id='8'/ cpu id='9'/ cpu id='10'/ cpu id='11'/ cpu id='12'/ cpu id='13'/ cpu id='14'/ cpu id='15'/ /cpus /cell /cells /topology /host My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager is 0.6.1. Ah, are you using the version of libvirt that comes with RHEL 5.4? That version has been patched to only look for the qemu-kvm binary in one spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that, but since you are already building upstream KVM, virt-manager, and virtinst, might not be a bad idea to pull upstream libvirt as well. yes, my libvirt rpm and other related rpms all came from the RHEL 5.4 iso. And they all build for itanium 64 # rpm -qa | grep libvirt libvirt-python-0.6.3-20.el5 libvirt-devel-0.6.3-20.el5 libvirt-0.6.3-20.el5 And i try to make a link, it still doesn't work. ln -s /usr/local/bin/qemu-system-ia64 /usr/libexec/qemu-system-ia64 Once i tried to compile the virt-manager-0.8.0, but when i make check, it returns: PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py touch .tstamp.addhardware.py Traceback (mos! t recent call last): File addhardware.py, line 32, in ? from virtinst import VirtualCharDevice, VirtualDevice, VirtualVideoDevice when i rpm -ivh virt-manager-0.6.1-8.el5.ia64.rpm, it could work. I don't know why this error occur. Can anyone be kind to tell me how? thanks a lot. You will also need to install the latest version of virtinst, found at: http://virt-manager.org/download.html I downloaded and compiled the latest version of virtinst: virtinst-0.500.0.tar.gz. then compile the virt-manager-0.8.0, error changed as below: [r...@kvm virt-manager-0.8.0]# make check Making check in src make[1]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src' Making check in virtManager make[2]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager' make check-local make[3]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager' PYTHONPATH=./..:../graphWidgets/.libs python about.py touch .tstamp.about.py PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py touch .tstamp.addhardware.py Traceback (most recent call last): File addhardware.py, line 35, in ? from virtManager.asyncjob import vmmAsyncJob File /home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py, line 30, in ? class vmmAsyncJob(gobject.GObject): File /home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py, line 40, in vmmAsyncJob def __init__(self, config, callback, args=None, NameError: name '_' is not defined Thanks for help.If you need
[libvirt] [PATCH] Add test for legacy console ... tty= syntax
* tests/qemuxml2argvtest.c: Test legacy syntax for QEMU argument generation * tests/qemuxml2argvdata/qemuxml2argv-console-legacy.(xml|args): Add test data --- .../qemuxml2argv-console-legacy.args |1 + .../qemuxml2argv-console-legacy.xml| 29 tests/qemuxml2argvtest.c |1 + 3 files changed, 31 insertions(+), 0 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-legacy.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-legacy.xml diff --git a/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.args b/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.args new file mode 100644 index 000..fd42462 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.args @@ -0,0 +1 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial pty -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.xml b/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.xml new file mode 100644 index 000..68d86ba --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-console-legacy.xml @@ -0,0 +1,29 @@ +domain type='qemu' + nameQEMUGuest1/name + uuidc7a5fdbd-edaf-9455-926a-d65c16db1809/uuid + memory219200/memory + currentMemory219200/currentMemory + vcpu1/vcpu + os +type arch='i686' machine='pc'hvm/type +boot dev='hd'/ + /os + clock offset='utc'/ + on_poweroffdestroy/on_poweroff + on_rebootrestart/on_reboot + on_crashdestroy/on_crash + devices +emulator/usr/bin/qemu/emulator +disk type='block' device='disk' + source dev='/dev/HostVG/QEMUGuest1'/ + target dev='hda' bus='ide'/ +/disk +serial type='pty' + target port='0'/ +/serial +console type='pty' tty='/dev/pts/8' + source path='/dev/pts/8'/ + target port='0'/ +/console + /devices +/domain diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index c948379..233b3ae 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -268,6 +268,7 @@ mymain(int argc, char **argv) DO_TEST(serial-many, 0); DO_TEST(parallel-tcp, 0); DO_TEST(console-compat, 0); +DO_TEST(console-legacy, 0); DO_TEST(channel-guestfwd, QEMUD_CMD_FLAG_CHARDEV); -- 1.6.5.2 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
On 11/23/2009 01:43 AM, Dustin Xiong wrote: Date: Fri, 20 Nov 2009 08:14:09 -0500, cole wrote: cc-ing libvirt-list My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager is 0.6.1. Ah, are you using the version of libvirt that comes with RHEL 5.4? That version has been patched to only look for the qemu-kvm binary in one spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that! , but since you are already building upstream KVM, vir! t-manage r, and virtinst, might not be a bad idea to pull upstream libvirt as well. yes, my libvirt rpm and other related rpms all came from the RHEL 5.4 iso. And they all build for itanium 64 # rpm -qa | grep libvirt libvirt-python-0.6.3-20.el5 libvirt-devel-0.6.3-20.el5 libvirt-0.6.3-20.el5 And i try to make a link, it still doesn't work. ln -s /usr/local/bin/qemu-system-ia64 /usr/libexec/qemu-system-ia64 Actually I think that destination needs to be /usr/libexec/qemu-kvm, not qemu-system-ia64. And looking at the rhel5 code, this can also be /usr/bin/qemu-kvm Once i tried to compile the virt-manager-0.8.0, but when i make check, it returns: PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py touch .tstamp.addhardware.py Traceback (mos! t recent call last): File addhardware.py, line 32, in ? from virtinst import VirtualCharDevice, VirtualDevice, VirtualVideoDevice g! t; when i rpm -ivh virt-manager-0.6.1-8.el5.ia64.rpm, it could work. I don't know why this error occur. Can anyone be kind to tell me how? thanks a lot. You will also need to install the latest version of virtinst, found at: http://virt-manager.org/download.html I downloaded and compiled the latest version of virtinst: virtinst-0.500.0.tar.gz. then compile the virt-manager-0.8.0, error changed as below: [r...@kvm virt-manager-0.8.0]# make check Making check in src make[1]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src' Making check in virtManager make[2]: Entering directory `/home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager' make ch! eck-local make[3]: Entering directory `/home/dust! in/virt- manager/virt-manager-0.8.0/src/virtManager' PYTHONPATH=./..:../graphWidgets/.libs python about.py touch .tstamp.about.py PYTHONPATH=./..:../graphWidgets/.libs python addhardware.py touch .tstamp.addhardware.py Traceback (most recent call last): File addhardware.py, line 35, in ? from virtManager.asyncjob import vmmAsyncJob File /home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py, line 30, in ? class vmmAsyncJob(gobject.GObject): File /home/dustin/virt-manager/virt-manager-0.8.0/src/virtManager/asyncjob.py, line 40, in vmmAsyncJob def __init__(self, config, callback, args=None, NameError: name '_' is not defined Thanks for help.If you need any further infos please dont't hesitate to tell me. Ah, didn't notice the make check! in the first mail. 'make check' doesn't work in the virt-manager code base, never taken the time to fix it. You should just be able to 'make make install', or 'make' and python src/virt-manager.py to run from the source dir. If running virt-manager then throws an error, report here and Ill try to help. After make install, when i run virt-manager, the error is: starting the virt-manager error: 'gtk.TreeView' object has no attribute 'set_level_indentation' Details: raceback (most recent call last): File /usr/local/share/virt-manager/virt-manager.py, line 377, in ? main() File /usr/local/share/virt-manager/virt-manager.py, line 364, in main options.no_conn_auto) File /usr/local/share/virt-manager/virt-manager.py, line 237, in show_engine engine.show_manager() File /usr/local/share/virt-man! ager/virtManager/engine.py, line 365, in show_manager nbs! p;self.get_manager().show() File /usr/local/share/virt-manager/virtManager/engine.py, line 342, in get_manager self.windowManager = vmmManager(self.get_config(), self) File /usr/local/share/virt-manager/virtManager/manager.py, line 167, in __init__ self.prepare_vmlist() File /usr/local/share/virt-manager/virtManager/manager.py, line 826, in prepare_vmlist vmlist.set_level_indentation(-15) AttributeError: 'gtk.TreeView' object has no attribute 'set_level_indentation' Hmm, looks like set_level_indentation isn't supported on RHEL5. Strange though since I've had other reports of people using latest virt-manager on RHEL5. I'll take a look Thanks, Cole -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
On Mon, Nov 23, 2009 at 11:09:28AM -0500, Cole Robinson wrote: On 11/23/2009 01:43 AM, Dustin Xiong wrote: Date: Fri, 20 Nov 2009 08:14:09 -0500, cole wrote: cc-ing libvirt-list My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager is 0.6.1. Ah, are you using the version of libvirt that comes with RHEL 5.4? That version has been patched to only look for the qemu-kvm binary in one spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that! , but since you are already building upstream KVM, vir! t-manage r, and virtinst, might not be a bad idea to pull upstream libvirt as well. yes, my libvirt rpm and other related rpms all came from the RHEL 5.4 iso. And they all build for itanium 64 # rpm -qa | grep libvirt libvirt-python-0.6.3-20.el5 libvirt-devel-0.6.3-20.el5 libvirt-0.6.3-20.el5 And i try to make a link, it still doesn't work. ln -s /usr/local/bin/qemu-system-ia64 /usr/libexec/qemu-system-ia64 Actually I think that destination needs to be /usr/libexec/qemu-kvm, not qemu-system-ia64. And looking at the rhel5 code, this can also be /usr/bin/qemu-kvm That's not going to help. 'ia64' is not listed as a valid architecture in qemu_conf.c, so it'll never be pulled into the capabilities, and thus libvirt will never even look for a KVM binary Someone needs to update qemu_conf.c to handle ia64 correctly. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] crash in libvirtd when assigning PCI device (storage controller)
Compiled libvirt and friends from todays sources on ubuntu 9.10. Was playing around with vt-d and while my MB works fine with ESXi 4, I got some permission issues when I tried the KVM and virt-manager included from ubuntu so I just gambled and compiled everything from latest sources. Things seems to work fine in a normal use case, but if I a PCI device such as a storage controller, libvirtd will get a sigsev. I got the onboard Intel Sata, a PCI Sil Sata card as well as an Areca Raid controller in this machine. I have not tried the Intel Sata device as I am booting from that, but both the other devices causes sigsev. I am sure assigned an intel network card a bit earlier and it actually worked (well, the VM started to boot at least and entered win7 installation without libvirtd crashing), but when I tested that again now, seems like the ethernet card causes the same problem. It is 6AM so will not do a serious attempt at debugging this, just wanted to check if anyone had an idea before I spent more time potentially debugging stuff that is know to not work. From dmesg: [ 986.341633] device vnet0 entered promiscuous mode [ 986.342897] virbr0: topology change detected, propagating [ 986.342902] virbr0: port 1(vnet0) entering forwarding state [ 986.380733] pci-stub :09:01.0: enabling device ( - 0003) [ 986.380786] pci-stub :09:01.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [ 986.422128] pci-stub :09:01.0: restoring config space at offset 0x9 (was 0x0, writing 0xe3c04000) [ 986.422141] pci-stub :09:01.0: restoring config space at offset 0x8 (was 0x1, writing 0x1041) [ 986.422152] pci-stub :09:01.0: restoring config space at offset 0x7 (was 0x1, writing 0x1061) [ 986.422163] pci-stub :09:01.0: restoring config space at offset 0x6 (was 0x1, writing 0x1051) [ 986.422174] pci-stub :09:01.0: restoring config space at offset 0x5 (was 0x1, writing 0x1065) [ 986.422185] pci-stub :09:01.0: restoring config space at offset 0x4 (was 0x1, writing 0x1059) [ 986.422199] pci-stub :09:01.0: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b3) [ 987.172975] assign device: host bdf = 9:1:0 [ 987.173054] deassign device: host bdf = 9:1:0 [ 987.206121] pci-stub :09:01.0: restoring config space at offset 0x9 (was 0x0, writing 0xe3c04000) [ 987.206134] pci-stub :09:01.0: restoring config space at offset 0x8 (was 0x1, writing 0x1041) [ 987.206146] pci-stub :09:01.0: restoring config space at offset 0x7 (was 0x1, writing 0x1061) [ 987.206157] pci-stub :09:01.0: restoring config space at offset 0x6 (was 0x1, writing 0x1051) [ 987.206167] pci-stub :09:01.0: restoring config space at offset 0x5 (was 0x1, writing 0x1065) [ 987.206178] pci-stub :09:01.0: restoring config space at offset 0x4 (was 0x1, writing 0x1059) [ 987.206192] pci-stub :09:01.0: restoring config space at offset 0x1 (was 0x2b0, writing 0x2b3) [ 987.206225] pci-stub :09:01.0: PCI INT A disabled [ 987.286791] libvirtd[3193]: segfault at 10 ip 7f921b4546b4 sp 7f9216e165e0 error 4 in libpthread-2.10.1.so[7f921b44a000+17000] From GDB 06:45:32.434: error : qemuMonitorCommandWithHandler:290 : cannot send monitor command 'info cpus': Connection reset by peer 06:45:32.434: error : qemuMonitorTextGetCPUInfo:436 : internal error cannot run monitor command to fetch CPU thread info Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f485bfff910 (LWP 18120)] 0x7f48657fb6b4 in pthread_mutex_unlock () from /lib/libpthread.so.0 (gdb) bt #0 0x7f48657fb6b4 in pthread_mutex_unlock () from /lib/libpthread.so.0 #1 0x00431101 in qemuDomainObjExitMonitorWithDriver (driver=0x11f0110, obj=0x12114f0) at qemu/qemu_driver.c:318 #2 0x0043f436 in qemudStartVMDaemon (conn=value optimized out, driver=0x11f0110, vm=0x12114f0, migrateFrom=value optimized out, stdin_fd=value optimized out) at qemu/qemu_driver.c:2320 #3 0x004407c4 in qemudDomainStart (dom=0x11f0330) at qemu/qemu_driver.c:4370 #4 0x7f4865a621e7 in virDomainCreate (domain=0x11f0330) at libvirt.c:4509 #5 0x00420d68 in remoteDispatchDomainCreate (server=value optimized out, client=value optimized out, conn=0x1219da0, hdr=value optimized out, rerr=0x7f485bffedf0, args=value optimized out, ret=0x7f485bffeed0) at remote.c:853 #6 0x004228e1 in remoteDispatchClientCall (server=value optimized out, client=0x7f485c000d30, msg=0x7f485c080f00) at dispatch.c:506 #7 0x00422c93 in remoteDispatchClientRequest (server=0x11e2790, client=0x7f485c000d30, msg=0x7f485c080f00) at dispatch.c:388 #8 0x0041625c in qemudWorker (data=value optimized out) at libvirtd.c:1518 #9 0x7f48657f7a04 in start_thread () from /lib/libpthread.so.0 #10 0x7f48655617bd in clone () from /lib/libc.so.6 #11 0x in ?? () (gdb) select 2 (gdb) info locals
[libvirt] RE: [virt-tools-list] Questions about virt-manager running on Arch of Itanium 64
Date: Mon, 23 Nov 2009 16:16:05 + From: berra...@redhat.com To: crobi...@redhat.com CC: x_k_...@hotmail.com; libvirt-l...@redhat.com; virt-tools-l...@redhat.com Subject: Re: [virt-tools-list] Questions about virt-manager running on Arch ofItanium 64 On Mon, Nov 23, 2009 at 11:09:28AM -0500, Cole Robinson wrote: On 11/23/2009 01:43 AM, Dustin Xiong wrote: Date: Fri, 20 Nov 2009 08:14:09 -0500, cole wrote: cc-ing libvirt-list My cpu is itanium 64, the OS is RHEL.The libvirt is 0.6.3, virt-manager is 0.6.1. Ah, are you using the version of libvirt that comes with RHEL 5.4? That version has been patched to only look for the qemu-kvm binary in one spot: /usr/libexec/qemu-kvm IIRC. You could try to work with that! , but since you are already building upstream KVM, vir! t-manage r, and virtinst, might not be a bad idea to pull upstream libvirt as well. yes, my libvirt rpm and other related rpms all came from the RHEL 5.4 iso. And they all build for itanium 64 # rpm -qa | grep libvirt libvirt-python-0.6.3-20.el5 libvirt-devel-0.6.3-20.el5 libvirt-0.6.3-20.el5 And i try to make a link, it still doesn't work. ln -s /usr/local/bin/qemu-system-ia64 /usr/libexec/qemu-system-ia64 Actually I think that destination needs to be /usr/libexec/qemu-kvm, not qemu-system-ia64. And looking at the rhel5 code, this can also be /usr/bin/qemu-kvm That's not going to help. 'ia64' is not listed as a valid architecture in qemu_conf.c, so it'll never be pulled into the capabilities, and thus libvirt will never even look for a KVM binary The libvirt and virt-manager rpm all come from the iso of Red Hat Enterprise Linux 5.4 Server (Itanium)Does the redhat have the plans to implement the architecture ia64 in libvirt ? Someone needs to update qemu_conf.c to handle ia64 correctly. If i want to update qemu_conf.c to handle ia64 , which files or datastruct needs to update ? Only the qemu_conf.c ? thanks a lot _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
