[libvirt] virStorageVolCreateXMLFrom
I'd like to get a better understanding of the virStorageVolCreateXMLFrom api Its name and signature imply that it is a cloning operation that copies a volume from one location to another. Is this correct? Assuming that the answer is yes I have few other questions: Does it support remote copy of non-shared storage, e.g. from a http server? Is there any thought about adding digest validation check, e.g. with a md5 digest? Is copy-on-write cloning supported in this command? Kenneth Nagin
On Mon, Jun 22, 2009 at 09:59:00AM +0300, Kenneth Nagin wrote:
I'd like to get a better understanding of the virStorageVolCreateXMLFrom api Its name and signature imply that it is a cloning operation that copies a volume from one location to another. Is this correct?
Yes this method does a deep-copy of all the data, and can convert between disk formats at the same time (eg raw -> qcow2, or any qemu-img format).
Does it support remote copy of non-shared storage, e.g. from a http server?
It only supports copying within the same storage pool at this time, and we don't implement any storage pool based on http.
Is there any thought about adding digest validation check, e.g. with a md5 digest?
What would that do ? Or rather what semantics would you want from such a thing ? I rather hope that just reading & writing a local file would not result in data corruption.
Is copy-on-write cloning supported in this command?
No, you can create copy on write volumes using the <backingStore> element in the XML description http://libvirt.org/formatstorage.html#StorageVolBacking This is supported for LVM volumes, qcow, qcow2 and vmdk files at this time. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
"Daniel P. Berrange" <berrange@redhat.com> wrote on 22/06/2009 12:08:39:
On Mon, Jun 22, 2009 at 09:59:00AM +0300, Kenneth Nagin wrote:
I'd like to get a better understanding of the
virStorageVolCreateXMLFrom
api Its name and signature imply that it is a cloning operation that copies a volume from one location to another. Is this correct?
Yes this method does a deep-copy of all the data, and can convert between disk formats at the same time (eg raw -> qcow2, or any qemu-img format).
Does it support remote copy of non-shared storage, e.g. from a http server?
It only supports copying within the same storage pool at this time, and we don't implement any storage pool based on http.
Is there any thought about adding digest validation check, e.g. with a md5 digest?
What would that do ? Or rather what semantics would you want from such a thing ? I rather hope that just reading & writing a local file would not result in data corruption. My question was in the context of supporting remote copy (see above). The digest validation would only be necessary if you supported remote copy.
Is copy-on-write cloning supported in this command?
No, you can create copy on write volumes using the <backingStore> element in the XML description
http://libvirt.org/formatstorage.html#StorageVolBacking
This is supported for LVM volumes, qcow, qcow2 and vmdk files at this
time.
Regards, Daniel -- |: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Kenneth Nagin wrote:
"Daniel P. Berrange" <berrange@redhat.com> wrote on 22/06/2009 12:08:39:
On Mon, Jun 22, 2009 at 09:59:00AM +0300, Kenneth Nagin wrote:
I'd like to get a better understanding of the virStorageVolCreateXMLFrom api Its name and signature imply that it is a cloning operation that copies a volume from one location to another. Is this correct? Yes this method does a deep-copy of all the data, and can convert between disk formats at the same time (eg raw -> qcow2, or any qemu-img format).
Does it support remote copy of non-shared storage, e.g. from a http server? It only supports copying within the same storage pool at this time, and we don't implement any storage pool based on http.
Is there any thought about adding digest validation check, e.g. with a md5 digest? What would that do ? Or rather what semantics would you want from such a thing ? I rather hope that just reading & writing a local file would not result in data corruption. My question was in the context of supporting remote copy (see above). The digest validation would only be necessary if you supported remote copy.
CreateXMLFrom does not facilitate copying storage from one machine to another, it only works on a single connection/host. This host can be remote though. - Cole
participants (3)
-
Cole Robinson -
Daniel P. Berrange -
Kenneth Nagin