mirror of
https://github.com/apache/cloudstack.git
synced 2025-10-26 08:42:29 +01:00
This commit adds a additional VirtIO channel with the name 'org.qemu.guest_agent.0' to all Instances. With the Qemu Guest Agent the Hypervisor gains more control over the Instance if these tools are present inside the Instance, for example: * Power control * Flushing filesystems * Fetching Network information In the future this should allow safer snapshots on KVM since we can instruct the Instance to flush the filesystems prior to snapshotting the disk. More information: http://wiki.qemu.org/Features/QAPI/GuestAgent Keep in mind that on Ubuntu AppArmor still needs to be disabled since the default AppArmor profile doesn't allow libvirt to write into /var/lib/libvirt/qemu This commit does not add any communication methods through API-calls, it merely adds the channel to the Instances and installs the Guest Agent in the SSVMs. With the addition of the Qemu Guest Agent channel a second channel appears in /dev on a SSVM as a VirtIO port. The order in which the ports are defined in the XML matters for the naming inside the SSVM VM and by not relying on /dev/vportXX but looking for a static name the SSVM still boots properly if the order in the XML definition is changed. A SSVM with both ports attached will have something like this: root@v-215-VM:~# ls -l /dev/virtio-ports total 0 lrwxrwxrwx 1 root root 11 May 13 21:41 org.qemu.guest_agent.0 -> ../vport0p2 lrwxrwxrwx 1 root root 11 May 13 21:41 v-215-VM.vport -> ../vport0p1 root@v-215-VM:~# ls -l /dev/vport* crw------- 1 root root 251, 1 May 13 21:41 /dev/vport0p1 crw------- 1 root root 251, 2 May 13 21:41 /dev/vport0p2 root@v-215-VM:~# In this case the SSVM port points to /dev/vport0p1, but if the order in the XML is different it might point to /dev/vport0p2 By looking for a portname with a pre-defined pattern in /dev/virtio-ports we do not rely on the order in the XML definition. Signed-off-by: Wido den Hollander <wido@widodh.nl>