Bug 1213410

Created attachment 1016383 [details]
virt1 log

(In reply to jas from comment #0)
> Created attachment 1016382 [details]
> engine log
> 
> I believe I'm following the instructions for installing a Windows 7 test VM
> from the ovirt quick start guide, yet it's not working.
> I create the VM, then when I go to "Run Once", select "Atttach Floppy
> [sysprep]" and "Attach CD", then click OK, the VM stops with an error:
> "Failed to run VM wintest".
> 
> engine log to be attached.
> virt1 vdsm log to be attached.
> virt1 log to be uploaded.

Hi,

please also attach virt1 supervdsm log

Created attachment 1016836 [details]
virt1 supervdsm log

Thanks Francesco.. I've attached the supervdsm log.

Could you please also post /var/log/audit.log?

Hi Fabian..

I assume you mean /var/log/audit/audit.log.  On engine? or on virt1?

Since audit.log doesn't seem to be specifically tied to date and time, its difficult to figure out exactly the relevant portion since my test was a few days ago, so I ran the test again.  On neither engine nor virt1 were there any lines added to /var/log/audit/audit.log.
(though as a side note, I can see a wholleee bunch of accesses from a Chinese IP address on type=USER LOGIN rport=50048 that end in terminal=? res=success"... I thought that node would be suitably firewalled from all external activity by default. hmph.)

(In reply to jas from comment #4)
> Thanks Francesco.. I've attached the supervdsm log.

Considering the provided vdsm.log, supervdsm.log and report from https://bugzilla.redhat.com/show_bug.cgi?id=1213410#c0 , looks like the image file is created correctly. The next suspect in line is selinux preventing the access to that image, hance the request for audit.log.

I have reinstalled my setup using ovirt CentOS 7.1 instead of nodes.  Previously I was using 3.5, now 3.5.1. The system did not complain when starting the Win 7 DVD with [sysprep] on floppy.  The problem may not exist in this setup any longer.   I wanted to complete the installation, run sysprep and report back, but I've run into an oddity - after the installation, rather than asking me for an account, there's an account "user" created, and I have no idea what the password is to login!  Is that included in sysprep setup!?  Did a ghost create an account while I wasn't looking??

(In reply to jas from comment #8)
> I have reinstalled my setup using ovirt CentOS 7.1 instead of nodes. 
> Previously I was using 3.5, now 3.5.1. The system did not complain when
> starting the Win 7 DVD with [sysprep] on floppy.  The problem may not exist
> in this setup any longer.   I wanted to complete the installation, run
> sysprep and report back, but I've run into an oddity - after the
> installation, rather than asking me for an account, there's an account
> "user" created, and I have no idea what the password is to login!  Is that
> included in sysprep setup!?  Did a ghost create an account while I wasn't
> looking??

hopefully not:)
The sysprep files hasn't changed for quite a while, they are in /etc/ovirt-engine/sysprep, corresponding to your VM's OS Type; you may have run it several times or something...try with fresh Win install

Actually, it seems sysprep files were moved from /etc/ovirt-engine/sysprep to /usr/share/ovirt-engine/conf/sysprep in the current versions.

I repeated the Windows 7sp1 install multiple times with the same "user" account being created that I could not access.  I then discovered through trial and error that when starting the VM for the install, I not only have to choose "Attach Floppy" with "[sysprep]", but I also have to go to "Initial Run" and specify an "admin password".  Now, the password for the default "user" is the admin password and I can access the system after the installation.

Why does ovirt actually let me even start a sysprep install without forcing me to specify an admin password if that's required?   Why do the instruction on ovirt site not specify this at all, I do not know. See here:

http://www.ovirt.org/How_to_create_a_Windows_7_Virtual_Machine

For me, the original problem is solved, but unfortunately, it's not clear how.  It was either the upgrade from 3.5 to 3.5.1, or the upgrade of my nodes to CentOS 7.1 hosts..  Either way, the problem still exists, but I can't replicate it at this point.

(In reply to jas from comment #10)

> For me, the original problem is solved, but unfortunately, it's not clear
> how.  It was either the upgrade from 3.5 to 3.5.1, or the upgrade of my
> nodes to CentOS 7.1 hosts..  Either way, the problem still exists, but I
> can't replicate it at this point.

I think the relevant part here is if we still have this issue on ovirt node,
because as per https://bugzilla.redhat.com/show_bug.cgi?id=1213410#c7 this is the only pending item.

Should we move this to node? or maybe selinux?

closing for https://bugzilla.redhat.com/show_bug.cgi?id=1213410#c10 after no activity.
please reopen if new evidence comes out.