Re: [PATCH 7/7] kvmtool: Implementation for kvm tool driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2011年12月06日 22:55, Daniel P. Berrange wrote:
On Fri, Nov 11, 2011 at 07:57:06PM +0800, Osier Yang wrote:
Basically, the drivers is implemented by using kvm tool binary
currently, (see ./kvm help for more info).

Current implementation supports define/undefine, start/destroy/,
suspend/resume, connect to guest console via "virsh console",
and balloon memory with with "virsh setmem" (using ./kvm balloon
command). Also as it supports cgroup controllers "cpuacct", and
"memory", so some other commands like "schedinfo", "memtune" can
also work. Some other commands such as "domid", "domname", "dumpxml"
,"autostart", etc. are supported, as the driver is designed
as a "stateful" driver, those APIs just need to talk with libvirtd
simply.

As Native Linux KVM Tool is designed for both non-root and root users,
the driver is designed just like QEMU, supports two modes of the
connection:

     kvmtool:///system
     kvmtool+unix:///system

     kvmtool:///session
     kvmtool+unix:///session

An example of the domain XML (all the XMLs supported currently are
listed):

% virsh -c kvm:///system dumpxml kvm_test
<domain type='kvmtool'>
   <name>kvm_test</name>
   <uuid>88bf38f1-b6ab-cfa6-ab53-4b4c0993d894</uuid>
   <memory>524288</memory>
   <currentMemory>524288</currentMemory>
   <vcpu>1</vcpu>
   <os>
     <type arch='x86_64'>hvm</type>
     <kernel>/boot/bzImage</kernel>
     <boot dev='hd'/>
   </os>
   <clock offset='utc'/>
   <on_poweroff>destroy</on_poweroff>
   <on_reboot>restart</on_reboot>
   <on_crash>restart</on_crash>
   <devices>
     <emulator>/usr/bin/kvmtool</emulator>
     <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/linux-0.2.img'/>
       <target dev='vda' bus='virtio'/>
     </disk>
     <filesystem type='mount' accessmode='passthrough'>
       <source dir='/tmp'/>
       <target dir='/mnt'/>
     </filesystem>
     <console type='pty'>
       <target type='serial' port='0'/>
     </console>
     <memballoon model='virtio'/>
   </devices>
</domain>
---
  cfg.mk                       |    1 +
  daemon/Makefile.am           |    4 +
  daemon/libvirtd.c            |    7 +
  po/POTFILES.in               |    2 +
  src/Makefile.am              |   36 +-
  src/kvmtool/kvmtool_conf.c   |  130 ++
  src/kvmtool/kvmtool_conf.h   |   66 +
  src/kvmtool/kvmtool_driver.c | 3079 ++++++++++++++++++++++++++++++++++++++++++
  src/kvmtool/kvmtool_driver.h |   29 +

My main suggestion here would be to split up the kvmtool_driver.c
file into 3 parts as we did with the QEMU driver.

   kvmtool_driver.c   ->  Basic libvirt API glue
   kvmtool_command.c  ->  ARGV generation
   kvmtool_process.c  ->  KVMtool process start/stop/autostart/autodestroy


Agreed. As a early thinking, kvmtool might has APIs exposed in future,
how should we plan for it? A new driver just like libxl for XEN? or new
backend driver like what we do for xm, xend for XEN driver? Should we
consider the expansibility currently if we tend to use backend
drivers?

Regards,
Osier

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]