[libvirt] about qemu monitor mode.
Hello there libvirt compiles JSON mode as the default qemu monitor mode if yajl-devel is available. As a result of this solution, the user has no way to change into the text mode. And because the qemu QMP always lacks commands currently, such as savevm, it will prevent us creating the snapshot of domain, especially for us who want to do some testing. What I think is could we add the configuration item in qemu.conf? so that the user can choose which mode to use, such as: monitor_mode=json #monitor_mode=text Regards osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt: C++ or Java?
Hello, I am planning to develop a management application for managing Redhat Xen and Redhat KVM hypervisors. I am evaluating the Java bindings versus the C++ version of libvirt. As part of evaluation, I could not find meaningful answers to the questions below. Hence, I thought that people on this mailing list would be the most appropriate to comment on them. Can you please let me know your views? 1. Are all functions that are available in C API available in Java? 2. Are Java bindings added along with every enhancement to C API? 3. If answer to above question is negative, typically how long does it takes for the addition of Java bindings for the enhancement? 4. Most of libvirt based third party management applications use which of Java bindings or C API? 5. What are your good/bad experiences while using either of C API or Java bindings? 6. What is your concluding personal recommendation? And finally, since libvirt is a Redhat Emerging Technology project, does Redhat or any other third party service providers provide paid assistance, support? Appreciate your time. Thanks. Regards, Ganesh -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problems accessing ESX using libvirt
Given the latest version of libvirt available for RHEL 5 is libvirt-0.6.3-33, what is the recommended download site for libvirt-0.7.0? Obviously I can get a copy off of brew, but what dependency issues might I run into and is it possible for the customer to get simply leverage a libvirt from Fedora? Regards, -- Eric L. Sammons, RHCE Red Hat, Inc. Technical Account Manager Office: 919.754.4963 | Cell: 919.802.0239 - Original Message - From: Matthias Bolte matthias.bo...@googlemail.com To: Matthew Booth mbo...@redhat.com Cc: libvir-list@redhat.com, Eric Sammons esamm...@redhat.com Sent: Thursday, April 8, 2010 11:37:05 AM GMT -05:00 US/Canada Eastern Subject: Re: [libvirt] Problems accessing ESX using libvirt 2010/4/8 Matthew Booth mbo...@redhat.com: I was forwarded the following query relating to v2v: === There are no firewalls between the hosts and the ESX firewall is configured to allow all incoming outgoing connections. The virsh -c 'esx://elabhost011.xxx/' list --all command also fails in the same way as the virt-v2v command. When I run the 'virsh list' command it doesn't prompt for a username/password as in the example below. If I run tcpdump on the ESX host, when 'virsh list' is run, I see the packet arrive from the test box and a reply sent back, only these two packets are sent between the hosts: 09:51:20.205524 bwyhs0020p.xxx.56436 elabhost011.xxx.16514: S 338(0) win 5840 mss 1460,sackOK,timestamp 1214177495 0,nop,wscale 7 (DF) 09:51:20.205544 elabhost011.xxx.16514 bwyhs0020p.xxx.56436: R 0:9 win 0 (DF) The problem is there is nothing listening on port 16514 on the ESX host, hence the Connection refused message. Should the connection be using the TSL port as opposed to a 'ESX' port? === The user is using libvirt 0.6.3-20.1.el5_4. Unfortunately I'm not intimately familiar with how the libvirt ESX driver magic works. Can anybody shed any light? Thanks, ESX support was added in libvirt 0.7.0. So libvirt 0.6.3 is too old. Libvirt will give unexpected error messages when you give it URIs that no driver handles. For example if no local driver claims to handle an URI the remote driver will try to connect to a libvirtd on the server and uses TLS (default libvirt port 16514) for that. That's what you see in the tcpdump there. Matthias -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [vserver] Linux-vServer Support in libvirt
On Thu, Apr 1, 2010 at 6:15 PM, Walter Stanish walter.stan...@saffrondigital.com wrote: Hi libvir-list (cc: vserver list), I am another Linux-vServer user who would like to see support in libvirt. From a very brief look back through the archives it appears that there may have been some architectural concerns re: libvirt's assumptions about what kind of network stack a virtualisation platform provides, in that Linux-vServer doesn't use a traditional approach to networking and thus may break previously valid assumptions. I found 2007 posts and a post last year (2009). I remeber hearing that the patches have been submitted multiple times http://www.paul.sladen.org/vserver/archives/200807/0003.html Would it be possible for someone with a good overall understanding of previous integration attempts and the results thereof to summarise what issues were encountered and how difficult it would be to overcome these, so that users can understand what's going on. The issue: linux-vserver is not sexy and hip like some of those other technologies. Maybe if vserver was a huge hulking patch, had really slow emulation, and or then more or less got killed by being aquired by a large non-open source friendly company... http://boycottnovell.com/2009/02/25/xen-spit-it-out-strategy/ ...people would start adopting it. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt: C++ or Java
Hello, I am planning to develop a management application for managing Redhat Xen and Redhat KVM hypervisors. I am evaluating the Java bindings versus the C++ version of libvirt. As part of evaluation, I could not find meaningful answers to the questions below. Hence, I thought that people on this mailing list would be the most appropriate to comment on them. Can you please let me know your views? 1. Are all functions that are available in C API available in Java? 2. Are Java bindings added along with every enhancement to C API? 3. If answer to above question is negative, typically how long does it takes for the addition of Java bindings for the enhancement? 4. Most of libvirt based third party management applications use which of Java bindings or C API? 5. What are your good/bad experiences while using either of C API or Java bindings? 6. What is your concluding personal recommendation? And finally, since libvirt is a Redhat Emerging Technology project, does Redhat or any other third party service providers provide paid assistance, support? Thanks, Shashi -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote: Daniel P. Berrange wrote: I think this alteration of existing args is fr too complex fragile, and way overkill. Would it not be simpler, for the target audience, for the config to contain a one-line shell script to transform particular matched arguments in any way that's wanted? I might be missing something but I thought you could already do this in current libvirt. ie. Change the emulator element [1] to point to your shell script: emulator/usr/local/bin/my-qemu-wrapper.sh/emulator The wrapper should get called with the command line arguments and you can alter them however you like. Isn't that right, Dan? Rich. [1] http://libvirt.org/formatdomain.html#elementsDevices -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
Richard W.M. Jones wrote: On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote: Daniel P. Berrange wrote: I think this alteration of existing args is fr too complex fragile, and way overkill. Would it not be simpler, for the target audience, for the config to contain a one-line shell script to transform particular matched arguments in any way that's wanted? I might be missing something but I thought you could already do this in current libvirt. ie. Change the emulator element [1] to point to your shell script: emulator/usr/local/bin/my-qemu-wrapper.sh/emulator The wrapper should get called with the command line arguments and you can alter them however you like. Isn't that right, Dan? That forces the shell script to be relatively complicated and recognise all qemu arguments (including version specific ones) to skip the ones with parameters - and to know where to look for the real target executable is. It's not a very friendly way to add or change parts of specific subsystems, for example modifying a blockdev parameter, but it can be done that way if necessary. It's not that hard to write this for trivial extra options: emulator/bin/sh -c 'qemu $0 $@ -extra-flag'/emulator (if that works). But for things like modifications to particular devices, wouldn't it be better to associate add cache=special option to a section about one of the blockdevs which libvirt knows about, rather than the awful prospect of parsing libvirt's output to guess which of three -device arguments corresponds with the second SCSI drive mentioned in the libvirt config - which might not necessarily be the second on the command line, even. Parsing libvirt output and having to guess which option corresponds to what from the libvirt config sounds very fragile and also a rather large amount of effort for something which should be easy. And then there's modifying how network tap devices are set up and other networking, outside qemu, but requested by libvirt. Doing that in emulator sounds like a bad idea, but script hooks are the only sane way to make networking fit every environment and requirement. Ideally without forcing the hook writer to reimplement the normal network setup from scratch just to tweak it a bit. I apologise if libvirt already provides such hooks - I haven't looked at that part of it. -- Jamie -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
