libvirt users - Dec 2013 - Re: blockcopy for libvirt and version compatibility

I'm currently running:
virsh --version
1.0.2

libvirtd --version
libvirtd (libvirt) 1.0.2

I have a couple questions.

1. Can I upgrade my libvirt.so version to use with an older libvirtd?  In
other words, does the versions of libvirt and libvirtd need to be in lock
step?


2. I'm able to use virsh blockcopy, but I want to do it programmatically
via C.  I looked through the API and was not able to see any references to
that.  I did see mention of virDomainBlockCopy on the TIP of the git
repository, but no other references to it.

How do I run virsh blockcopy via a C function?

On 12/20/2013 11:45 AM, Mark Trinh wrote:
> I'm currently running:
> virsh --version
> 1.0.2
> 
> libvirtd --version
> libvirtd (libvirt) 1.0.2
> 
> I have a couple questions.
> 
> 1. Can I upgrade my libvirt.so version to use with an older libvirtd?  In
> other words, does the versions of libvirt and libvirtd need to be in lock
> step?
No, they do not have to be in lockstep.  libvirt.so communicates to a
local libvirtd the same way it communicates to a remote machine, and we
took great care in the design to ensure that things error out nicely if
the libvirt.so client is newer than the remote server; conversely, if
the client is older, the changes have always been back-compat so that a
newer server will always talk to the client correctly (although the
client being older means that you can't take full advantage of the server).
> 
> 
> 2. I'm able to use virsh blockcopy, but I want to do it
programmatically
> via C.  I looked through the API and was not able to see any references to
> that.  I did see mention of virDomainBlockCopy on the TIP of the git
> repository, but no other references to it.
The source code to virsh shows the APIs that we used; this is a good
starting point for any other C binding, and also for any other language
binding if you can map the C bindings over to your language bindings.
In particular, tools/virsh-domain.c:cmdBlockCopy() is currently
implemented atop the virDomainBlockRebase() API call with the
VIR_DOMAIN_BLOCK_REBASE_COPY flag (but the door is open to also
implement it atop a newer more-powerful virDomainBlockCopy() once we
start targetting some of qemu 1.7 or 2.0's newer features).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Thanks Eric!  This was exactly what I was looking for.


On Fri, Dec 20, 2013 at 11:48 AM, Eric Blake <eblake@redhat.com> wrote:
> On 12/20/2013 11:45 AM, Mark Trinh wrote:
> > I'm currently running:
> > virsh --version
> > 1.0.2
> >
> > libvirtd --version
> > libvirtd (libvirt) 1.0.2
> >
> > I have a couple questions.
> >
> > 1. Can I upgrade my libvirt.so version to use with an older libvirtd? 
In
> > other words, does the versions of libvirt and libvirtd need to be in
lock
> > step?
>
> No, they do not have to be in lockstep.  libvirt.so communicates to a
> local libvirtd the same way it communicates to a remote machine, and we
> took great care in the design to ensure that things error out nicely if
> the libvirt.so client is newer than the remote server; conversely, if
> the client is older, the changes have always been back-compat so that a
> newer server will always talk to the client correctly (although the
> client being older means that you can't take full advantage of the
server).
>
> >
> >
> > 2. I'm able to use virsh blockcopy, but I want to do it
programmatically
> > via C.  I looked through the API and was not able to see any
references
> to
> > that.  I did see mention of virDomainBlockCopy on the TIP of the git
> > repository, but no other references to it.
>
> The source code to virsh shows the APIs that we used; this is a good
> starting point for any other C binding, and also for any other language
> binding if you can map the C bindings over to your language bindings.
> In particular, tools/virsh-domain.c:cmdBlockCopy() is currently
> implemented atop the virDomainBlockRebase() API call with the
> VIR_DOMAIN_BLOCK_REBASE_COPY flag (but the door is open to also
> implement it atop a newer more-powerful virDomainBlockCopy() once we
> start targetting some of qemu 1.7 or 2.0's newer features).
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>