On 02/08/2013 12:20 PM, Scott Stark wrote: [any way you can convince your mailer to wrap long lines?]

I'm working with a java vm vendor that is developing a multi-tenancy jvm and is trying to leverage the libvirt framework for the domain configuration. Right now the java language binding leverages the libvirt c library for parsing the domain.xml file. What are the thoughts on adding a 'jvm' domain type?

You mean, adding a a src/jvm/jvm_driver.c backend that supports a jvm:/// URI for connecting to your vms? Seems reasonable; we've added support for other hypervisor technologies in the past.

I believe there would need to be a jvm specific section in a separate namespace similar to the qemucmdline section.

You may want to look at the patches for adding a URI for parallels:// (commit cafc26ff, and lots of more recent commits with a prefix of 'parallels:') or hyperv:// (commit 4d6e6f4 and more recent commits with a prefix of 'hyperv:') for inspiration on what it would take to contribute your patch. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

On Fri, Feb 08, 2013 at 02:20:25PM -0500, Scott Stark wrote:

I'm working with a java vm vendor that is developing a multi-tenancy jvm and is trying to leverage the libvirt framework for the domain configuration. Right now the java language binding leverages the libvirt c library for parsing the domain.xml file. What are the thoughts on adding a 'jvm' domain type?

It is an interesting idea. You can certainly view a multi-tenancy jvm as another type of virtualization / hypervisor, and from that POV it would seem relevant for libvirt. I guess from my POV the big unknown is just how well it would fit in with the APIs and XML description that libvirt currently defines. ie are the current libvirt APIs / XML too focused on virtualizing operating systems to be practical for interaction with the JVM capabilities

I believe there would need to be a jvm specific section in a separate namespace similar to the qemucmdline section.

This ties into my question above, about how it would fit in with the current XML. The current QEMU specific namespace is something that we consider to be *unsupported* in libvirt - it is just there as a "get out of jail free" card. The goal is that anything in the QEMU namespace will be mapped to real libvirt APIs / XML over time. So I wouldn't want to have a JVM driver where use of a custom namespace was a fundamental part of its usage. For it to be viable, a JVM driver needs to be useable with the standardized XML schema, and any JVM specific namespace would just be for temporary hacks/ edge cases that should rarely be used. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|