Same with Ubuntu Server 15.04

Thanks for the report. For future reference I'd prefer if files were attached to bugzilla instead of google drive. VM XML can just be pasted.

Since there's a lot of moving parts here, please trying narrowing it down: first try virt-manager 1.2.1 and see if that makes a difference, creating the VM from scratch. If it's still not working, try an older qemu version like 2.3.X

I think there might be a lead here with --debug while creating the same "KVM-DevStack" VM based on Ubuntu Server 15.10 with "git checkout fe722b99cb386e7f4163f3515b66d69c41f097d2":

[Sat, 14 Nov 2015 12:26:16 virt-manager 13950] ERROR (inspection:157) qemu:///system:KVM-DevStack: exception while processing
Traceback (most recent call last):
  File "/home/actionmystique/Program-Files/Ubuntu/Virt-manager/git-virt-manager/virtManager/inspection.py", line 147, in _process_vms
    data = self._process(conn, vm)
  File "/home/actionmystique/Program-Files/Ubuntu/Virt-manager/git-virt-manager/virtManager/inspection.py", line 173, in _process
    roots = g.inspect_os()
  File "/usr/lib/python2.7/dist-packages/guestfs.py", line 4638, in inspect_os
    r = libguestfsmod.inspect_os (self._o)
RuntimeError: part_list: parted print: /dev/sda: Warning: The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes

I continue to go back in time to find a working commit, but it is a tedious task.

Also, I was able to trap the loop in the linux installer: it happens during "Detecting disk and all other hardware".

That error might be related but my guess it isn't.

You don't need to check every virt-manager commit; I mentioned v1.2.1, so just 'git checkout v1.2.1'. But I'm more interested in the qemu test. virt-manager really doesn't do much more than setup the qemu command line parameters via libvirt, so if a VM is misbehaving it's often a qemu issue

I've downgraded to the following versions, but the issue is still there:
- libvirt 1.2.19
- qemu 2.4.0
- virt-manager 1.2.1

Thanks to a "Ctrl-C" during the installer loop, I was able to capture a video of the trace; the screenshot cannot be enhanced - cf. attachment "Qemu trace"
You'll notice the "device not available". It seems that the virtio disk cannot be accessed.

I'm sure you'll be able to decipher at least some of this trace.

Also, I was able in the past (2015-09-18) to install an Ubuntu 15.04 server with libvirt 1.2.19 & qemu 2.4.50 (from the logs): do you know what 2.4.50 correspond to?

Created attachment 1094384 [details]
Qemu trace

I've tried with the following Qemu versions with the same negative result (alongside libvirt 1.2.19, libvirt-python 1.2.20 & virt-manager 1.2.1):
- 2.4.0
- 2.4.0.1
- 2.4.1
- 2.5.0 rc0

I'm stuck here. The only lead is the one proposed in comments 3 & 4: what is the  driver involved in the error message?

I confirm the discrepancy exposed in the previous error message.
On virt-manager "Choose storage volume" or any other storage related window, the sizes of all Linux-based VMs are all incorrect, but the sizes of all other VMs are OK: cf. "virt-manager storage-based windows" attachment.

Linux-based VMs:
--------------- 
ls-al
-rw-r----- 1 root root            1166475264 Oct 14 12:27 KVM-DevStack.qcow2
-rw-r----- 1 root root            1166475264 Oct 26 23:44 KVM-Ubuntu-Gnome-Server-15.04.qcow2
-rw-r----- 1 root root            1166475264 Oct 14 12:27 KVM-Ubuntu-Server-15.04.qcow2

Other VMs:
---------
-rwxrwx--- 1 root virtualization  3221946368 Jul 21 16:49 KVM-CSR-1000V-3.14.qcow2
-rwxrwx--- 1 root root           53695545344 Nov 13 16:19 KVM-Windows-10.qcow2

On virt-manager storage-based windows:
-------------------------------------
All linux-based VMs are seen as ~ 2362 MB when they are actually nearly half that size on disk.

I don't know which piece of software is responsible for that misleading information.

Created attachment 1094452 [details]
virt-manager storage-based windows

qemu X.Y.50 is the version number for qemu.git when it is between releases, but before rc0 versions come out.

The discrepancy you point on in comment #9 could be due to qcow2 (and other image formats) being sparse, that is capable of representing a large filesystem on to the guest, but only using the bare minimum disk space on the host until the guest has actually written to it. 'qemu-img info $path' will give a bit more info about the qcow2 specifics


Are you re-using disk images for the install, or creating a new disk image? Maybe something inside the existing disk image filesystem is confusing the ubuntu installer... it may explain the libguestfs error in the virt-manager logs too. So can you ensure the disk image is wiped out between install attempts? If that doesn't fix it, try allocating a raw disk image and see if that makes any difference

I've already tried to use new disk image at the beginning of each new try, but it doesn't change anything.
I tried to use other images, but no luck here either:
- different disk bus (SATA),
- different storage format (raw)

qemu-img info ./KVM-Ubuntu-Server-15.04.qcow2 
image: ./KVM-Ubuntu-Server-15.04.qcow2
file format: qcow2
virtual size: 2.2G (2361393152 bytes)
disk size: 1.1G
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16

OK, there is a difference between the virtual size & the actual disk size.

Regarding the error in comment #3 about the discrepancy related to the physical block size of only the newly created VM disk, when there is no such error for all other VM disks, including Ubuntu 15.04 server: it seems that it is directly linked to the "OS type/version" chosen during the VM creation. If I choose anything lower than Ubuntu 15.10 for Linux, there is no such error. It appears only with 15.10. There is an issue here.

However, I've tried to define another VM with Linux/Ubuntu 15.04 & Ubuntu 15.10 ISO, and I've experienced the same issue installing it.

Are you able to install a VM with the same ISO on your system?
Could you share the versions of the virt-manager sources & of each major dependency:
- libvirt
- libvirt-glib,
- libvirt-python,
- libosinfo.

Trying the create the same VM on a different host (Ubuntu Desktop 15.10) allowed me to have a full access to the error during the installation: cf. attachment "no disk drive was detected.txt"
"no disk drive was detected" error message shows up and a list of other types is shown, but virtio, SATA or IDE are not part of it, only some unusual disk drivers.

Created attachment 1095440 [details]
No disk drive was detected

I can not reproduce the issue with The VM install starts fine. Here's what I'm running:

- ubuntu-15.10-server-amd64.iso
- kernel 4.2.5-300.fc23.x86_64
- qemu-2.4.1-1.fc23
- libvirt-1.2.18.1-2.fc23.x86_64
- libvirt-glib-0.2.2-1.fc23.x86_64
- libvirt-python-1.2.18-1.fc23.x86_64
- virt-manager from git
- libosinfo from git


So, some ideas:
- Maybe it's a host kernel/kvm issue
- Check host dmesg to see if there's any KVM warnings that aren't there when running a working VM
- See if there's any qemu stderr messages in /var/log/libvirt/qemu/$vmname.log that aren't there for a working VM
- If you are compiling bits from source, see if you can get this working with your distro packages first, then slowly reintroduce manually built packages to see if you can identify the culprit



Let me give some advice WRT debugging these issues. This is all just my opinion

- host kernel virt issues can manifest in a few ways: qemu crashing, kernel traces on the host, guest hangs like you are seeing. however I'd say they are infrequent for normal virt usage, unless you are building kernels from git

- the guest kernel can have virt specific issues as well, though normally they are rare. what's more likely is you hit a general kernel or distro issue instead

- qemu regressions can _definitely_ affect VM behavior, but also appear as qemu startup error messages, and often qemu runtime crashes. really anything

- for how virt-manager uses it, libvirt-glib practically never has bugs... the bit of code we use from there is basically 'finished' and is rarely touched. and if they did, they wouldn't affect how the VM runs

- libvirt-python bugs usually manifest as error messages in virt-manager. basically python backtraces. I can't think of a single example that affected how a VM ran

- libvirt bugs can manifest in a lot of ways, but for virt-manager usage I'd say at least 80% of them bubble up as explicit error messages from libvirt API calls. the most common is failure starting up a VM, either because some validation check failed, or libvirt messed up the qemu command line and qemu threw an error. in these cases the VM never starts up. really much of what libvirt does is translating an XML document into a qemu command line, and wrapping API calls around it.

- virt-manager issues are mostly just python backtraces or malfunctioning UI.

- changes to virt-manager and libosinfo _can_ trigger issues inside the VM but really only if _we_generate_different_XML_for_the_new_VM.

- If you ever want to rule out virt-manager for an issue like this, compare the working XML with the new XML virt-manager is generating, and see if it's specifying any new devices. This also works for libvirt and there generated qemu commandlines, and sometimes XML since there might be a regression as far as what defaults it is fitting in.

- If you are hitting an issue _inside_ the VM, 90% of the time it's either an issue with the guest OS, qemu, or host kernel (if using KVM).

Thanks for your advices.
Comparing with your packages, we have differences with:
- kernel release: unless you can show me how to generate a signed vmlinuz on an EFI dual boot system without paying a fee to Microsoft, I won't be able to match your version (mine is 4.2.0)
- libvirt & libvirt-python 1.2.18 vs 1.2.19: matching your releases does not solve that issue
- same conclusion if I downgrade from qemu 2.50 rc0 to 2.4.1

So, it seems that the issue lies somewhere in the Linux kernel, or is due to an incompatibility between that kernel and some package.

I suggest you file a bug with your distro kernel then. Closing, but if it comes back to virt-manager feel free to reopen

It seems that this issue is CPU-related because I've just found the following workaround: with the CPU set as "host-passthrough" instead of "host-model", I am now able to install an Ubuntu server 15.10 VM with virt-manager :)
This reminds me of another current issue: https://bugzilla.redhat.com/show_bug.cgi?id=870071

BTW, it would be great to offer that "host-passthrough" choice in the drop-down menu.

Also, my CPU is a Intel 4700-MQ: http://www.notebookcheck.net/Intel-Core-i7-4700MQ-Notebook-Processor.92959.0.html

You can use host-passthrough in the virt-manager UI, just type the value explicitly in the CPU model box. We don't advertise it because it's not recommended by for libvirt usage presently

Just duping this to the host-model bug you reference

*** This bug has been marked as a duplicate of bug 870071 ***