Thanks Eric! This was exactly what I was looking for.
On Fri, Dec 20, 2013 at 11:48 AM, Eric Blake <eblake@xxxxxxxxxx> wrote:
On 12/20/2013 11:45 AM, Mark Trinh wrote:No, they do not have to be in lockstep. libvirt.so communicates to a
> 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?
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).
The source code to virsh shows the APIs that we used; this is a good
>
>
> 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.
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
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
