[
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15693887#comment-15693887
]
ASF subversion and git services commented on CLOUDSTACK-8715:
-------------------------------------------------------------
Commit 2a5f37c1b10ba4e5acaf7fbb30ce0b016b04d082 in cloudstack's branch
refs/heads/master from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2a5f37c ]
CLOUDSTACK-8715: Add channel to Instances for Qemu Guest Agent
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 <[email protected]>
> Add support for qemu-guest-agent to libvirt provider
> ----------------------------------------------------
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
> Reporter: Sten Spans
> Assignee: Wido den Hollander
> Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite
> a lot of useful functionality, which can only be provided by having an agent
> on the VM. This includes things like freezing/thawing filesystems (for
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM
> virtual machines,:
> <channel type='unix'>
> <source mode='bind'/>
> <target type='virtio' name='org.qemu.guest_agent.0'/>
> </channel>
> This provides the communication channel between libvirt and the agent on the
> host. All in all a pretty simple change to LibvirtComputingResource.java /
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm
> template.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
