Daniel P. Berrange wrote:
On Thu, Nov 15, 2007 at 11:49:17AM -0800, Robert Nelson wrote:
Hugh O. Brock wrote:
On Wed, Nov 14, 2007 at 11:50:47PM -0800, Robert Nelson wrote:
I've been trying to add support for additional para-virtual operating
systems (OpenSolaris and Debian) to virt-manager. There is no problem
getting the initial kernel and ramdisk, however there is no way to
specify the target disk node based on the OS or distro. Also some OS's
don't support the virtual frame buffer driver but there is no way to
prevent the XML for it being created.
I can't see how this could be done without doing some major
restructuring of the code and creating a new class to encapsulate all
the target specific information. Is there any plan on doing something
like this? If someone were to do it, are the changes likely to be
incorporated?
Hello Robert, thanks for your interest.
I'm not sure I understand what you mean by "specify the target disk
node based on the OS or distro"?
Virt-Manager names the target disknodes xvda, xvdb, etc. OpenSolaris
requires 0, 1, 2, etc.
I would have no problem with adding a checkbox to virt-manager that
would have the effect of passing the --nographics flag to virtinst if
you can determine a good place to do it. I don't think we want to
spend a whole ton of time creating a new class to take different PV
guest OSes into account, though. Having said that, have you looked at
the *Installer class family in virtinst? Is there a way we could
extend that to do what you need?
I'll take another look at the Installer class and see if it can be done
there.
In the virtinst/FullVirtGuest.py class, there is already a bunch of
OS specific metadata, eg what of mouse to use, apic/acpi/pae settings,
whether the installer is multi-stage reboots (eg Windows). I'd recommend
moving this metadata into virtinst/DistroManager and have a bunch of
methods in that module for querying distro specific metadata, from the
Installer class.
Dan.
And so we come full circle :-) If you combine that with the OS
specific derived classes of ImageStore you end up with something
similar to what I originally proposed.
|
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
