Re: [PATCH libvirt-java 7/9] Use and implement virDomainMigrate2 instead of virDomainMigrate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Sat,  5 Jan 2013 12:48:24 +0100,
Wido den Hollander wrote:
> 
> This enables use a different XML for running the guest on the target host.

This sentence does not sound right. How about

This makes it possible to alter host-specific portions of the domain
XML that will be used on the destination host.

> Signed-off-by: Wido den Hollander <wido@xxxxxxxxx>
> ---
>  src/main/java/org/libvirt/Domain.java      |   54 ++++++++++++++++++++++++++--
>  src/main/java/org/libvirt/jna/Libvirt.java |    2 ++
>  2 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/src/main/java/org/libvirt/Domain.java b/src/main/java/org/libvirt/Domain.java
> index 932f56c..03afa0e 100644
> --- a/src/main/java/org/libvirt/Domain.java
> +++ b/src/main/java/org/libvirt/Domain.java
> @@ -760,6 +760,8 @@ public class Domain {
>       *
>       * @param dconn
>       *            destination host (a Connect object)
> +     * @param dxml
> +     *            (optional) XML config for launching guest on target
>       * @param flags
>       *            flags
>       * @param dname
> @@ -773,13 +775,61 @@ public class Domain {
>       *         scope of the destination connection (dconn).
>       * @throws LibvirtException
>       */
> -    public Domain migrate(Connect dconn, long flags, String dname, String uri, long bandwidth) throws LibvirtException {
> -        DomainPointer newPtr = libvirt.virDomainMigrate(VDP, dconn.VCP, new NativeLong(flags), dname, uri, new NativeLong(bandwidth));
> +    public Domain migrate(Connect dconn, long flags, String dxml, String dname, String uri, long bandwidth) throws LibvirtException {
> +        DomainPointer newPtr = libvirt.virDomainMigrate2(VDP, dconn.VCP, dxml, new NativeLong(flags), dname, uri, new NativeLong(bandwidth));
>          processError();
>          return new Domain(dconn, newPtr);
>      }
>  
>      /**
> +     * Migrate this domain object from its current host to the destination host
> +     * given by dconn (a connection to the destination host). Flags may be one
> +     * of more of the following: Domain.VIR_MIGRATE_LIVE Attempt a live
> +     * migration. If a hypervisor supports renaming domains during migration,
> +     * then you may set the dname parameter to the new name (otherwise it keeps
> +     * the same name). If this is not supported by the hypervisor, dname must be
> +     * NULL or else you will get an error. Since typically the two hypervisors
> +     * connect directly to each other in order to perform the migration, you may
> +     * need to specify a path from the source to the destination. This is the
> +     * purpose of the uri parameter.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. Uri should only
> +     * be specified if you want to migrate over a specific interface on the
> +     * remote host. For Qemu/KVM, the uri should be of the form
> +     * "tcp://hostname[:port]". This does not require TCP auth to be setup
> +     * between the connections, since migrate uses a straight TCP connection
> +     * (unless using the PEER2PEER flag, in which case URI should be a full
> +     * fledged libvirt URI). Refer also to driver documentation for the
> +     * particular URIs supported. If set to 0, libvirt will choose a suitable
> +     * default. Some hypervisors do not support this feature and will return an
> +     * error if bandwidth is not 0. To see which features are supported by the
> +     * current hypervisor, see Connect.getCapabilities,
> +     * /capabilities/host/migration_features. There are many limitations on
> +     * migration imposed by the underlying technology - for example it may not
> +     * be possible to migrate between different processors even with the same
> +     * architecture, or between different types of hypervisor.

Breaking this up into a few paragraphs would be nice.

Also, you've re-used the documentation of the old method for the new
method having an additional argument. It would be nice to add some
words about the new parameter. And while touching this, adding a few
paragraph separators would be a bonus.

> diff --git a/src/main/java/org/libvirt/jna/Libvirt.java b/src/main/java/org/libvirt/jna/Libvirt.java
> index 2bbc8c3..de2a262 100644
> --- a/src/main/java/org/libvirt/jna/Libvirt.java
> +++ b/src/main/java/org/libvirt/jna/Libvirt.java
> @@ -209,6 +209,8 @@ public interface Libvirt extends Library {
>      public int virDomainManagedSaveRemove(DomainPointer virDomainPtr, int flags);
>      public DomainPointer virDomainMigrate(DomainPointer virDomainPtr, ConnectionPointer virConnectPtr,
>              NativeLong flags, String dname, String uri, NativeLong bandwidth);
> +    public DomainPointer virDomainMigrate2(DomainPointer virDomainPtr, ConnectionPointer virConnectPtr,
> +            String dxml, NativeLong flags, String dname, String uri, NativeLong bandwidth);

Again, please drop the public modifier.

Since we're no longer using virDomainMigrate, we might just as well
remove it from the JNA interface altogether.

Claudio
-- 
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>

Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]