Re: Extensions to the libvirt Storage API

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

 



On 07/28/2010 01:24 PM, Daniel P. Berrange wrote:

>>>>
>>>>
>>>  We explicitly don't support external driver plugins in libvirt for a
>>>  couple of reasons
>>>
>>>    - We don't want to support use of closed source plugins
>>>    - We don't want to guarentee stability of any aspect of
>>>      libvirt's internal API
>>>
>>>  We would like to see support for the various vendor specific iSCSI
>>>  extensions to allow volume creation/deletion, but want that code to
>>>  be part of the libvirt codebase.
>>>
The APIs can also invoke standard snmpget/set methods to talk to the target.

All standard distributions ship with a net-snmp implementation.

Would an implementation of the APIs that invokes snmpset/gets be an amenable solution?


 Namespace clash ! The virDomainSnapshot APIs are per-hypervisor. They
 do snapshotting of the guest VM (including its storage).

 I was actually just talking about the storage backends though which
can do snapshots independently of any hypervisor. See the<backingstorage>
 element here:

http://libvirt.org/formatstorage.html#StorageVolBacking

 This is already implemented with the LVM pool doing LVM snapshots. We
 also use it for external qcow2 backing files.


There are certain benefits of allowing snapshots/backup to happen in the storage and thereby save CPU cycles. It becomes even more visible with large TB storage where in a simple qcow2 backup copy could take a long time.

--
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]