On Wed, Mar 14, 2007 at 11:59:57AM +0000, Richard W.M. Jones wrote:
> (1) is_pae_capable: host supports PAE? Uses Linux-specific /proc/cpuinfo
This is also arch specific - only relevant for i386/x86_64.
> (2) is_hvm_capable: host supports HVM & enabled in Xen? Uses
> Xen-specific /sys/hypervisor/properties/capabilities
The cpuinfo tells you whether the CPU supports particular
features. Whether the hypervisor actually uses these features
to provide HVM, or whether the BIOS even lets you use them is
not easy to figure out. So we need driver specific code in this
case - for Xen as described. For KVM we look for presence of
the /dev/kvm device node. As you say, this should really be
hidden away in libvirt rather than apps.
> (3) is_kqemu_capable: [Linux] kernel supports kqemu? Uses
> Linux-specific /dev/kqemu
> (4) is_kvm_capable: [Linux] kernel supports kvm? Uses Linux-specific
> /dev/kvm
This is really equivalent to the 'is_hvm_capable' check but for KVM.
> In virtinst/FullVirtGuest.py:
>
> (5) "emulator" and "loader" must be specified for Xen/QEMU and Xen
> guests respectively. They have architecture- and distro-specific paths
> which refer to files on the remote machine.
> In virtinst/ParaVirtGuest.py:
>
> (6) Uses "xm console" to connect to the console in the Xen case (but
> then this sort of paravirtualisation implies Xen).
This on the 'TODO' list to fix. In the 0.3.0 release of libvirt we now
have a 'virsh console' command which works with QEMU / KVM too, so we
can remove this Xen-ism now.
> In virtinst/DistroManager.py:
>
> (7) We download the kernel and boot.iso files, and download and modify
> the initrd file. [Comment: I'm not sure that capabilities can solve
> this, but it does need to be fixed properly for the remote case to work].
A tricky one with several possible answers:
- Have APIs for grabbing the kenel/initrd files in libvirt. Pure evil really
- Require use of PXE in remote case. QEMU/HVM does PXE now, and there is work
in progress to write a paravirt bootloader which does PXE too.
- Have a library of pre-defined install images, and a libvirt API to enumerate the
installs images and their kernel/initrd paths.
In light of the recent thread about OpenVZ support I'm now leaning towards the
latter because OpenVZ guest creation has the idea of OS images / templates as
a core requirement. Our current code which downloads the kernl/initrd every
single time is kindof wasteful. If we had a library of install kernels, we could
assume that in the remote case, the administrator has prepopulated it with valid
options. In the local cases, we could simply repuporse our downloading code as
a means to populate the image library.
> (11) Similarly, the "accelerate" checkbox is enabled only for type ==
> "QEMU". [Comment: Dan tells me that this requirement comes about
> because kqemu is sometimes unreliable, so users need a way to disable it].
It is actually KVM which is the bigger trouble - there's a frequent stream
of messages on kvm-devel from people whoi can install in plain QEMU but not
in KVM. So if we forced everyone to always use KVM we'd have alot of unhappy
people. This is really just an artifact of KVM being a very young project,
so I'd expect that in a year or so we could quite likely *always* use KVM
if its available & get rid of the checkbox.
> (12) Local media are required for FV installs. Also we use HAL to
> detect media inserted and removed. [Comment: Can be solved separately by
> abstracting storage].
>
> In the *.glade files:
>
> (13) The list of CPU architectures for qemu is hard-coded in the
> interface description file.
Indeed, that sucks.
> Other areas which are beyond the role of capabilities:
> * Remote console
Work in progress. Got a new VNC widget that supports Hextile for efficient
remote access, and TLS encryption & X509 auth.
> * Serial console
We need a way to expose the serial console over the network. All existing
programs I'm aware of are only really suitable for exposing console output
since they are clear-text network sockets. Since Xen serial console is
a real bi-directional channel we need good encrypted access, preferrably
without having to grant shell access to the host. Maybe we can do something
incredibly evil & layer it into the RFB VNC stream, or maybe we need a
real network daemon.
> * Saving images
Although we popup a file dialog letting the user choose where to save an image,
in reality they have no choice in the matter. SELinux mandates that it be under
/var/lib/xen/. I'm inclined to remove this flexibility from the UI and just
pick a sensisible directory for each HV. Or adjust the libvirt APIs for save
restore so that they work with a relative filename, as well as the existing
full qualified path.
> Guest architectures: Cartesian product or UI builder?
> -----------------------------------------------------
>
> Currently the list of guest architectures is a flat list, worst case 5
> entries long for Xen and 14 entries long for qemu. Presenting this in
> user interfaces could be challenging.
I think I'd like to avoid doing a plain meta-data driven UI for this because
it is really going to suck horribly. The user doesn't care about many of the
choices so we need to be intelligent about only presenting the choices which
really matter, and making the rest on their behalf. If they want to use the
full range of options, then there is virt-install - virt-manager should be a
much simpler UI dealing with the '95%' common case & ignoring the hairy 5%
that's left.
> Some proposed features may make translation challenging. For example
> qemu supports a whole list of machine types ("pc", "sun4m", etc.) and it
> would be nice for libvirt clients to be able to provide some sort of
> description for the user. It would not be wise to carry this
> description in the XML because it would not be possible to localise it.
I'm in two minds about this - in virt-manager I don't anticipate ever giving
the user the choice of machine types since this is an advanced niche case
which I doubt many people would use.
For virt-install I'd expect people would just want to use the explicit machine
types rather than a prettified & xlated string.
> To avoid all libvirt clients duplicating and maintaining lists of
> machine types and descriptions, it may be worth adding a call to the API
> along the lines of:
>
> virConnectGetMachineDescription (const char *machine_name,
> const char *lang);
> (where lang == NULL would mean to use the current language).
That's one option - or we could use XML regular l18n support to provide
all the different translations inline.
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|