On 03/04/2010 02:13 PM, Zachary Amsden wrote:
The biggest problem with virt-manager isn't virt-manager, it's that it
is trying to do a nearly intractable task. Because a qemu virtual
machine is not a machine at all, just a disk image without the proper
metadata to track the important properties of the machine, like what
revision of PCI chipset, how many disk controllers the thing is using,
what kind of graphics card, etc.
These are all basic things that are left completely undefined by
qemu's lack of a top-level configuration file, and it's an inexcusable
disgrace.
So virt-manager or any other management tool has the burden of
creating and maintaining a bunch of metadata around this workhorse
tool called qemu and invoking libvirt to figure out which set of
100,000 blasted command line options to pass on.
That's why it falls short of expectations at times, not because
virt-manager is crap, but because there is no well defined, well
designed infrastructure for it to manage and the ad-hoc solution here
is total crap.
And this is why we're doing QMP and qdev. It's long overdue
infrastructure. It's not just the problem that you describe though.
virt-manager is limited by what libvirt provides and today libvirt does
not expose nearly enough qemu features for virt-manager to even attempt
to solve the problem on it's own.
Regards,
Anthony Liguori
Zach
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
