- Devel - libvirt List Archives

[libvirt] QEMU/KVM auto-detection bug
by Chris Lalancette 12 May '09

12 May '09

All, Even with Guido/Pritesh's recent changes to the vbox open routine, the auto-detection in libvirt is currently broken. What happens is that in src/libvirt.c:do_open(), at the start of the loop to auto-detect drivers, ret->uri is NULL. As each driver declines, it remains NULL. However, the very first thing the vboxOpen() routine does is: if (conn->uri == NULL) { conn->uri = xmlParseURI(uid ? "vbox:///session" : "vbox:///system"); if (conn->uri == NULL) { return VIR_DRV_OPEN_ERROR; } So, any driver that is trying to auto-probe after vboxOpen sees a conn->uri with a scheme of vbox and a path of system/session, and they all fail (including Qemu, which is what I'm mostly concerned with at the moment). In point of fact, this whole auto-detection thing is fragile. We got away with it before because the qemuOpen() routine bombs out before doing the whole conn->uri == NULL check, but in general, it's very easy for one buggy driver to mess up auto-detection for all drivers. Any thoughts about where to go here? We should obviously fix the vboxOpen() routine to not mess with the URI if it's going to fail. Additionally, I was thinking that maybe we should reset conn->uri to NULL in each iteration of the auto-detection loop. While that might leak memory for buggy drivers, it should at least make this whole thing less fragile. Thoughts? -- Chris Lalancette

3 5

[libvirt] [PATCH 1/6] Allow multiple monitor devices (v2)
by Anthony Liguori 12 May '09

12 May '09

Right now only one monitor device can be enabled at a time. In order to support asynchronous notification of events, I would like to introduce a 'wait' command that waits for an event to occur. This implies that we need an additional monitor session to allow commands to still be executed while waiting for an asynchronous notification. Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com> diff --git a/vl.c b/vl.c index 4bd173f..f78cabb 100644 --- a/vl.c +++ b/vl.c @@ -184,6 +184,9 @@ int main(int argc, char **argv) /* Max number of bluetooth switches on the commandline. */ #define MAX_BT_CMDLINE 10 +/* Maximum number of monitor devices */ +#define MAX_MONITOR_DEVICES 10 + /* XXX: use a two level table to limit memory usage */ #define MAX_IOPORTS 65536 @@ -4252,8 +4255,9 @@ int main(int argc, char **argv, char **envp) int hda_index; int optind; const char *r, *optarg; - CharDriverState *monitor_hd = NULL; - const char *monitor_device; + CharDriverState *monitor_hds[MAX_MONITOR_DEVICES]; + const char *monitor_devices[MAX_MONITOR_DEVICES]; + int monitor_device_index; const char *serial_devices[MAX_SERIAL_PORTS]; int serial_device_index; const char *parallel_devices[MAX_PARALLEL_PORTS]; @@ -4324,7 +4328,6 @@ int main(int argc, char **argv, char **envp) kernel_cmdline = ""; cyls = heads = secs = 0; translation = BIOS_ATA_TRANSLATION_AUTO; - monitor_device = "vc:80Cx24C"; serial_devices[0] = "vc:80Cx24C"; for(i = 1; i < MAX_SERIAL_PORTS; i++) @@ -4340,6 +4343,11 @@ int main(int argc, char **argv, char **envp) virtio_consoles[i] = NULL; virtio_console_index = 0; + monitor_devices[0] = "vc:80Cx24C"; + for (i = 1; i < MAX_MONITOR_DEVICES; i++) + monitor_devices[i] = NULL; + monitor_device_index = 0; + usb_devices_index = 0; nb_net_clients = 0; @@ -4723,7 +4731,12 @@ int main(int argc, char **argv, char **envp) break; } case QEMU_OPTION_monitor: - monitor_device = optarg; + if (monitor_device_index >= MAX_MONITOR_DEVICES) { + fprintf(stderr, "qemu: too many monitor devices\n"); + exit(1); + } + monitor_devices[monitor_device_index] = optarg; + monitor_device_index++; break; case QEMU_OPTION_serial: if (serial_device_index >= MAX_SERIAL_PORTS) { @@ -4974,8 +4987,8 @@ int main(int argc, char **argv, char **envp) serial_devices[0] = "stdio"; if (parallel_device_index == 0) parallel_devices[0] = "null"; - if (strncmp(monitor_device, "vc", 2) == 0) - monitor_device = "stdio"; + if (strncmp(monitor_devices[0], "vc", 2) == 0) + monitor_devices[0] = "stdio"; } #ifndef _WIN32 @@ -5184,14 +5197,14 @@ int main(int argc, char **argv, char **envp) #endif /* Maintain compatibility with multiple stdio monitors */ - if (!strcmp(monitor_device,"stdio")) { + if (!strcmp(monitor_devices[0],"stdio")) { for (i = 0; i < MAX_SERIAL_PORTS; i++) { const char *devname = serial_devices[i]; if (devname && !strcmp(devname,"mon:stdio")) { - monitor_device = NULL; + monitor_devices[0] = NULL; break; } else if (devname && !strcmp(devname,"stdio")) { - monitor_device = NULL; + monitor_devices[0] = NULL; serial_devices[i] = "mon:stdio"; break; } @@ -5208,11 +5221,20 @@ int main(int argc, char **argv, char **envp) } } - if (monitor_device) { - monitor_hd = qemu_chr_open("monitor", monitor_device, NULL); - if (!monitor_hd) { - fprintf(stderr, "qemu: could not open monitor device '%s'\n", monitor_device); - exit(1); + for (i = 0; i < MAX_MONITOR_DEVICES; i++) { + const char *devname = monitor_devices[i]; + if (devname && strcmp(devname, "none")) { + char label[32]; + if (i == 0) + snprintf(label, sizeof(label), "monitor"); + else + snprintf(label, sizeof(label), "monitor%d", i); + monitor_hds[i] = qemu_chr_open(label, devname, NULL); + if (!monitor_hds[i]) { + fprintf(stderr, "qemu: could not open monitor device '%s'\n", + devname); + exit(1); + } } } @@ -5335,8 +5357,13 @@ int main(int argc, char **argv, char **envp) text_consoles_set_display(display_state); qemu_chr_initial_reset(); - if (monitor_device && monitor_hd) - monitor_init(monitor_hd, MONITOR_USE_READLINE | MONITOR_IS_DEFAULT); + for (i = 0; i < MAX_MONITOR_DEVICES; i++) { + if (monitor_devices[i] && monitor_hds[i]) { + monitor_init(monitor_hds[i], + MONITOR_USE_READLINE | + ((i == 0) ? MONITOR_IS_DEFAULT : 0)); + } + } for(i = 0; i < MAX_SERIAL_PORTS; i++) { const char *devname = serial_devices[i];

11 60

[libvirt] PATCH: Fix QEMU arg detection for kvm >= 85
by Daniel P. Berrange 11 May '09

11 May '09

The -help output from KVM >= 85 is now large than we expected. This patch increases the buffer from 8k to 64k when reading help. It also provides more detailed error messages should something go wrong in the future. Two examples of improved error reporting # virsh -c qemu:///system start VirtTest error: Failed to start domain VirtTest error: Unable to read QEMU help output: Value too large for defined data type # virsh -c qemu:///system start VirtTest error: Failed to start domain VirtTest error: internal error cannot parse QEMU version number in 'QEMU PC emulator version 0.9.1 (kvm-79), Copyright (c) 2003-2008 Fabrice Bellard' Daniel Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.145 diff -u -p -r1.145 qemu_conf.c --- src/qemu_conf.c 8 May 2009 10:07:16 -0000 1.145 +++ src/qemu_conf.c 8 May 2009 10:37:22 -0000 @@ -431,18 +431,28 @@ int qemudExtractVersionInfo(const char * return -1; char *help = NULL; - enum { MAX_HELP_OUTPUT_SIZE = 8192 }; + enum { MAX_HELP_OUTPUT_SIZE = 1024*64 }; int len = virFileReadLimFD(newstdout, MAX_HELP_OUTPUT_SIZE, &help); - if (len < 0) + if (len < 0) { + virReportSystemError(NULL, errno, "%s", + _("Unable to read QEMU help output")); goto cleanup2; + } if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", &major, &minor, &micro, &kvm_version) != 4) kvm_version = 0; - if (!kvm_version && sscanf(help, "QEMU PC emulator version %u.%u.%u", - &major, &minor, &micro) != 3) + if (!kvm_version && + sscanf(help, "QEMU PC emulator version %u.%u.%u", + &major, &minor, &micro) != 3) { + char *eol = strchr(help, '\n'); + if (eol) *eol = '\0'; + qemudReportError(NULL, NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _("cannot parse QEMU version number in '%s'"), + help); goto cleanup2; + } version = (major * 1000 * 1000) + (minor * 1000) + micro; Index: src/qemu_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_driver.c,v retrieving revision 1.236 diff -u -p -r1.236 qemu_driver.c --- src/qemu_driver.c 8 May 2009 10:11:14 -0000 1.236 +++ src/qemu_driver.c 8 May 2009 10:37:22 -0000 @@ -1379,12 +1379,8 @@ static int qemudStartVMDaemon(virConnect if (qemudExtractVersionInfo(emulator, NULL, - &qemuCmdFlags) < 0) { - qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("Cannot determine QEMU argv syntax %s"), - emulator); + &qemuCmdFlags) < 0) goto cleanup; - } if (qemuPrepareHostDevices(conn, vm->def) < 0) goto cleanup; @@ -3703,12 +3699,8 @@ static int qemudDomainChangeEjectableMed if (qemudExtractVersionInfo(vm->def->emulator, NULL, - &qemuCmdFlags) < 0) { - qemudReportError(conn, dom, NULL, VIR_ERR_INTERNAL_ERROR, - _("Cannot determine QEMU argv syntax %s"), - vm->def->emulator); + &qemuCmdFlags) < 0) return -1; - } if (qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE) { if (!(devname = qemudDiskDeviceName(conn, newdisk))) -- |: 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 :|

2 1

[libvirt] [PATCH v2 0/4] Improve QEMU process startup error
by Cole Robinson 11 May '09

11 May '09

Error reporting for failed QEMU processes isn't too great at the moment. A couple cases I have hit: - Trying to start a VM with a cdrom pointing to a nonexistent file. The svirt hook function choked on this and indicated as much in the domain log, but I still had to wait for the pidfile timeout (10 seconds), and the only error reported was 'Domain did not show up'. - QEMU dies quickly at startup. Happened with the pulse audio issue, or if we build cli args incorrectly. The reporting here varies: if QEMU dies before writing out the pidfile, the above case applies. If the pidfile is written, we timeout in ReadLogOutput, and it's hit or miss whether we even report the logfile output to the user. The following patches improve the above cases by ensuring we never have to wait for a timeout, and that the logfile output is always reported in the error message. Changes since v1: Drop patch 1 + 2 (applied separately) Patch 7 is pretty isolated, so was resent to list separately. Don't waitpid in virExecDaemonize if virExec fails. Remove needless pidfile loop in qemudStartVMDaemon. Thanks, Cole Cole Robinson (4): Add helper function virExecDaemonize Report qemu log data if we fail to daemonize the process. Add pidfile argument to __virExec Check that QEMU is still alive while reading startup output. src/libvirt_private.syms | 2 +- src/proxy_internal.c | 16 +--- src/qemu_conf.c | 7 -- src/qemu_driver.c | 89 +++++++++++-------- src/remote_internal.c | 15 +--- src/uml_driver.c | 11 +-- src/util.c | 90 +++++++++++++++++--- src/util.h | 15 +++- .../qemuxml2argvdata/qemuxml2argv-boot-cdrom.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-boot-floppy.args | 2 +- .../qemuxml2argv-boot-network.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-bootloader.args | 2 +- .../qemuxml2argv-clock-localtime.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-clock-utc.args | 2 +- .../qemuxml2argv-console-compat.args | 2 +- .../qemuxml2argv-disk-cdrom-empty.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-cdrom.args | 2 +- .../qemuxml2argv-disk-drive-boot-cdrom.args | 2 +- .../qemuxml2argv-disk-drive-boot-disk.args | 2 +- .../qemuxml2argv-disk-drive-cache-v1-none.args | 2 +- .../qemuxml2argv-disk-drive-cache-v1-wb.args | 2 +- .../qemuxml2argv-disk-drive-cache-v1-wt.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-none.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-wb.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-wt.args | 2 +- .../qemuxml2argv-disk-drive-fmt-qcow.args | 2 +- .../qemuxml2argv-disk-drive-shared.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-floppy.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-disk-many.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-disk-usb.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-virtio.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-disk-xenvbd.args | 2 +- .../qemuxml2argv-graphics-sdl-fullscreen.args | 2 +- .../qemuxml2argv-graphics-sdl.args | 2 +- .../qemuxml2argv-graphics-vnc-sasl.args | 2 +- .../qemuxml2argv-graphics-vnc-tls.args | 2 +- .../qemuxml2argv-graphics-vnc.args | 2 +- .../qemuxml2argv-hostdev-pci-address.args | 2 +- .../qemuxml2argv-hostdev-usb-address.args | 2 +- .../qemuxml2argv-hostdev-usb-product.args | 2 +- .../qemuxml2argv-input-usbmouse.args | 2 +- .../qemuxml2argv-input-usbtablet.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-input-xen.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-migrate.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-minimal.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-misc-acpi.args | 2 +- .../qemuxml2argv-misc-no-reboot.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-misc-uuid.args | 2 +- .../qemuxml2argv-net-eth-ifname.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-net-eth.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-net-user.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-net-virtio.args | 2 +- .../qemuxml2argv-parallel-tcp.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-restore-v1.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-restore-v2.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-dev.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-file.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-many.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-pty.args | 2 +- .../qemuxml2argv-serial-tcp-telnet.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-tcp.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-udp.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-serial-unix.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-serial-vc.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-sound.args | 2 +- 65 files changed, 211 insertions(+), 148 deletions(-)

2 9

[libvirt] [PATCH 2/3] support for "Host only" and "Internal" networks in VirtualBox driver
by Pritesh Kothari 11 May '09

11 May '09

Hi All, As discussed on the list resending the networking patch's. the patch's are as below: [PATCH 1/3]: contains support for "Internal" network in libvirt [PATCH 2/3]: contains support for "Host only" and "Internal" networks in VirtualBox driver [PATCH 3/3]: contains networking API for hostonly networks in VirtualBox driver in libvirt (it contains all the fix's proposed on list along with two extra *DefinedNetworks functions) The patches work as per cvs checkin today. (git SHA1 ID: 9136ae2056b45ea83854d3fe31d860f645b8c883) Regards, Pritesh

3 2

[libvirt] [PATCH 1/3] support for "Internal" network in libvirt
by Pritesh Kothari 11 May '09

11 May '09

Hi All, As discussed on the list resending the networking patch's. the patch's are as below: [PATCH 1/3]: contains support for "Internal" network in libvirt [PATCH 2/3]: contains support for "Host only" and "Internal" networks in VirtualBox driver [PATCH 3/3]: contains networking API for hostonly networks in VirtualBox driver in libvirt (it contains all the fix's proposed on list along with two extra *DefinedNetworks functions) The patches work as per cvs checkin today. (git SHA1 ID: 9136ae2056b45ea83854d3fe31d860f645b8c883) Regards, Pritesh

3 2

[libvirt] Status and plans for next release
by Daniel Veillard 11 May '09

11 May '09

Seems I didn't send any reminder about the next release plans on Friday, so here is a recap: - feature freeze on the 22nd so we have 2 more week to work on reviewing and adding OpenNebula/Power drivers and try to get the NPIV, netcf and secure migration patches in. It's likely not everything will make the release cut but we can try ! - target for next release is Friday 29th So far we have mostly a lot of bug fixes and VirtualBox driver updates commited since 0.6.3, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] Java binding blockStats bug (libvirt-java-0.2.1)
by Zvi Dubitzky 11 May '09

11 May '09

running blcokStats() with Java binding (libvirt-java-0.2.1 ) I get an exception Inspecting the src/jni/org_libvirt_Domain.c is see the following lines of code : JNIEXPORT jobject JNICALL Java_org_libvirt_Domain__1blockStats (JNIEnv *env, jobject obj, jlong VDP, jstring j_path){ struct _virDomainBlockStats stats; jobject j_stats; jclass stats_cls=(*env)->FindClass(env, "org/libvirt/DomainInterfaceStats"); const char *path = (*env)->GetStringUTFChars(env, j_path, NULL); if(virDomainBlockStats((virDomainPtr)VDP, path, &stats, sizeof(struct _virDomainBlockStats))<0){ (*env)->ReleaseStringUTFChars(env, j_path, path); return NULL; } . . . The bold line should be replaced by : jclass stats_cls=(*env)->FindClass(env, "org/libvirt/DomainBlockStats") as we deal here with blockStats and not network interface Stats ! thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

2 1

[libvirt] Fw: Java api for domain migration
by Zvi Dubitzky 10 May '09

10 May '09

Sorry , clarification: Bottom line is that the Java binding of libvirt should accept 'dname' parameter = null as the C libvirt case does without crashing The below stament that " If I try to specify a meaningful 'dname' then if it is the same name as the original host domain 'name' I will get a message saying : invalid domain pointer in no domain with matching id -1." is not correct. The migrate works under Java in this case as in the C case i.e the domain is migrated to the destination host but remains paused there for a long time until resumed there. If the 'dname' is null then the migration is faster but that works ok only with the libvirt C library. It crashes with the Java binding . Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL ----- Forwarded by Zvi Dubitzky/Haifa/IBM on 10/05/2009 13:29 ----- Zvi Dubitzky/Haifa/IBM 10/05/2009 13:14 To libvir-list(a)redhat.com cc Subject Fw: Java api for domain migration Hi I think I detected the origin of the libvirt Java binding crash in the case of domain migration though I do not know how to fix it yet . The fix should be in the src/jni/org_libvirt_Domain.c / migrate function. First: It turns out the that the C libvirt interface for migrate ( libvirt 0.6.1. + kvm-84) has a limitation with specifying the 'dname' parameter . It should be NULL to work ok , meaning the domain is migrated from the old host to the new host under the same domain name . If I try to specify a meaningful 'dname' then if it is the same name as the original host domain 'name' I will get a message saying : invalid domain pointer in no domain with matching id -1. If I am using 'dname' different than the original host domain 'name' it will complain that no such domain is found on the target host. So using NULL for 'dname' is the only one that makes the migrate work Using 'dname' = NULL with the Java binding causes it though to crash as below (see .log file). Fixing the jni code as below (see added 'if') does not help: src/jni/org_libvirt_Domain.c -------------------------------- JNIEXPORT jlong JNICALL Java_org_libvirt_Domain__1migrate (JNIEnv *env, jobject obj, jlong VDP, jobject dconn, jlong flags, jstring j_dname, jstring j_uri, jlong bandwidth){ virConnectPtr destVCP; const char *dname=NULL; const char *uri=NULL; //if String="", we pass NULL to the library if((*env)->GetStringLength(env, j_dname)>0) dname=(*env)->GetStringUTFChars(env, j_dname, NULL); //if String="", we pass NULL to the library if((*env)->GetStringLength(env, j_uri)>0) uri=(*env)->GetStringUTFChars(env, j_uri, NULL); //Extract the destination Conn Ptr destVCP=(virConnectPtr)(*env)->GetLongField(env, dconn, (*env)->GetFieldID(env, (*env)->GetObjectClass(env, dconn), "VCP", "J")); jlong retval = (jlong)virDomainMigrate((virDomainPtr)VDP, destVCP, flags, dname, uri, bandwidth) ; if (dname) (*env)->ReleaseStringUTFChars(env, j_dname, dname); if (uri) (*env)->ReleaseStringUTFChars(env, j_uri, uri); return retval; } Please your advice on how to solve the migrate for the Java binding thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL ----- Forwarded by Zvi Dubitzky/Haifa/IBM on 10/05/2009 12:59 ----- Zvi Dubitzky/Haifa/IBM 07/05/2009 13:49 To libvir-list(a)redhat.com cc Subject Java api for libvirt migration I am trying to do a migrate of VM with libvirt 0.6.1 and kvm-84 . I am successful in doing it many times via the C interface . I can do most of the basic libvirt activity via the libvirt JAVA library (libvirt-java-0.2.1). When it comes to a migrate the JVM fails wit a log file attached below . Can someone help. My memory consumption in my JAVA test code is small. The migrate parameters I am sending with the Java are identical to those I use in the C case and is: destDomain = localDomain.migrate (dcon, // destination host Connect object VIR_MIGRATE_LIVE, null, //const char *dname destination domain name target_uri, //"tcp:9.148.28.13:4444" 0 // unsigned long bandwidth) - do not specify ); thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

1 0

[libvirt] Fw: Java api for domain migration
by Zvi Dubitzky 10 May '09

10 May '09

Hi I think I detected the origin of the libvirt Java binding crash in the case of domain migration though I do not know how to fix it yet . The fix should be in the src/jni/org_libvirt_Domain.c / migrate function. First: It turns out the that the C libvirt interface for migrate ( libvirt 0.6.1. + kvm-84) has a limitation with specifying the 'dname' parameter . It should be NULL to work ok , meaning the domain is migrated from the old host to the new host under the same domain name . If I try to specify a meaningful 'dname' then if it is the same name as the original host domain 'name' I will get a message saying : invalid domain pointer in no domain with matching id -1. If I am using 'dname' different than the original host domain 'name' it will complain that no such domain is found on the target host. So using NULL for 'dname' is the only one that makes the migrate work Using 'dname' = NULL with the Java binding causes it though to crash as below (see .log file). Fixing the jni code as below (see added 'if') does not help: src/jni/org_libvirt_Domain.c -------------------------------- JNIEXPORT jlong JNICALL Java_org_libvirt_Domain__1migrate (JNIEnv *env, jobject obj, jlong VDP, jobject dconn, jlong flags, jstring j_dname, jstring j_uri, jlong bandwidth){ virConnectPtr destVCP; const char *dname=NULL; const char *uri=NULL; //if String="", we pass NULL to the library if((*env)->GetStringLength(env, j_dname)>0) dname=(*env)->GetStringUTFChars(env, j_dname, NULL); //if String="", we pass NULL to the library if((*env)->GetStringLength(env, j_uri)>0) uri=(*env)->GetStringUTFChars(env, j_uri, NULL); //Extract the destination Conn Ptr destVCP=(virConnectPtr)(*env)->GetLongField(env, dconn, (*env)->GetFieldID(env, (*env)->GetObjectClass(env, dconn), "VCP", "J")); jlong retval = (jlong)virDomainMigrate((virDomainPtr)VDP, destVCP, flags, dname, uri, bandwidth) ; if (dname) (*env)->ReleaseStringUTFChars(env, j_dname, dname); if (uri) (*env)->ReleaseStringUTFChars(env, j_uri, uri); return retval; } Please your advice on how to solve the migrate for the Java binding thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL ----- Forwarded by Zvi Dubitzky/Haifa/IBM on 10/05/2009 12:59 ----- Zvi Dubitzky/Haifa/IBM 07/05/2009 13:49 To libvir-list(a)redhat.com cc Subject Java api for libvirt migration I am trying to do a migrate of VM with libvirt 0.6.1 and kvm-84 . I am successful in doing it many times via the C interface . I can do most of the basic libvirt activity via the libvirt JAVA library (libvirt-java-0.2.1). When it comes to a migrate the JVM fails wit a log file attached below . Can someone help. My memory consumption in my JAVA test code is small. The migrate parameters I am sending with the Java are identical to those I use in the C case and is: destDomain = localDomain.migrate (dcon, // destination host Connect object VIR_MIGRATE_LIVE, null, //const char *dname destination domain name target_uri, //"tcp:9.148.28.13:4444" 0 // unsigned long bandwidth) - do not specify ); thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

1 0