Bug 500320

Summary: RFE: Use libosinfo for improved OS metadata (minimum disk size, ram, ...)
Product: [Community] Virtualization Tools Reporter: Liam Li <lili>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aron.griffis, berrange, clalance, crobinso, gscrivan, itamar, jturner, petersen, rbalakri, veillard, virt-maint, yshao, zbitter
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1055588 (view as bug list) Environment:
Last Closed: 2014-09-21 18:13:50 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1055588, 1066293    

Description Liam Li 2009-05-12 05:18:22 EDT
Description of problem:

Create VM for vista the disk image should be more than 15G by default when we select OS Type as"Windows" and Version  "Microsoft Windows Vista"
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a VM for vista select OS type as "Windows" and version as"Microsoft Windows vista",forward to create a disk image.
2. the default disk image is 8G,but vista install needs at least 15G,if we create VM with the default setting,install will fail
Actual results:
if we are on customer's side,we should make sure they can install Guest os successfully by default setting

Expected results:

Additional info:
Comment 1 Daniel Berrange 2009-05-18 09:06:46 EDT
Seems like we should add a 'minimum recommended disk size' to the list of (os type, variant) metadata we maintain.
Comment 2 Bug Zapper 2010-03-15 08:36:28 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
Comment 4 Cole Robinson 2011-03-29 17:06:06 EDT
Since this isn't upstream yet, it's unlikely to be fixed in f13. Reassigning to rawhide.
Comment 5 Cole Robinson 2012-01-25 13:42:30 EST
Moving to upstream tracker
Comment 6 Cole Robinson 2012-01-25 13:42:41 EST
*** Bug 499763 has been marked as a duplicate of this bug. ***
Comment 7 Cole Robinson 2012-10-13 21:03:31 EDT
*** Bug 863309 has been marked as a duplicate of this bug. ***
Comment 8 Cole Robinson 2013-04-21 15:11:57 EDT
virtinst has been merged into virt-manager.git. Moving all virtinst bugs to the virt-manager component.
Comment 9 Cole Robinson 2013-07-11 15:46:13 EDT
*** Bug 895434 has been marked as a duplicate of this bug. ***
Comment 10 Cole Robinson 2014-02-02 12:23:36 EST
For the record, we are planning on integrating libosinfo soon, after the next virt-manager release

A few things floating on my todo list that we should investigate after the initial support is merged:

- create wizard autonaming: the new VM wizard will suggest VM names based on the chosen OS. We should make sure this works optimally with libosinfo, particularly takes advantage of the sub release tracking like RHEL6.1, RHEL6.2, etc.

- consider making virt-manager require the user to enter an OS if we can't detect one, since this is so important for optimal defaults.

- similarly virt-install should loudly warn if we can't detect an OS and the user didn't specify one.

- We should consider trying to call out to virt-inspector or use libguestfs APIs if available to detect the OS of an imported disk image. Not sure if we should do this in virt-install though.

- larger task of figuring out how we want to expose the automatic install stuff. virt-install should be easy enough, just add another option. virt-manager might be interesting though.

- think if there's any way to tweak the virt-manager 'new VM' OS list UI, since libosinfo is going to add a ton of options here and we don't want the combo boxes to have 500 options. I don't have any immediate ideas

- Track the guest OS in the libvirt XML. boxes already does this with libvirt's <metadata> support. I was always hoping we could get an official XML element for this stuff, that would just map to a libosinfo value, but libvirt wouldn't do anything explicit with it: https://bugzilla.redhat.com/show_bug.cgi?id=509164
Maybe use the metadata value if libvirt isn't new enough, but try to push that explicit value into upstream libvirt.

- When we track the guest OS in the XML, we can offer better defaults like virtio when adding a NIC to an existing VM. There's likely other options as well.

- Worth a consideration if there's any way we can detect if the CDROM media is a livecd, and possible offer different defaults in that case (like give the user an option to not 'install' the VM with a persistent disk, more ram, etc.). Not a priority though, not sure if libosinfo even gives fine grained info here.

- Same thing for 'cloud' images: fedora cloud images need cloud-init support, if we could detect that case from the disk image, we could automagically add a cloud-init disk so that users can actually log in to the OS: https://bugzilla.redhat.com/show_bug.cgi?id=981693
Comment 11 Cole Robinson 2014-03-25 14:10:39 EDT
I dumped a lot of other ideas here in Comment 10. Maybe we should split them up into their own bug reports. But until then we shouldn't close this.
Comment 12 Cole Robinson 2014-05-12 12:38:03 EDT
Also osinfo related, but is just a virt-manager patch:

Comment 13 Cole Robinson 2014-05-21 09:21:50 EDT
Launching the new VM wizard has a full second delay due to libosinfo initialization, we can probably push all that to a thread or do it lazily as I suggested here:

Comment 14 Daniel Berrange 2014-05-21 09:24:46 EDT
Can you file a bug against libosinfo to optimize this. I'd like to think we can also reduce that time penalty, even if that means we have to cache the data in a more efficient format than XML, and only reload XML files when they change.
Comment 15 Cole Robinson 2014-07-30 15:48:32 EDT
(In reply to Daniel Berrange from comment #14)
> Can you file a bug against libosinfo to optimize this. I'd like to think we
> can also reduce that time penalty, even if that means we have to cache the
> data in a more efficient format than XML, and only reload XML files when
> they change.

Forgot to respond at the time, but I did file that bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1099917
Comment 16 Cole Robinson 2014-09-21 18:13:50 EDT
I filed a couple bugs for the remaining big issues:

- tracking OS value in the XML: https://bugzilla.redhat.com/show_bug.cgi?id=1144895
- libosinfo install script support: https://bugzilla.redhat.com/show_bug.cgi?id=1144896

The rest of the remaining mini items I moved to my todo list and I'll try to get them done before the next release. So closing this issue since the main chunk of work is already upstream