Struct libvirt_rpc::async::VolumeOperations

pub struct VolumeOperations<'a> { /* fields omitted */ }

Operations on libvirt storage volumes

Methods

impl<'a> VolumeOperations<'a>

fn create(
    &self,
    pool: &StoragePool,
    xml: &str,
    flags: StorageVolCreateXmlFlags
) -> LibvirtFuture<Volume>

Create a storage volume within a pool based on an XML description. Not all pools support creation of volumes.

fn create_from(
    &self,
    pool: &StoragePool,
    xml: &str,
    vol: &Volume,
    flags: StorageVolCreateXmlFlags
) -> LibvirtFuture<Volume>

Create a storage volume in the parent pool, using the 'clonevol' volume as input. Information for the new volume (name, perms) are passed via a typical volume XML description.

fn delete(&self, vol: Volume) -> LibvirtFuture<()>

Delete the storage volume from the pool

fn wipe(&self, vol: &Volume) -> LibvirtFuture<()>

Ensure data previously on a volume is not accessible to future reads. The data to be wiped may include the format and possibly size information, so non-raw images might become raw with a different size. It is storage backend dependent whether the format and size information is regenerated once the initial volume wipe is completed. Depending on the actual volume representation, this call may not overwrite the physical location of the volume. For instance, files stored journaled, log structured, copy-on-write, versioned, and network file systems are known to be problematic.

fn lookup_by_name(
    &self,
    pool: &StoragePool,
    name: &str
) -> LibvirtFuture<Volume>

fn resize(
    &self,
    vol: &Volume,
    capacity: u64,
    flags: StorageVolResizeFlags
) -> LibvirtFuture<()>

Changes the capacity of the storage volume @vol to @capacity. The operation will fail if the new capacity requires allocation that would exceed the remaining free space in the parent pool. The contents of the new capacity will appear as all zero bytes. The capacity value will be rounded to the granularity supported by the hypervisor.

Normally, the operation will attempt to affect capacity with a minimum impact on allocation (that is, the default operation favors a sparse resize). If @flags contains VIR_STORAGE_VOL_RESIZE_ALLOCATE, then the operation will ensure that allocation is sufficient for the new capacity; this may make the operation take noticeably longer. Normally, the operation treats @capacity as the new size in bytes; but if @flags contains VIR_STORAGE_VOL_RESIZE_DELTA, then @capacity represents the size difference to add to the current size. It is up to the storage pool implementation whether unaligned requests are rounded up to the next valid boundary, or rejected.

Normally, this operation should only be used to enlarge capacity; but if @flags contains VIR_STORAGE_VOL_RESIZE_SHRINK, it is possible to attempt a reduction in capacity even though it might cause data loss. If VIR_STORAGE_VOL_RESIZE_DELTA is also present, then @capacity is subtracted from the current size; without it, @capacity represents the absolute new size regardless of whether it is larger or smaller than the current size.

fn download(
    &self,
    vol: &Volume,
    offset: u64,
    length: u64
) -> LibvirtFuture<LibvirtStream>

Download the content of the volume as a stream. If @length is zero, then the remaining contents of the volume after @offset will be downloaded. This call sets up an asynchronous stream; subsequent use of stream APIs is necessary to transfer the actual data, determine how much data is successfully transferred, and detect any errors. The results will be unpredictable if another active stream is writing to the storage volume.

fn upload(
    &self,
    vol: &Volume,
    offset: u64,
    length: u64
) -> LibvirtFuture<LibvirtSink>

Upload new content to the volume from a stream. This call will fail if @offset + @length exceeds the size of the volume. Otherwise, if @length is non-zero, an error will be raised if an attempt is made to upload greater than @length bytes of data.

This call sets up an asynchronous stream; subsequent use of stream APIs is necessary to transfer the actual data, determine how much data is successfully transferred, and detect any errors. The results will be unpredictable if another active stream is writing to the storage volume.

When the data stream is closed whether the upload is successful or not the target storage pool will be refreshed to reflect pool and volume changes as a result of the upload. Depending on the target volume storage backend and the source stream type for a successful upload, the target volume may take on the characteristics from the source stream such as format type, capacity, and allocation.

fn upload_with<F, R>(
    &self,
    vol: &Volume,
    offset: u64,
    length: u64,
    uploader: F
) -> Box<Future<Item = (), Error = R::Error>> where
    F: FnOnce(LibvirtSink) -> R + Send + 'static,
    R: IntoFuture + 'static,
    R::Future: Send + 'static,
    R::Item: Send + 'static,
    R::Error: Send + 'static + From<LibvirtError>, 

Same as upload but accepts callback and returns upload result