[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API
From: |
Chris Lalancette |
Subject: |
Re: [libvirt] [Qemu-devel] Re: Libvirt debug API |
Date: |
Mon, 26 Apr 2010 10:25:46 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 |
On 04/26/2010 08:54 AM, Jamie Lokier wrote:
> All the features? The qemu API is quite large already (look at all
> the command line options and monitor commands). I'll be very
> surprised if libvirt provides all of it that obscure apps may use.
>
> I'm thinking of features which are relatively obscure but nonetheless
> useful to a small number of deployments. Probably not enough to
> justify the effort building data models, specifying the XML and remote
> protocol and so on in libvirt.
>
> (Unless that becomes so easily mapped to qemu's API that it's almost an
> automatic thing... Which sounds like QMP, doesn't it?)
>
> Is libvirt ever likely to go to the effort of providing all the
> easily-usable API, or hooks, for:
>
> - sending keys to a guest, driven by a timed host script?
>
> - rebooting the guest while switching between USB touchpad and
> mouse devices, because one of them is needed during an OS
> install and the other is needed after?
>
> - changing the amount of RAM available to the guest at the next
> reboot, for OS install needing more memory than run time, in a
> scripted fashion when building new VMs from install disk images?
>
> - switching the guest between qemu mode and kvm mode on the next
> guest reset, because qemu is faster for some things (VGA
> updates) and kvm is faster for other things, so the best choice
> depends on which app you need to run on that guest
>
> - pausing a VM, making a copy, and resuming it, so as to fork it
> into two VMs (literally fork)?
>
> - setting up the host network container and NAT IP forwarding, on
> demand as guests are stopped and started, so that it works in
> the above scenario despite clashing IP addresses?
>
> - running a copy of the same guest, or perhaps an entire OS
> install process (scripted), many times for different qemu and
> qemu-kvm versions, different BIOSes, and different
> almost-equivalent hardware emulations (i.e. different NIC types,
> SMP count, CPU features, disk controller type, AIO/cache type) -
> for testing guests and apps on them - with some paralellism?
>
> None of those, except perhaps the first, as what I think of as typical
> virtualisation workloads, and they all seem obscure things probably
> outside libvirt's remit. Probably not many users either :-)
>
> Yet you can do them all today with qemu and scripting the monitor, and
> it's getting easier with QMP.
In point of fact, you can also do some of them today more-or-less with libvirt
and some scripting. However, you are right, there are probably obscure features
that libvirt will *never* be able to entirely implement, either because they
don't fit into libvirt's world-view or because they are too obscure or difficult
to do.
However, Dan's point stands; for most features that most users want to use,
it is far better to spend effort creating a cross-hypervisor, long-term API than
to spend too much effort on individual hypervisor hacks.
<snip>
> I'm just raising my hand as a potential user who might like to monitor
> a bunch of active and inactive guests, remotely, see how much memory
> they report using, etc. launch VNC viewer from the GUI, even choose
> the target host based on load and migrate on demand, while also
> needing a fair bit of non-standardness and qemu-level scripting too.
>
> Imho, that probably comes under the heading of apps using pass-through
> or multiple QMP monitors, which use features that probably won't and
> probably shouldn't ever be handled by libvirt itself.
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with virtualization/qemu, we want
to steer them far clear of this API. That goes doubly true for application
developers; we want them to be able to use a stable, long-term API and
not have to worry about the nitty-gritty details of the monitor. It's that
latter group that we want to make sure doesn't use this API.
--
Chris Lalancette
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, (continued)
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Luiz Capitulino, 2010/04/12
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Anthony Liguori, 2010/04/22
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Avi Kivity, 2010/04/23
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Anthony Liguori, 2010/04/23
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Avi Kivity, 2010/04/23
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Daniel P. Berrange, 2010/04/23
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Jamie Lokier, 2010/04/26
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API,
Chris Lalancette <=
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Avi Kivity, 2010/04/26
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Daniel P. Berrange, 2010/04/26
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Anthony Liguori, 2010/04/26
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Daniel P. Berrange, 2010/04/26
- Re: [libvirt] [Qemu-devel] Re: Libvirt debug API, Anthony Liguori, 2010/04/26
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Anthony Liguori, 2010/04/23
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Avi Kivity, 2010/04/24
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Anthony Liguori, 2010/04/24
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Avi Kivity, 2010/04/25
- Re: [Qemu-devel] Re: [libvirt] Libvirt debug API, Anthony Liguori, 2010/04/25