Re: [libvirt] libvirt(-java): How to make vm.getDomain().getJobInfo() thread safe?
On 09/14/2011 02:20 PM, Thomas Treutner wrote: complete JVM crashes - http://pastebin.com/jT6sXubu With this message on the CLI: java: tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio = __sched_fifo_min_prio new_prio = __sched_fifo_max_prio)' failed. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt(-java): How to make vm.getDomain().getJobInfo() thread safe?
On 09/16/2011 10:16 AM, Thomas Treutner wrote: On 09/14/2011 02:20 PM, Thomas Treutner wrote: complete JVM crashes - http://pastebin.com/jT6sXubu With this message on the CLI: java: tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio = __sched_fifo_min_prio new_prio = __sched_fifo_max_prio)' failed. Different kind of error: http://pastebin.com/ujFd4Lw9 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt(-java): How to make vm.getDomain().getJobInfo() thread safe?
On 09/16/2011 10:44 AM, Daniel P. Berrange wrote: On Wed, Sep 14, 2011 at 02:20:46PM +0200, Thomas Treutner wrote: Of course, in my monitoring thread I'm checking in every monitoring iteration if the domain object is not null, is still active, if the jobInfo is available yet etc. But, as I can not synchronize with vm.migrate(), there still a reasonable chance that migrate() just invalidates the current domain while I'm accessing it, no matter what I do. At the C level every API in libvirt is threadsafe. The only key point is that if you use objects (eg virDomainPtr) from multiple threads you ought to hold an extra reference on them (virDomainRef) per thread to ensure that one thread does not delete an object that is in use by the other thread. At the Java level, this reference handling ought to be working automatically so you wouldn't need todo anything special to safely do migration with 2 threads as you describe. So I don't really have any explanation for what you see. I think that gave me a drift to the right direction, thanks. I'm using an additional, temporary domain (java) object in the monitoring thread now. The testing isn't running for a long time yet, but it looks promising. It's been a while since I poked around in libvirt-java, but could it be that per domain java object, a reference is held? regards, thomas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime
On 07/13/2010 07:12 PM, Daniel P. Berrange wrote: This tells me that calling migrateSetMaxDowntime is only allowed during migrations. As I'm migrating VMs automatically and without any user intervention I'd need to create some glue code that runs in an extra thread, waiting some time hoping that the migration was kicked off in the main thread yet and then calling migrateSetMaxDowntime. I'd like to avoid such quirks in the long run, if possible. Multiple threads is our recommended approach to the problem, since it is a general solution. eg you can call virDomainSuspend to pause the guest during migration thus let it complete non-live. And virDomainGetJobInfo to check progress. And virDomainAbortJob to cancel. Sorry to reanimate this zombie, but I think this approach isn't really doable in a clean way, but maybe I'm missing something. I've started a new thread with Message-ID: 4e709c1e.1030...@scripty.at here. Maybe you could give your highly appreciated 0.02 $/€ ... I've also sent a fix to the under-underlying issue, which was much more easy for me both than I thought and than getting multiple threads done right here (I think one can't, but see above etc.). Anyways, chances of acceptance are not too high, eventually. One can't argue with politics. http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg01754.html regards, thomas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt(-java): How to make vm.getDomain().getJobInfo() thread safe?
Hi, this is kind of a follow-up to an older question/discussion: https://www.redhat.com/archives/libvir-list/2010-July/msg00267.html As a result of that, I use a second thread for monitoring the live migration, taking actions (setting maxdowntime to a value that fits the situation) if necessary. Although I call getJobInfo() with a quite low frequency (once a second), problems are occuring frequently, like every 10th or 15th live migration. Problems range from exceptions that the domain is not running anymore to complete JVM crashes - http://pastebin.com/jT6sXubu Recovery from exceptions doesn't seem to work perfectly, as they seem to trigger that connections to a host can't be shut down properly because there are still open references. Of course, in my monitoring thread I'm checking in every monitoring iteration if the domain object is not null, is still active, if the jobInfo is available yet etc. But, as I can not synchronize with vm.migrate(), there still a reasonable chance that migrate() just invalidates the current domain while I'm accessing it, no matter what I do. Do I miss something or is that correct? Any ideas how to reliably solve it? Is there some experience from virt-manager, where (in my quite old version) I assume at least the domain is read for cpu etc. stats while live migrating... regards, thomas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.9.0 crashes on first start since boot
On 04/17/2011 11:31 AM, Laine Stump wrote: On 04/15/2011 09:03 AM, Thomas Treutner wrote: I removed dnsmasq startup from the runlevel, now it works fine. I have seen dnsmasq errors for a long time, but I didn't really care too much about, as I don't need dnsmasq and the warnings didn't stop libvrit from working. I think I'll just deinstall dnsmasq. Are you sure you want to uninstall dnsmasq, and not just disable it in the system config? If you uninstall dnsmasq, libvirt will fail to start the virtual networks - it uses dnsmasq to provide DNS for those networks even if you don't specify a dhcp range or hosts. Thanks for info, but I've not experienced such problems in my setup. I have a bridged network for the guests, static IPs and my DNS server in the guests /etc/resolv.conf - and everything works fine that way. I assume I don't need dnsmasq in such a setup? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.9.0 crashes on first start since boot
Am 14.04.2011 17:34, schrieb Laine Stump: On 04/14/2011 06:47 AM, Thomas Treutner wrote: Hi, I've upgraded to 0.9.0 today on my Debian Squeeze boxes. Everything went fine, expect on one node (and only on that one, although the setup is identical), the first start of libvirtd since boot (and again, only that start) crashes with SEGV. Here are traces from gdb: http://pastebin.com/DiZrw0S5 http://pastebin.com/eacJRv07 If I delete the PID-file and start libvirtd again, it works fine. It doesn't seem to matter when the first start since boot happens, I've deactivated startup of libvirtd at boot time. Any ideas or further infos needed? Aside from Michal's fix to the error *recovery*, the more interesting question is why this is now failing. The bits of system log we can see in the pastebin shows that dnsmasq failed with an exit code of 2. From the manpage, this means: 2 - A problem with network access occurred (address in use, attempt to use privileged ports without permission). Do you have a system instance of dnsmasq already running? (perhaps it's already listening on all interfaces) Can you send the output of dnsmasq -v; ps -AlF | grep dnsmasq? Indeed: root@node05:~# dnsmasq -v; ps -AlF | grep dnsmasq Dnsmasq version 2.55 Copyright (c) 2000-2010 Simon Kelley Compile time options IPv6 GNU-getopt DBus I18N DHCP TFTP This software comes with ABSOLUTELY NO WARRANTY. Dnsmasq is free software, and you are welcome to redistribute it under the terms of the GNU General Public License, version 2 or 3. 5 S dnsmasq 2647 1 0 80 0 - 5981 -856 3 14:54 ? 00:00:00 /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new 0 S root 3544 3473 0 80 0 - 2180 -852 3 14:56 pts/0 00:00:00 grep dnsmasq I removed dnsmasq startup from the runlevel, now it works fine. I have seen dnsmasq errors for a long time, but I didn't really care too much about, as I don't need dnsmasq and the warnings didn't stop libvrit from working. I think I'll just deinstall dnsmasq. Also, does the directory /usr/local/var/lib/libvirt/dnsmasq exist? Jep: # ls /usr/local/var/lib/libvirt/dnsmasq default.leases thanks, -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.9.0 crashes on first start since boot
Am 14.04.2011 17:34, schrieb Laine Stump: Do you have a system instance of dnsmasq already running? PS: It was the only node where dnsmasq was installed, for whatever reason. Seems to narrow down the problem pretty good. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt 0.9.0 crashes on first start since boot
Hi, I've upgraded to 0.9.0 today on my Debian Squeeze boxes. Everything went fine, expect on one node (and only on that one, although the setup is identical), the first start of libvirtd since boot (and again, only that start) crashes with SEGV. Here are traces from gdb: http://pastebin.com/DiZrw0S5 http://pastebin.com/eacJRv07 If I delete the PID-file and start libvirtd again, it works fine. It doesn't seem to matter when the first start since boot happens, I've deactivated startup of libvirtd at boot time. Any ideas or further infos needed? thanks regards, thomas -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] virDomainMigrate, suitable default for omitted bandwidth parameter
Hi, does somebody know what the following paragraph exactly means resp. what it should mean? The maximum bandwidth (in Mbps) that will be used to do migration can be specified with the bandwidth parameter. *If set to 0, libvirt will choose a suitable default*. http://libvirt.org/html/libvirt-libvirt.html#virDomainMigrate What is the suitable default? I looked through the code for qemu and the only call to qemuMonitorSetMigrationSpeed() I can find is in ./src/qemu/qemu_driver.c:8406, using libvirt 0.8.7. When I remember correctly the second condition in a conjunction will not be evaluated if the first one evaluates to false? So if resource == 0, no limit will be set? I ask because I discovered that qemu is live migrating with a hard coded throttle of 32MiB/s for historic reasons, which is an activated handbrake if you have GBit Ethernet and additionally annoying when thinking about qemu's broken way of live migration (no maximum amount of iterations, no forced action, no error message, no abortion - no *nothing*.). Effectively *using* GBit Ethernet often solves this problem as the bandwidth to transfer dirty pages is quadrupled. Also see qemu mailing list, Message-ID: 4d52d95d.3030...@scripty.at There was a short discussion on IRC where concerns of breaking libvirt when deactivating the default limit were stated. If there really are applications that depend on handbraked live migration, I think these applications just should pass the limit they need to virDomainMigrate(). What do you think? regards, -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime
Hi, I'm facing some troubles with virDomainMigrate virDomainMigrateSetMaxDowntime. The core problem is that KVM's default value for the maximum allowed downtime is 30ms (max_downtime in migration.c, it's nanoseconds there; 0.12.3) which is too low for my VMs when they're busy (~50% CPU util and above). Migrations then take literally forever, I had to abort them after 15 minutes or so. I'm using GBit Ethernet, so plenty bandwidth should be available. Increasing the allowed downtime to 50ms seems to help, but I have not tested situations where the VM is completely utilized. Anyways, the default value is too low for me, so I tried virDomainMigrateSetMaxDowntime resp. the Java wrapper function. Here I'm facing a problem I can overcome only with a quite crude hack: org.libvirt.Domain.migrate(..) blocks until the migration is done, which is of course reasonable. So I tried calling migrateSetMaxDowntime(..) before migrating, causing an error: Requested operation is not valid: domain is not being migrated This tells me that calling migrateSetMaxDowntime is only allowed during migrations. As I'm migrating VMs automatically and without any user intervention I'd need to create some glue code that runs in an extra thread, waiting some time hoping that the migration was kicked off in the main thread yet and then calling migrateSetMaxDowntime. I'd like to avoid such quirks in the long run, if possible. So my question: Would it be possible to extend the migrate() method resp. virDomainMigrate() function with an optional maxDowntime parameter that is passed down as QEMU_JOB_SIGNAL_MIGRATE_DOWNTIME so that qemuDomainWaitForMigrationComplete would set the value? Or are there easier ways? Thanks and regards, -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime
[forgot list] On 07/13/2010 08:21 PM, Cole Robinson wrote: On 07/13/2010 01:12 PM, Daniel P. Berrange wrote: On Tue, Jul 13, 2010 at 06:56:53PM +0200, Thomas Treutner wrote: So my question: Would it be possible to extend the migrate() method resp. virDomainMigrate() function with an optional maxDowntime parameter that is passed down as QEMU_JOB_SIGNAL_MIGRATE_DOWNTIME so that qemuDomainWaitForMigrationComplete would set the value? Or are there easier ways? That approach really desirable IMHO, because it is already possible todo this using threads, which is already neccessary for the other APIs you can invoke during migration. If you care about the max downtime parameter, then you almost certainly need to care about calling virDomainGetJobInfo() in order to determine whether the guest is actually progressing during migration or not. Also sounds like it would be handy to allow globally configuring the default migration downtime in /etc/libvirt/qemu.conf Yep, that would be at least something. I'd even doubt that the qemu default value makes sense at all, in more than one way: 1) When I set 100ms, the last jobinfo I see says approx. 80MByte remaining. Over Gbit Ethernet, it would take about 0.5s to transfer that, in the ideal case. A flooding ping says about 800ms max delay. Maybe there's a bit/Byte-bug lurking around somewhere in qemu? (100ms vs. 800ms) 2) Even if there's no bug, the 30ms look far too optimistic to me. As I said, unless the VM is only moderately loaded (50%), migrations never finish and would run forever, I assume. I suggest that the default value should be higher and/or some action should be taken if the migration can not be done within some time or iteration limit (IIRC Xen takes the iteration approach). One can argue whether the action should be abortion or just-do-it, but I think there should be definitively *some* action to have a sane default without tracking a migration process in each and every software built on libvirt/qemu. (Yes, it's primarily a qemu issue, but there are lots of other optional, driver-specific things in libvirt too). I'd find it even more interesting to have the downtime as a part of the domain config, with choices/values for timeouts and the respective action, but that's a lot of wishes and would need hypervisor support. regards, -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix disk stats retrieval with QEMU = 0.12
On Wednesday 10 February 2010 18:49:15 Daniel P. Berrange wrote: With QEMU = 0.12 the host and guest side of disks no longer have the same naming convention. Specifically the host side will now get a 'drive-' prefix added to its name. The 'info blockstats' monitor command returns the host side name, so it is neccessary to strip this off when looking up stats since libvirt stores the guest side name ! * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Move 'drive-' prefix string to a defined constant * src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_text.c: Strip off 'drive-' prefix (if found) when looking up disk stats --- src/qemu/qemu_conf.c |4 ++-- src/qemu/qemu_conf.h |2 ++ src/qemu/qemu_monitor_json.c |7 +++ src/qemu/qemu_monitor_text.c |7 +++ 4 files changed, 18 insertions(+), 2 deletions(-) [...] Thanks a lot, fixes the problem also for qemu-kvm-0.12.2 -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] domblkstat not working for qemu-kvm 0.11
Hi, with all qemu-kvm 0.11, virsh domblkstat is not working: virsh -c qemu://node03/system domblkstat wp01 vdb : invalid argument in no stats found for device virtio-disk1 (vda, vdb etc. works with 0.11) virtio-disk1 seems to be a red herring: virsh -c qemu://node03/system domblkstat wp01 virtio-disk1 : invalid argument in invalid path: virtio-disk1 Most probably there have been made some changes with 0.12 libvirt does not resemble yet. If you need more debugging output, just tell. kr,t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Live migration woes
On Friday 05 February 2010 21:21:32 Thomas Sjolshagen wrote: Quoting Thomas Treutner tho...@scripty.at: Hi, is anyone using libvirt-git and qemu-kvm post-0.11 and can live migrate VMs successfully for- and backwards? qemu-kvm-0.11 seems to be the latest release were live migration works, and I'm trying to figure out if its a kvm or libvirt problem, since there were other things (balloon parameter f.e.) that were changed with qemu-kvm-0.12 and caused troubles when using libvirt. Yes. I'm using the virt-preview repo (rawhide) and I just noticed, today, after re-upgrading to 0.12.2-5 (since -4 has a rather nasty IO problem for virtio devices against raw image files) that my live-migrations fail with the following error message on the destination system (i.e. the system the I'm trying to migrate to): I now switched back to 0.11 and disabled Enhanced C1 of my PhenomII and AthlonII (I think the MSI BIOS calls it just C1), which makes things better, but migrations are not completely stable yet. From http://tinyurl.com/yaacdtu: In addition, we have C-states, in the case of the Phenom, it is the C0 and C1 state with the C1 state being enabled if there are no outstanding IPCs and resulting in a clock divider of 1/128. If there is no cache activity either or outstanding memory requests, then the CPU can go into the enhanced C1 state, that is the C1e state where the shared cache and memory controllers are clock gated back to 1/16 of the original frequency. So, currently, it seems to be a KVM-bug related to power saving features. -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Live migration woes
Hi, is anyone using libvirt-git and qemu-kvm post-0.11 and can live migrate VMs successfully for- and backwards? qemu-kvm-0.11 seems to be the latest release were live migration works, and I'm trying to figure out if its a kvm or libvirt problem, since there were other things (balloon parameter f.e.) that were changed with qemu-kvm-0.12 and caused troubles when using libvirt. thx,t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Live migration woes
On Friday 05 February 2010 21:21:32 Thomas Sjolshagen wrote: Quoting Thomas Treutner tho...@scripty.at: Hi, is anyone using libvirt-git and qemu-kvm post-0.11 and can live migrate VMs successfully for- and backwards? qemu-kvm-0.11 seems to be the latest release were live migration works, and I'm trying to figure out if its a kvm or libvirt problem, since there were other things (balloon parameter f.e.) that were changed with qemu-kvm-0.12 and caused troubles when using libvirt. Yes. I'm using the virt-preview repo (rawhide) and I just noticed, today, after re-upgrading to 0.12.2-5 (since -4 has a rather nasty IO problem for virtio devices against raw image files) that my live-migrations fail with the following error message on the destination system (i.e. the system the I'm trying to migrate to): /var/log/libvirt/qemu/guest.log: Unknown savevm section -2038417646 load of migration failed I don't see that in the logs. My migrations succeed, but at the dst, the VM immediately crashes, with no chance of getting some useful debug output so far. Also, in the same log file, I'm seeing: Warning: vlan 0 with no nics Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 But that may not be related to the migration failing. Yeah, that's familiar to me: 22:09:40.409: debug : qemuSecurityDACSetProcessLabel:411 : Dropping privileges of VM to 0:0 char device redirected to /dev/pts/3 Warning: vlan 0 with no nics Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Live migration woes
On Friday 05 February 2010 22:39:04 Thomas Treutner wrote: Yeah, that's familiar to me: 22:09:40.409: debug : qemuSecurityDACSetProcessLabel:411 : Dropping privileges of VM to 0:0 char device redirected to /dev/pts/3 Warning: vlan 0 with no nics Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 I just found out that migrating from A to B seems to work, but then, back from B to A won't. After A-B, the VM has a huge timetrift, although A+B have ntp running and clocksource is kvm-clock: http://tt.scripty.at/tmp/kvm_clocksource_ts_unstable.png A is a PhenomII X4, B is a AthlonII X2, /proc/cpuinfo flags are identical. -t -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fix wrong nodeinfo-mhz when cpufreq is enabled
Hi, I've written a little patch to fix wrong nodeinfo-mhz when the Linux kernel module cpufreq and a typical governor like ondemand are loaded. nodeinfo-mhz is then too low as libvirt just reads /proc/cpuinfo, entry cpu MHz. This patch reads /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq if existing and corrects nodeinfo-mhz if the value found is higher. Using cpu0 is a crude hack but as discussed on IRC, considering different governors/maximum frequencies per cpu/core would require changing the nodeinfo struct, which would break the API. Some more info: https://bugzilla.redhat.com/show_bug.cgi?id=559762 Please have a careful look at my patch, my last C is quite some time ago. I tried to stick to linuxNodeInfoCPUPopulate, but f.e., checking for *p == '\0' after virStrToLong_ui doesn't work and I'm wondering why scaling_max_freq may not be terminated with by NUL? I also hope the file handling is correct, but please have a look. There is still some todo: Some logging would be helpful, maybe one of you could point out which function best to use? This is my first patch, so hopefully it follows in the next mail ;-) kr, tom -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] * src/nodeinfo.c: Read nodeinfo-mhz from cpufreq device file, if detected.
---
src/nodeinfo.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index 7d26b2b..15877ed 100644
--- a/src/nodeinfo.c
+++ b/src/nodeinfo.c
@@ -55,11 +55,14 @@
#ifdef __linux__
#define CPUINFO_PATH /proc/cpuinfo
+#define SCALINGMAXFREQ_PATH
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/* NB, these are not static as we need to call them from testsuite */
int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE *cpuinfo,
virNodeInfoPtr nodeinfo);
+int linuxNodeInfoConsiderCPUScaling(FILE *scalingmaxfreq, virNodeInfoPtr
nodeinfo);
+
int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE *cpuinfo, virNodeInfoPtr
nodeinfo) {
char line[1024];
@@ -132,6 +135,27 @@ int linuxNodeInfoCPUPopulate(virConnectPtr conn, FILE
*cpuinfo, virNodeInfoPtr n
return 0;
}
+int linuxNodeInfoConsiderCPUScaling(FILE *scalingmaxfreq, virNodeInfoPtr
nodeinfo) {
+char line[1024];
+
+while (fgets(line, sizeof(line), scalingmaxfreq) != NULL) {
+char *buf = line;
+char *p;
+unsigned int khz;
+
+if (virStrToLong_ui(buf, p, 10, khz) == 0)
+{
+if(khz/1000 nodeinfo-mhz)
+{
+nodeinfo-mhz = khz/1000;
+return 0;
+}
+}
+}
+return 1;
+}
+
+
#endif
int nodeGetInfo(virConnectPtr conn,
@@ -164,6 +188,18 @@ int nodeGetInfo(virConnectPtr conn,
if (ret 0)
return -1;
+FILE *scalingmaxfreq = fopen(SCALINGMAXFREQ_PATH, r);
+if (scalingmaxfreq != NULL) {
+// TODO: some logging information that cpufreq was detected?
+ret = linuxNodeInfoConsiderCPUScaling(scalingmaxfreq, nodeinfo);
+if(ret == 0) {
+// TODO: logging: nodeinfo-mhz was updated
+} else if(ret == 1) {
+// TODO: logging: cpufreq was detected, but information available
didn't make sense
+}
+fclose(scalingmaxfreq);
+}
+
/* Convert to KB. */
nodeinfo-memory = physmem_total () / 1024;
--
1.5.4.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libvirt 0.7.5 vs qemu 0.12.1 imcompatability?
On Wednesday 06 January 2010 17:11:17 Tom Hughes wrote: On 06/01/10 15:53, Daniel P. Berrange wrote: On Wed, Jan 06, 2010 at 03:38:29PM +, Tom Hughes wrote: The update from qemu 0.11.0 to qemu 0.12.1 in the virt-preview repository seems to have broken things. Starting a VM now just gives me a blank screen and a log which says: Option 'ipv4': Use 'on' or 'off' Failed to parse yes for dummy.ipv4 I assume libvirt is sending a it a command on the monitor interface that it no longer understands... That warning message should be harmless - all my VMs show that and they work ok. It is not actually something libirt sets - its a internal QEMU default setting which is wrong Hmm... Well something is wrong because I just get a black screen. I don't even get the BIOS messages since I updated this morning. If you start your VM with -kernel $image, there's a bug in qemu-0.12.1(.1?), which is fixed in 0.12.1.2. Downgrading back to the fedora-updates version of qemu makes it work again. BTW the trigger for that warning seems to be that I have listen='0.0.0.0' set on the vnc adaptor to allow connections from remote machines, which causes libvirt to build a qemu command line with -vnc 0.0.0.0:0. Tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New libvirt API for domain memory statistics reporting (V3)
On Wednesday 23 December 2009 19:42:20 Adam Litke wrote: Attached to this email are two patches: memstats-kernel-2.6.32-rc5.patch: Applies to 2.6.32-rc5 which should be a capable-enough kernel for testing and development. memstats-qemu-0.12.1.patch: Applies to qemu-0.12.1 which can be found here: http://mirrors.igsobe.com/nongnu/qemu/qemu-0.12.1.tar.gz Unfortunately, it is not trivial for me to port this work to 0.11.0 so you will have to find a resolution to your BIOS woes first and then use this version. Who knows, it might already be fixed in 0.12.1. I tried with qemu-*kvm*-0.12.1.1, no memstats yet, but dynamically setting the amount of memory now doesn't work at all. I'll try to isolate the problem, I suspect it comes from qemu-kvm-0.12.1.1. I can't use qemu-0.12.1: $ ./configure --enable-kvm --disable-xen #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS NOTE: To enable KVM support, update your kernel to 2.6.29+ or install recent kvm-kmod from http://sourceforge.net/projects/kvm. ERROR ERROR: User requested feature kvm ERROR: configure was not able to find it ERROR $ uname -r 2.6.32.2 $ modinfo kvm_amd ... vermagic: 2.6.32.2 SMP mod_unload modversions kr,tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New libvirt API for domain memory statistics reporting (V3)
Hi Adam, thanks for your efforts, for me such an API would be very helpful. I tried to use it by applying this patch http://git.kernel.org/?p=linux/kernel/git/rusty/linux-2.6-for-linus.git;a=patch;h=7e280facc1c0ab91e20dbc93d8e8dd88ca6ebaad against vanilla 2.6.32.2 and using latest libvirt from git, but when I do $ virsh dommemstat mydomain I just get an empty line of output, no error message, nothing. Ballooning works fine, but as I said, no statistics output. I'm also using virtio for net and blk - did I miss something (additional entry in the dom-config?) or is there something going wrong? I'm using qemu-kvm-0.11.0 currently, -0.12 is not working for me. Could that be the cause? Thanks for any directions, kr,tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] New libvirt API for domain memory statistics reporting (V3)
Hi Adam, On Wednesday 23 December 2009 15:47:58 Adam Litke wrote: To use the memory statistics API with qemu, you will need support in 3 places: libvirt (you're good here), qemu, and linux. The qemu and linux parts have been accepted but are still staging. If you want to build your own qemu and linux-kernel, let me know and I can provide you some patches. yes, I'd highly appreciate that! I can use any Linux kernel that is stable enough for devtesting, with qemu-kvm, I wasn't lucky with all releases newer than 0.11.0, as my VMs are stuck at boot (SeaBIOS...gPXE, then nothing happens). Thxkr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Segmentation fault when shutting down VMs
On Friday 13 November 2009 12:46:24 Daniel P. Berrange wrote: On Fri, Nov 13, 2009 at 11:42:46AM +0100, Thomas Treutner wrote: Hi, I'm facing another problem with latest git. This happens regularly when shutting down VM(s): http://pastebin.com/m4ef1d93f It doesn't depend on which or how many VM is/are shut down, or if I have a VNC connection to a VM that is shutting down. Sometimes after a segv, I get this: http://pastebin.com/m5260bf21 It seems to me that libvirt tries to query a qemu monitor that is no longer alive? This second problem is fixed by http://www.redhat.com/archives/libvir-list/2009-November/msg00458.html I'm still trying to figure out what's going on with the first problem I found some time to pull latest git, build, and test a little bit today, and it seems to me that the problem has vanished away! -t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] migration: qemu vs. qemu+tcp at virsh vs. libvirt-java
On Monday 16 November 2009 14:42:16 Cole Robinson wrote: For virDomainMigrate, the least you need is a VM pointer and an open connection ptr, which will be the destination connection. URI should only be specified if you want to migrate over a specific interface on the remote host, and the uri should be of the form Both tcp://hostname[:port] and omitting the URI parameter seem to work. Regarding javadoc - of course one should read it, which I didn't, but I think it wouldn't have helped me, because in If uri is NULL, then libvirt will try to find the best method. Uri may specify the hostname or IP address of the destination host as seen from the source. Or uri may be a URI giving transport, hostname, user, port, etc. in the usual form. Refer to driver documentation for the particular URIs supported. the pointer to http://libvirt.org/drvqemu.html isn't helpful as tcp://host isn't there either. So I think it would be helpful to add your suggestions to either javadoc or the drivers doc? kr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] migration: qemu vs. qemu+tcp at virsh vs. libvirt-java
On Monday 16 November 2009 14:42:16 you wrote: On 11/16/2009 12:33 AM, Thomas Treutner wrote: Hi, I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp:// Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java. I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh? Has anyone clues where this twisted-mind behaviour could come from? What is the full argument list you are passing to the migrate function? You should only see that 'tcp' error if you are passing an explicit URI, which isn't required for standard migration. domain.migrate(dst, 1, null, dstIP, 0); where dst is a Connect object created with qemu://nodeX/system - I'm also passing a destination IP, could that be the problem? I used this code with Xen before. I have two ethXs, one for iSCSI, libvirt, .. and one for br0. dstIP is the same IP dst points to, but if it's possible, I'd like to let it be configurable that way. Ah, javadoc says I'm using an URI ;) I'll try your suggestions ASAP. Thanks! kr tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] How to keep VM definitions in sync across hosts?
On Saturday 14 November 2009 18:07:48 Matthias Bolte wrote: 2009/11/14 Thomas Treutner tho...@scripty.at: Hi, is there any best-practice how to keep VM definitions in sync across a couple of hosts? Is it reasonable to put /etc/libvirt/qemu/ on a NFS share? Or are there better ways? How does oVirt solve that? There was a similar question some weeks ago. The short answer is: No, it's not safe to share /etc/libvirt/qemu/. https://www.redhat.com/archives/libvir-list/2009-October/msg00031.html Ah, thx for the pointer! Why do you think the domain configs have to be available to all nodes? Because I'm coming from Xen and now finally had time to switch to KVM and there's no regretting anything, but some rethinking neccessary :) When using Xen, it's AFAIK necessary to have the domain configs available at all nodes which one wants to migrate a VM to. The default migration semantic of libvirt is to blame here. A migrated domain stays defined on the source node and is transient on the destination node. A transient domain has no persistent config on its node and is lost when destroyed. Thats very cool! Just to be on the secure side of life: I assume a transient VM can be target of setmem, etc.pp., be migrated again (and of course will be transient at the target again), ... , and the only shortcome is that its config is lost when it is destroyed? Chris Lalancette committed a patch a month ago that adds two new migration flags. This commit was applied after the release of 0.7.2, it will be part of release 0.7.3. https://www.redhat.com/archives/libvir-list/2009-October/msg00318.html VIR_MIGRATE_PERSIST_DEST makes a domain persistent on the destination node, libvirt writes a config to disk. VIR_MIGRATE_UNDEFINE_SOURCE removes the domain config on the source node. If you migrate a domain using this two flags then the domain takes its config with it. So there is no need to have the domain configs available on all nodes. Thanks again - very interesting. I'm really impressed by the features of libvirt more and more. I think the second reason (beneath live migration) for thinking about keeping domain configs in sync was the necessity to be able to *start* VMs at an arbitrary host (hardware failures, whatever), but for that, I can use svn etc. and do a virsh define before starting. kr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] migration: qemu vs. qemu+tcp at virsh vs. libvirt-java
Hi, I'm having a little problem when triggering (live) migration from libvirt-java (libvirt.so at client is approx. 0.7.1), I get an error that the qemu:// driver for migration URIs is not supported, only qemu+tcp:// Strange thing is, with virsh at the same client (same libvirt.so), qemu:// works. Interestingly, the error message seems to come from libvirt.so and not libvirt-java. I'd like to avoid maintaining two different URIs/drivers for normal connections and migration destinations, especially as it works flawlessly (and fast!) with virsh? Has anyone clues where this twisted-mind behaviour could come from? kr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] make install fails, missing HTML files
On Friday 13 November 2009 23:28:47 Matthias Bolte wrote: Well, I assume you still have the two rewite lines in your /etc/xml/catalog, that's why it's working without the patch. Yes, of course. Thanks for the patch you submitted today! -t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] How to keep VM definitions in sync across hosts?
Hi, is there any best-practice how to keep VM definitions in sync across a couple of hosts? Is it reasonable to put /etc/libvirt/qemu/ on a NFS share? Or are there better ways? How does oVirt solve that? I'm asking because I'm currently setting up a four node cluster with KVM and libvirt. Previously, with Xen, I used libvirt only for changing currently running VMs (setmem, migrate etc.), but with KVM, I'd like to use libvirt the way it is intented to ;-) So I assume that VM definitions are required to be available and in sync among all nodes for doing live migration. I don't want to rsync them or wrap the virsh URI edit inside a for-loop, as I assume there are better ways? I'd like to do virsh URI edit once and have the changes propagated automagically. kr,tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] make install fails, missing HTML files
On Thursday 12 November 2009 16:01:39 Matthias Bolte wrote: I came across this problem some time ago, too. I'm using Ubuntu, so it's basically Debian. I somewhat solved it by hacking my /etc/xml/catalog. I added this into the catalog element: rewriteSystem systemIdStartString=http://www.w3.org/TR/xhtml1/DTD/; rewritePrefix=file:///usr/share/xml/xhtml/schema/dtd/1.0// rewriteURI uriStartString=http://www.w3.org/TR/xhtml1/DTD/; rewritePrefix=file:///usr/share/xml/xhtml/schema/dtd/1.0// Matthias Thanks for the tip, but it still fails. http://pastebin.com/m3bf17c73 http://pastebin.com/m90f9ba6 catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog rewriteSystem systemIdStartString=http://www.w3.org/TR/xhtml1/DTD/; rewritePrefix=file:///usr/share/xml/xhtml/schema/dtd/1.0// rewriteURI uriStartString=http://www.w3.org/TR/xhtml1/DTD/; rewritePrefix=file:///usr/share/xml/xhtml/schema/dtd/1.0// delegatePublic publicIdStartString=ISO 8879:1986//ENTITIES catalog=file:///etc/xml/sgml-data.xml/ /catalog # ls -l /usr/share/xml/xhtml/schema/dtd/1.0/ total 104 -rw-r--r-- 1 root root 898 2004-08-11 06:17 catalog -rw-r--r-- 1 root root 1385 2004-08-11 06:17 catalog.xml lrwxrwxrwx 1 root root31 2009-11-12 12:50 xhtml1.dcl - ../../../../declaration/xml.dcl -rw-r--r-- 1 root root 32950 2002-08-01 20:23 xhtml1-frameset.dtd -rw-r--r-- 1 root root 25473 2002-08-01 20:23 xhtml1-strict.dtd -rw-r--r-- 1 root root 32112 2002-08-01 20:23 xhtml1-transitional.dtd Any suggestions? kr,tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Segmentation fault when shutting down VMs
Hi, I'm facing another problem with latest git. This happens regularly when shutting down VM(s): http://pastebin.com/m4ef1d93f It doesn't depend on which or how many VM is/are shut down, or if I have a VNC connection to a VM that is shutting down. Sometimes after a segv, I get this: http://pastebin.com/m5260bf21 It seems to me that libvirt tries to query a qemu monitor that is no longer alive? kr,tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Segmentation fault when shutting down VMs
On Friday 13 November 2009 12:46:24 Daniel P. Berrange wrote: I'm still trying to figure out what's going on with the first problem Uhm, it's getting stranger. When trying to do: # export LIBVIRT_DEBUG=1 # strace -o libvirt.log -s 1000 -ff libvirtd -l -v strace crashes with: *** glibc detected *** strace: malloc(): memory corruption (fast): 0x00af75b0 *** during startup, although /usr/local/var/run/libvirt/qemu/ is wiped out and no stale pids or kvms running. http://pastebin.com/m45c03cfb strace's logs until crash: http://tt.scripty.at/tmp/glibc_mem_corrupt.log.tar.bz2 Time for doing a memtest? -t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] make install fails, missing HTML files
On Friday 13 November 2009 16:41:02 Matthias Bolte wrote: Ah, I can reproduce your pastebin'ed output if I uninstall xsltproc. So I assume you're missing the xsltproc package. The Makefile output is not very helpful in this situation, it tries to validate files that have not been generated, because xsltproc is missing. Thx a lot, that works (even w/o your patches)! kr,t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] make install fails, missing HTML files
Hi, I'm not sure if this is a bug or if I'm missing some tools: When doing a fresh git clone ./autogen.sh, make install fails because it complains about some missing HTML doc files. # ./autogen.sh .. configure: Libraries configure: configure: libxml: -I/usr/include/libxml2 -lxml2 configure: libcurl: no configure: libssh2: no configure: gnutls: -lgnutls -lpthread configure: sasl: -lsasl2 configure:avahi: no configure: polkit: no configure: selinux: no configure: apparmor: no configure: numactl: no configure:capng: no configure: xen: -lxenstore configure: hal: no configure: devkit: no configure:netcf: no configure: xmlrpc: no ... # make . make[3]: Leaving directory `/root/tmp/libvirt/docs' (./apibuild.py) missing XHTML1 DTD missing XHTML1 DTD missing XHTML1 DTD missing XHTML1 DTD missing XHTML1 DTD missing XHTML1 DTD . (lots more) # ll docs/*html | wc -l 8 # ll docs/*html.in | wc -l 51 Could someone please cross-check? thx,kr tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] make install fails, missing HTML files
On Thursday 12 November 2009 13:47:32 Daniel Veillard wrote: On Thu, Nov 12, 2009 at 11:34:13AM +, Daniel P. Berrange wrote: You are missing the XHTML DTDs on your system. On Fedora/RHEL this is in the RPM called xhtml1-dtds-1.0-20020801.4.noarch Note that it should not be a hard requirement, you should just get the errors about the missing DTDs making validation impossible but the HTML files are generated. Installed w3c-dtd-xhtml (debian lenny), doesn't help, because: xmlcatalog /etc/xml/catalog http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; No entry for SYSTEM http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd No entry for URI http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd xmlcatalog /etc/xml/catalog -//W3C//DTD XHTML 1.0 Strict//EN file:///usr/share/xml/xhtml/schema/dtd/1.0/xhtml1-strict.dtd I'm not much into XML - is the Debian package faulty or shouldn't one rely on the way the docs/Makefile works? kr,t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
On Thursday 29 October 2009 01:30:34 Bryan Kearney wrote: Ok.. patch is attached. You can see a test build at: http://bkearney.fedorapeople.org/libvirt-0.3.1-test.jar Let me know if this works for you. If so, I will push a new build. Yes, works for me, thank you! A minor improvement: finalize() should have an @override annotation, just to be sure it actually overrides a method. In case it doesn't (due to f.e. wrong return type) a warning (or even error?) is thrown at compile time, avoiding hard to find bugs. A more important issue: In org.libvirt.Domain.free(), the VDP is not checked for being NULL, and return type is void, hardening debugging. I did a copy and paste from your new Connect.close() methods and s/VCP/VDP/, works fine for me. kr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
On Friday 09 October 2009 19:38:34 Bryan Kearney wrote: The Java bindings should now be pretty light weight. Are you seeing this in them? If so, spin up a bug and I will take a look. It took me quite some time to get to the bottom of this, as I'm not a professional full time dev. From what I see now, the gnutls problem just stems from the fact that libvirt connections somewhat tend to pile up. When does that happen? I looked into the libvirt-java and libvirt source, and to me (again, I'm just coding for fun), there are two obvious bugs in libvirt-java (I'm even ashamed I didn't see them for so long ;)), both in org.libvirt.Connect: 1) Connect.close() The return value of libvirt.virConnectClose(VCP) is never checked, so VCP is NULLed in *any* case. That means: If a connection couldn't be shut down because there are still references to it, it can *never* be shut down in the future, even when there are no more references, because the VCP is then NULL. 2) Connect.finalize() This is just a minor annoyance: The status of the VCP is again not checked. Means if the connection was closed properly, and some time later the garbage collector runs, an ugly and more importantly unneccesary error message is printed to the console. There should be a check if the VCP != null or something more appropriate. Regarding finalize(), I read in Effective Java that one should never rely on finalize() for tearing down things, as it is completely uncertain *when* the GC may run. This thing went through my brain in random directions, but right now, I think it's just the API user's responsibility to call close(). kr, tom -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Fix xen domain listing
On Friday 09 October 2009 11:35:47 Daniel P. Berrange wrote: These patches are a re-post of Jonas Eriksson's work from a couple of months ago, that we mistakenly forgot to commit. The first patch is unchanged, apart from being adjusted for new source code layout. The second patch is changed so that it checks against the hypervisor, not Xend, since using Xend has a very serious performance impact (as much as 1 second per domain queried has been seen) Looks very good so far, stable and fast! Thanks a lot, -t- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: Xen: Domain.migrate() causes invalid listDomains() output
And some more interesting behaviour: When I do node01:~# xm migrate -l wp02 node02 after libvirt has lost track of wp01, it reappears again at node02! node02:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 192 2 r- 74.1 wp01 3 512 2 -b 1.8 wp02 4 512 2 -b 0.0 But now, wp02 is not seen by libvirt. And I can push it further: node02:~# xm create wp03.cfg Using config file /etc/xen/wp03.cfg. Started domain wp03 node02:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 192 2 r- 80.5 wp01 3 512 2 -b 2.2 wp02 4 512 2 -b 0.4 wp03 5 512 2 -b 5.2 Now guess, wp02 reappears, but wp03 is missing. It seems to me that the domain with the highest ID is missing. node02:~# xm create wp04.cfg Using config file /etc/xen/wp04.cfg. Error: I need 524288 KiB, but dom0_min_mem is 262144 and shrinking to 262144 KiB would leave only 200712 KiB free. node02:~# Now, wp03 shortly pops up, but is then lost again. # xm shutdown wp03 Now wp02 is lost again! # xm shutdown wp02 and now, wp01. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Xen: Domain.migrate() causes invalid listDomains() output
On Wednesday 07 October 2009 10:25:11 Thomas Treutner wrote: Shall I provide more debug output? Here the debug output of libvirtd: http://tt.scripty.at/tmp/node01.txt.gz http://tt.scripty.at/tmp/node02.txt.gz At start, domain wp01 is @ node01, and wp02 @ node02. Then their placement is exchanged. After migration: node01:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 256 2 r- 37.9 wp02 2 512 2 -b 0.9 node02:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 192 2 r- 52.4 wp01 3 512 2 -b 1.0 virt-top etc. don't see w...@node02 anymore. libvirt obviously returns ID 1 for it, which can't be resolved. As there is no alternative to int[] listDomains() (f.e., return UUIDs), I'm stuck here. NB: Doing migration with xm migrate works fine, libvirt isn't confused by that. -t- -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Re: Xen: Domain.migrate() causes invalid listDomains() output
On Wednesday 07 October 2009 11:38:31 Daniel P. Berrange wrote: What is the output of 'xenstore-ls' on each host machine at this time ? http://tt.scripty.at/tmp/node01-xenstore-ls.txt.gz http://tt.scripty.at/tmp/node02-xenstore-ls.txt.gz node01:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 256 2 r- 29.1 wp02 2 512 2 -b 0.0 node02:~# xm list NameID Mem VCPUs State Time(s) Domain-0 0 192 2 r- 34.1 wp01 2 512 2 -b 0.0 w...@node01 is missing! thanks, t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
On Monday 05 October 2009 14:43:05 Daniel P. Berrange wrote: On Fri, Oct 02, 2009 at 09:59:27PM +0200, Thomas Treutner wrote: Hi list, I was wondering about the status of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=512367 Patch proposed but the original reporter never indicated whether it actually fixed the problem or not. If someone can confirm Now I get: remote_internal.c:1092: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a function) /usr/include/gcrypt.h is there. I did a ./configure, make clean, make. System is Ubuntu 8.04. When I close my connections properly, I run into this, most probably whent he Java garbage collector runs: https://www.redhat.com/archives/libvir-list/2009-March/msg00453.html ..although I didn't see a segfault yet. From what I read this bug is fixed in the Python bindings. Is the error message I get noisy but harmless or do the Java bindings need a patch too? kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Hi list, I was wondering about the status of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=512367 Is it correct that this is a bug in the libvirt client? I ran into this today, as I've written a kind of a VM scheduler (ressource requirements, placement etc.) in Java (libvirt-java 0.3.0, libvirt 0.6.5) and this is a show-stopper for me right now. I had some troubles with the newest version of libvirt (it couldn't connect to Xen IIRC), so I don't want to mess my setup again for nothing. What is actually causing this problem resp. in which situation is libvirt broken? When a client uses more than one connection at the same time? Or when a client uses more than one connection to the same server at the same time? Are there any recommeded workarounds? TIA kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: libvirt java bindings based on JNA
On Thursday 30 July 2009 03:30:20 Bryan Kearney wrote: Can you try the new release? It is cleaned up.. and should be easier to consume. Let me know if there are issues. Thanks, works fine so far (liblibvirt.so issue is gone). kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: libvirt java bindings based on JNA
On Thursday 30 July 2009 13:57:44 Thomas Treutner wrote: On Thursday 30 July 2009 03:30:20 Bryan Kearney wrote: Can you try the new release? It is cleaned up.. and should be easier to consume. Let me know if there are issues. Thanks, works fine so far (liblibvirt.so issue is gone). Sorry for the mixup, but I wasn't using the new version, Eclipse was accidentially configured for JNI version. It still doesn't work, so I looked in the code and did a quick experiment: src/main/java/org/libvirt/jna/Libvirt.java:23: -Libvirt INSTANCE = (Libvirt) Native.loadLibrary(libvirt, Libvirt.class); +Libvirt INSTANCE = (Libvirt) Native.loadLibrary(virt, Libvirt.class); and it works (without any symlinks hacks, of course). I don't have any experience with JNA, but I assume that somewhere a lib is being prepended and therefore libvirt is over-specified. What I still don't understand is my it is presumably working for you, and not for me: JNA 3.2.1 $ java -version java version 1.6.0_14 Java(TM) SE Runtime Environment (build 1.6.0_14-b08) Java HotSpot(TM) 64-Bit Server VM (build 14.0-b16, mixed mode) $ javac -version javac 1.6.0_14 btw, I don't see a JNA-branch in git://libvirt.org/libvirt-java.git anymore - is JNI-version now obsolete? kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Drop the leading lib from libvirt. Based on testing by tho...@scripty.at this is a better way to load the libarary
On Thursday 30 July 2009 16:24:02 Daniel Veillard wrote: On Thu, Jul 30, 2009 at 10:13:49AM -0400, Bryan Kearney wrote: --- src/main/java/org/libvirt/jna/Libvirt.java |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Per previous discussion, ACK ! It's better to not try to load a library we know doesn't exist (or if it was it might not be ours...) Now tried to use LD_LIBRARY_PATH, that works too (without this patch). But I really do not understand why setting that env var is necessary when /usr/local/lib is in my ld.so.conf and considering the following output, which is looking good, AFAIK: $ ldconfig -p | grep libvirt libvirt_jni.so.0 (libc6,x86-64) = /usr/local/lib/libvirt_jni.so.0 libvirt_jni.so (libc6,x86-64) = /usr/local/lib/libvirt_jni.so libvirt_jni.so (libc6,x86-64) = /usr/lib/libvirt_jni.so libvirt.so.0 (libc6,x86-64) = /usr/local/lib/libvirt.so.0 libvirt.so (libc6,x86-64) = /usr/local/lib/libvirt.so Ah, and tried JNA 3.0.9 too, no difference at all. kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: libvirt java bindings based on JNA
On Wednesday 29 July 2009 13:49:45 Bryan Kearney wrote: Thomas Treutner wrote: On Tuesday 28 July 2009 14:42:42 Bryan Kearney wrote: Thomas Treutner wrote: When using it with my tiny test application (which works fine with the JNI version), it first complains that /etc/pki/CA/cacert.pem can not be found. As I installed libvirt from source, it's in /usr/local/..., working fine with JNI. So I did a symlink workaround for now. Where did you see this complaint? Hm, I really cannot reproduce it anymore. Most probably it was caused by my libvirt-mixup. Also.. what is your LD_LIBRARY_PATH set to when running this. # cat /etc/ld.so.conf.d/* /usr/local/lib /usr/local/lib /usr/lib/kde4/lib # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu The file not found was cacert.pem, not the *.so - so I don't think LD_LIBRARY_PATH matters here? Anyways, the problem about conn = new Connect(xen://node02, false); was my fault - I forgot wiping an old apt-installed version of libvirt before compiling libvirt-java-jna. It works now, but there seems to be a massive typo somewhere; when I start my small application, it can't find liblibvirt.so (sic!) and exits. Really.. can you send me the output? Exception in thread main java.lang.UnsatisfiedLinkError: Unable to load library 'libvirt': liblibvirt.so: cannot open shared object file: No such file or directory at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:145) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:188) at com.sun.jna.Library$Handler.init(Library.java:123) at com.sun.jna.Native.loadLibrary(Native.java:255) at com.sun.jna.Native.loadLibrary(Native.java:241) at org.libvirt.jna.Libvirt.clinit(Unknown Source) at org.libvirt.Connect.clinit(Unknown Source) at MyTest.main(MyTest.java:13) MyTest.java:13: conn = new Connect(xen://node01/, false); What version of jna do you have? # cat META-INF/MANIFEST.MF Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.0 Created-By: 1.5.0_16-133 (Apple Inc.) Main-Class: com.sun.jna.Native Name: com/sun/jna/ Implementation-Title: com.sun.jna Implementation-Vendor: JNA Development Team Implementation-Version: 3.0.9 b0 Specification-Title: Java Native Access (JNA) Specification-Vendor: JNA Development Team Specification-Version: 3 It ist part of Eclipse, now downloaded 3.2.1 from jna.dev.java.net, with same results: Exception in thread main java.lang.UnsatisfiedLinkError: Unable to load library 'libvirt': liblibvirt.so: cannot open shared object file: No such file or directory at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:160) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:228) at com.sun.jna.Library$Handler.init(Library.java:140) at com.sun.jna.Native.loadLibrary(Native.java:372) at com.sun.jna.Native.loadLibrary(Native.java:357) at org.libvirt.jna.Libvirt.clinit(Unknown Source) at org.libvirt.Connect.clinit(Unknown Source) at MyTest.main(MyTest.java:13) hthtia, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: libvirt java bindings based on JNA
On Saturday 25 July 2009 13:56:36 Bryan Kearney wrote: I would like to get some comments on an initial cut of the java bindings on top of JNA[1]. They are not 100% complete (see below), but they are good enough to be criticized. In addition, if there are features additions to the API which people are interested in, I would appreciate the feedback on that. Thanks for your work! I pulled from git, it compiles fine when provided with jna.jar - couldn't find that except in my Eclipse 3.4 path. When using it with my tiny test application (which works fine with the JNI version), it first complains that /etc/pki/CA/cacert.pem can not be found. As I installed libvirt from source, it's in /usr/local/..., working fine with JNI. So I did a symlink workaround for now. But fixing that, it doesn't work either: libvir: error : invalid argument in could not parse connection URI exception caught:org.libvirt.LibvirtException: invalid argument in could not parse connection URI level:VIR_ERR_ERROR code:VIR_ERR_INVALID_ARG domain:VIR_FROM_NONE hasConn:false hasDom:false hasNet:false message:invalid argument in could not parse connection URI str1:invalid argument in %s str2:could not parse connection URI str3:null int1:0 int2:0 Code is: ... conn = new Connect(xen://node02, false); ... which works fine with JNI. When I use the test class (directly on a node where libvirtd is running, or remote, it doesn't matter), connections to the test driver are refused, although some test information seems to be gathered, and connecting with virsh works perfectly: node02:~# virsh --connect test:///default node02:~# java -cp libvirt-0.3.0pre.jar:jna.jar:. test libvir: Remote error : unable to connect to 'localhost': Connection refused exception caught:org.libvirt.LibvirtException: unable to connect to 'localhost': Connection refused level:VIR_ERR_ERROR code:VIR_ERR_SYSTEM_ERROR domain:VIR_FROM_REMOTE hasConn:false hasDom:false hasNet:false message:unable to connect to 'localhost': Connection refused str1:%s str2:unable to connect to 'localhost': Connection refused str3:null int1:-1 int2:-1 virNodeInfo.model:i686 virNodeInfo.memory:3145728 virNodeInfo.cpus:16 virNodeInfo.nodes:2 virNodeInfo.sockets:2 virNodeInfo.cores:2 virNodeInfo.threads:2 getHostName:node02.scripty.at getCapabilities:capabilities host cpu archi686/arch features pae/ nonpae/ /features /cpu topology cells num='2' cell id='0' cpus num='8' cpu id='0'/ cpu id='2'/ cpu id='4'/ cpu id='6'/ cpu id='8'/ cpu id='10'/ cpu id='12'/ cpu id='14'/ /cpus /cell cell id='1' cpus num='8' cpu id='1'/ cpu id='3'/ cpu id='5'/ cpu id='7'/ cpu id='9'/ cpu id='11'/ cpu id='13'/ cpu id='15'/ /cpus /cell /cells /topology /host guest os_typehvm/os_type arch name='i686' wordsize32/wordsize emulator/usr/bin/test-hv/emulator domain type='test' /domain /arch features pae/ nonpae/ /features /guest guest os_typexen/os_type arch name='i686' wordsize32/wordsize emulator/usr/bin/test-hv/emulator domain type='test' /domain /arch features pae/ nonpae/ /features /guest /capabilities getMaxVcpus:32 getType:Test getURI:test:// getVersion:2 getLibVirVersion:4006 conn.networkCreateXML: org.libvirt.netw...@3d434234 conn.networkDefineXML: org.libvirt.netw...@30f7f540 numOfDefinedNetworks:1 listDefinedNetworks:[Ljava.lang.String;@10b61fd1 - deftest numOfNetworks:2 listNetworks:[Ljava.lang.String;@24e2dae9 - createst - default conn.domainDefineXML:org.libvirt.dom...@27ce2dd4 conn.domainCreateLinux:org.libvirt.dom...@5122cdb6 numOfDefinedDomains:1 listDefinedDomains:[Ljava.lang.String;@43ef9157 deftest numOfDomains:2 listDomains:[...@252f0999 - 2 - 1 networkLookupByName: deftest == FIXME networkLookupByUUIDString: deftest virNetworkGetXMLDesc:network namedeftest/name uuid004b96e1-2d78-c30f-5aa5-f03c87d21e67/uuid forward dev='eth0' mode='nat'/ bridge name='deftest' stp='on' forwardDelay='0' / ip address='192.168.88.1' netmask='255.255.255.0' dhcp range start='192.168.88.128' end='192.168.88.253' / /dhcp /ip /network virNetworkGetAutostart:false virNetworkGetBridgeName:deftest virNetworkGetName:deftest virNetworkGetUUID:[...@443ecfff == FIXME 004bff96ffe12d78ffc30f5affa5fff03cff87ffd21e67 virNetworkGetName:004b96e1-2d78-c30f-5aa5-f03c87d21e67 virNetworkDestroy: virNetworkCreate: virNetworkCreate (should error): libvir: Test error deftest: internal error Network is already running
[libvirt] libvirt-java, deprecated methods?
Hi, I'm playing around with libvirt-0.6.5 and libvirt-java-0.2.1 these days. It looks very interesting, but I think I may have found a bug: conn = new Connect(xen://node02, false); conn.setDom0Memory(512000) gives: exception caught:org.libvirt.LibvirtException: invalid domain pointer in virDomainSetMemory level:VIR_ERR_ERROR code:VIR_ERR_INVALID_DOMAIN domain:VIR_FROM_DOM hasConn:false hasDom:false hasNet:false message:invalid domain pointer in virDomainSetMemory str1:invalid domain pointer in %s str2:virDomainSetMemory str3:null int1:0 int2:0 Furthermore, f.e. conn.GetHypervisorVersion(conn.getType()) gives: exception caught:org.libvirt.LibvirtException: this function is not supported by the hypervisor: Xen level:VIR_ERR_ERROR code:VIR_ERR_NO_SUPPORT domain:VIR_FROM_NONE hasConn:false hasDom:false hasNet:false message:this function is not supported by the hypervisor: Xen str1:this function is not supported by the hypervisor: %s str2:Xen str3:null int1:0 int2:0 But Domain dom0=conn.domainLookupByID(0); //domainLookupByName(Domain-0); too DomainInfo dom0info = dom0.getInfo(); dom0.setMemory(256000); works without glitches and does the job (btw, I can't see any effect of setMaxMemory() on Xen?) Is it possible that there are some inconsistences between libvirt-java and libvirt? Since libvirt-java wasn't updated approx. 1y, I assume that. Thanks for feedback, kr, thomas -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] cp error in api doc
I think there's a cp error: http://libvirt.org/html/libvirt-libvirt.html#virStoragePoolUndefine Returns: a virStoragePoolPtr object, or NULL if creation failed I assume it is 0 on success, -1 on failure as the return is of type int. kr,t -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
