FAQ

Snooze is a scalable, autonomic, and energy-aware virtual machine (VM) management framework. Its name stands for “take a nap” and was selected to emphasize the energy management features of the system. Snooze is one of the core results of Eugen Feller`s PhD thesis supervised by Christine Morin at the INRIA MYRIADS project-team.

Security aspects are currently not addressed by the system. Particularly, no user authentication and data communication encryption schemes are implemented by the system components (i.e. GL, GM, and LC).

Currently only bridged networking is supported. Particularly, Snooze can be given a subnet from which it will automatically assign IP addresses to VMs. The assigned IP address will be encoded into the VM MAC address and a contextualization script inside the VM will configure the VM networking interface by decoding the assigned IP from the VM MAC address upon boot up.

VM images must to be created by the user prior submission and placed on a stable storage which is visible by all the local controllers (LCs). For the time being the system was tested to work with the Network File System (NFS).

Resource monitoring information is obtained through the libvirt library. However, alternative monitoring frameworks (e.g. Ganglia) can be integrated by implementing the appropriate interface.

Currently resource (i.e. CPU, memory, network Rx, network Tx) monitoring information is stored in-memory. However, alternative repositories (e.g. Apache Cassandra, MongoDB, MySQL, etc.) can be integrated by implementing the appropriate repository interface.

Snooze is not limited to any particular hypervisor. However, for now it was tested with KVM only.

Snooze high availability mechanisms rely on native multicast support. Assumed that a global VLAN can be configured between the distributed locations the system should work. However, it was not tested in such a scenario yet. Alternatively either multicast must be enabled on the routers or a multicast overlay has to be provided. Note that even if the deployment could work most of the mechanisms relying on live migration would most likely fail as no reconfiguration (e.g. IP switch) logic is currently implemented. Finally heterogeneity of resources and potentially other problems would arise which are currently not handled.

Currently no EC2 interface is exposed.

Please refer to the API description for more details.

Currently the Snooze placement algorithms are not location constraints aware. However, given that the appropriate algorithms can be implemented such constraints could be supported

There can be several reasons for this message to occur: (1) Did you set the bridge name correctly in your VM template?; (2) Did you assign unique names and UUIDs to all of your VMs?; (3) Did you mount NFS storage on all LCs?; (4) Do you have libvirtd configured and running on all LCs?