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): qume-kvm-0.10-16.fc11.i586 How reproducible: 100% 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 3. 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:
Seems like we should add a 'minimum recommended disk size' to the list of (os type, variant) metadata we maintain.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Since this isn't upstream yet, it's unlikely to be fixed in f13. Reassigning to rawhide.
Moving to upstream tracker
*** Bug 499763 has been marked as a duplicate of this bug. ***
*** Bug 863309 has been marked as a duplicate of this bug. ***
virtinst has been merged into virt-manager.git. Moving all virtinst bugs to the virt-manager component.
*** Bug 895434 has been marked as a duplicate of this bug. ***
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
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.
Also osinfo related, but is just a virt-manager patch: https://bugzilla.redhat.com/show_bug.cgi?id=1095323
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: http://www.redhat.com/archives/virt-tools-list/2014-May/msg00048.html
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.
(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
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