Struct libvirt_rpc::async::DomainOperations

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

Operations on libvirt domains

Methods

impl<'a> DomainOperations<'a>

fn list(
    &self,
    flags: ListAllDomainsFlags
) -> BoxFuture<Vec<Domain>, LibvirtError>

Collect a possibly-filtered list of all domains, and return an allocated array of information for each.

fn lookup_by_uuid(&self, uuid: &Uuid) -> BoxFuture<Domain, LibvirtError>

Lookup a domain on the given hypervisor based on its UUID.

fn register_event(
    &self,
    dom: &Domain,
    event: i32
) -> BoxFuture<EventStream<DomainEvent>, LibvirtError>

fn start(
    &self,
    dom: Domain,
    flags: DomainCreateFlags
) -> BoxFuture<Domain, LibvirtError>

Launch a defined domain. If the call succeeds the domain moves from the defined to the running domains pools.

fn destroy(
    &self,
    dom: Domain,
    flags: DomainDestroyFlags
) -> BoxFuture<(), LibvirtError>

Destroy the domain object. The running instance is shutdown if not down already and all resources used by it are given back to the hypervisor.

fn define(&self, xml: &str) -> BoxFuture<Domain, LibvirtError>

Defines a domain, but does not start it. This definition is persistent, until explicitly undefined with virDomainUndefine(). A previous definition for this domain would be overridden if it already exists.

fn undefine(&self, dom: Domain) -> BoxFuture<(), LibvirtError>

Undefine a domain. If the domain is running, it's converted to transient domain, without stopping it. If the domain is inactive, the domain configuration is removed.

fn shutdown(&self, dom: &Domain) -> BoxFuture<(), LibvirtError>

Shutdown a domain, the domain object is still usable thereafter, but the domain OS is being stopped. Note that the guest OS may ignore the request.

Additionally, the hypervisor may check and support the domain 'on_poweroff' XML setting resulting in a domain that reboots instead of shutting down. For guests that react to a shutdown request, the differences from virDomainDestroy() are that the guests disk storage will be in a stable state rather than having the (virtual) power cord pulled, and this command returns as soon as the shutdown request is issued rather than blocking until the guest is no longer running.

fn reboot(&self, dom: &Domain) -> BoxFuture<(), LibvirtError>

Reboot a domain, the domain object is still usable thereafter, but the domain OS is being stopped for a restart. Note that the guest OS may ignore the request.

Additionally, the hypervisor may check and support the domain 'on_reboot' XML setting resulting in a domain that shuts down instead of rebooting.

fn reset(&self, dom: &Domain) -> BoxFuture<(), LibvirtError>

Reset a domain immediately without any guest OS shutdown. Reset emulates the power reset button on a machine, where all hardware sees the RST line set and reinitializes internal state.

Note that there is a risk of data loss caused by reset without any guest OS shutdown.

fn screenshot(
    &self,
    dom: &Domain,
    screen: u32
) -> BoxFuture<(Option<String>, LibvirtStream<BytesMut>), LibvirtError>

Take a screenshot of current domain console as a stream. The image format is hypervisor specific. Moreover, some hypervisors supports multiple displays per domain. These can be distinguished by @screen argument.

This call sets up a stream; subsequent use of stream API is necessary to transfer actual data, determine how much data is successfully transferred, and detect any errors.

The screen ID is the sequential number of screen. In case of multiple graphics cards, heads are enumerated before devices, e.g. having two graphics cards, both with four heads, screen ID 5 addresses the second head on the second card.