After upgrading from F7 kvm-65-15 to F10 kvm-74-10

After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Gerry Reno]

Hi,
  We had setup a number of VM's using KVM-65 running on F7 some time 
ago.  We just ocmpleted upgrading a number of hosts to F10 and with that 
came KVM-74-10.  We had some problems after that upgrade.  First, none 
of the VM's would start.  After digging around awhile we finally figured 
out that we had to once again 'chcon -t virt_image_t  path_to_image' as 
we had done back when we first setup the VM's.  But what is the proper 
procedure so that we don't lose the selinux attributes on these image 
files?  Shouldn't this be set by fedora's selinux-policy package?  Or by 
the kvm upgrade?  Next issue is that with KVM-74 we are having a lot of 
problems with the dreaded "TCP/IP VNC connection to hypervisor host has 
been refused or disconnected".  This has now happened to one of the VM's 
after it was shutdown and then we tried to Run it again and we haven't 
found a way to reconnect to it.  Also, another VM has this weird problem 
that when you run it, it looks like its running because the screen keeps 
changing size but all we see is a blank palette on the console page, no 
screen at all, but the thing is running.  How do we fix these things?

Regards,
Gerry

Re: After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Gerry Reno]

Gerry Reno wrote:
> Hi,
>  We had setup a number of VM's using KVM-65 running on F7 some time 
> ago.  We just ocmpleted upgrading a number of hosts to F10 and with 
> that came KVM-74-10.  We had some problems after that upgrade.  First, 
> none of the VM's would start.  After digging around awhile we finally 
> figured out that we had to once again 'chcon -t virt_image_t  
> path_to_image' as we had done back when we first setup the VM's.  But 
> what is the proper procedure so that we don't lose the selinux 
> attributes on these image files?  Shouldn't this be set by fedora's 
> selinux-policy package?  Or by the kvm upgrade?  Next issue is that 
> with KVM-74 we are having a lot of problems with the dreaded "TCP/IP 
> VNC connection to hypervisor host has been refused or disconnected".  
> This has now happened to one of the VM's after it was shutdown and 
> then we tried to Run it again and we haven't found a way to reconnect 
> to it.  Also, another VM has this weird problem that when you run it, 
> it looks like its running because the screen keeps changing size but 
> all we see is a blank palette on the console page, no screen at all, 
> but the thing is running.  How do we fix these things?
>
And we have a VM that when you start it says its Connecting to console 
for guest.  But the console message just stays like that and yet the 
machine completely boots up and we can log into it remotely in a 
terminal window.  We just cannot get a console screen.

We've tried putting the vnc on different ports 5901,5902,5903,etc.  But 
it doesn't help.   Again, what can we do to fix these problems?  Thanks.


Regards,
Gerry

Re: After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Gerry Reno]

Gerry Reno wrote:
> Gerry Reno wrote:
>> Hi,
>>  We had setup a number of VM's using KVM-65 running on F7 some time 
>> ago.  We just ocmpleted upgrading a number of hosts to F10 and with 
>> that came KVM-74-10.  We had some problems after that upgrade.  

>> we are having a lot of problems with the dreaded "TCP/IP VNC 
>> connection to hypervisor host has been refused or disconnected".  
>> This has now happened to one of the VM's after it was shutdown and 
>> then we tried to Run it again and we haven't found a way to reconnect 
>> to it.  
This is happening on a VM that was just anaconda upgraded to F9 and is 
on its first reboot.  But that reboot we cannot make happen because the 
VM refuses to run.

>> Also, another VM has this weird problem that when you run it, it 
>> looks like its running because the screen keeps changing size but all 
>> we see is a blank palette on the console page, no screen at all, but 
>> the thing is running.  How do we fix these things?
We kicked everyone off the VM's and rebooted the host and now we have 
access again to this VM. 


>>
> And we have a VM that when you start it says its Connecting to console 
> for guest.  But the console message just stays like that and yet the 
> machine completely boots up and we can log into it remotely in a 
> terminal window.  We just cannot get a console screen.
This also got corrected through a host reboot.


So the only problem I'm very concerned about at the moment is the VM 
that was at the point of first reboot after the successful completion of 
an F9 install.  Any suggestions as to how to get that VM running?


Regards,
Gerry

Re: After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Gerry Reno]

Gerry Reno wrote:
>
> So the only problem I'm very concerned about at the moment is the VM 
> that was at the point of first reboot after the successful completion 
> of an F9 install.  Any suggestions as to how to get that VM running?
>
>
In the virtmanager log we see this when we try to start this VM:
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (manager:427) VM 
MX_2 started
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (details:1042) Got 
timed retry
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (details:1094) 
Trying console login
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (details:1108) 
Graphics console configured at vnc://127.0.0.1:5901
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (details:1121) 
Starting connect process for 127.0.0.1 5901
[Sun, 29 Mar 2009 22:37:27 virt-manager 5707] DEBUG (details:1020) VNC 
initialized
[Sun, 29 Mar 2009 22:37:30 virt-manager 5707] DEBUG (details:1006) VNC 
disconnected
[Sun, 29 Mar 2009 22:37:30 virt-manager 5707] WARNING (details:1032) 
Retrying connection in 125 ms
[Sun, 29 Mar 2009 22:37:30 virt-manager 5707] ERROR (proxies:400) 
Introspect error on 
:1.5:/org/freedesktop/Hal/devices/net_06_d3_60_e9_70_0f: 
dbus.exceptions.DBusException: org.freedesktop.Hal.NoSuchDevice: No 
device with id /org/freedesktop/Hal/devices/net_06_d3_60_e9_70_0f
[Sun, 29 Mar 2009 22:37:30 virt-manager 5707] DEBUG (proxies:403) 
Executing introspect queue due to error
[Sun, 29 Mar 2009 22:37:30 virt-manager 5707] ERROR (connection:218) 
Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 214, 
in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/connection.py", line 278, in 
_net_phys_device_removed
    if objif.QueryCapability("net"):
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in 
__call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in 
__call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 630, 
in call_blocking
    message, timeout)


What does this mean?

Regards,
Gerry

Re: After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Ross McKay]

Gerry Reno wrote:

>[...]  After digging around awhile we finally figured 
>out that we had to once again 'chcon -t virt_image_t  path_to_image' as 
>we had done back when we first setup the VM's.  But what is the proper 
>procedure so that we don't lose the selinux attributes on these image 
>files?  [...]

You need to tell selinux about paths that you have custom selinux
contexts on if you want those contexts to persist. Something like
(assuming /path/to/image is a folder):

semanage fcontext -a -t virt_image_t "/path/to/image(/.*)?"

That will add them to the selinux database, and a restorecon will
preserve your changes (and reassert them if something else changes the
contexts of the files, or if you move a file from another place into
/path/to/image)
-- 
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin

Re: After upgrading from F7 kvm-65-15 to F10 kvm-74-10

[Gerry Reno]

Ross McKay wrote:
> Gerry Reno wrote:
>
>   
>> [...]  After digging around awhile we finally figured 
>> out that we had to once again 'chcon -t virt_image_t  path_to_image' as 
>> we had done back when we first setup the VM's.  But what is the proper 
>> procedure so that we don't lose the selinux attributes on these image 
>> files?  [...]
>>     
>
> You need to tell selinux about paths that you have custom selinux
> contexts on if you want those contexts to persist. Something like
> (assuming /path/to/image is a folder):
>
> semanage fcontext -a -t virt_image_t "/path/to/image(/.*)?"
>
> That will add them to the selinux database, and a restorecon will
> preserve your changes (and reassert them if something else changes the
> contexts of the files, or if you move a file from another place into
> /path/to/image)
>   
Ok, thanks.  I'll run that command on all the image file directory trees.

Now if we can just get some guidance on all this console connection 
craziness maybe we can get back to normal running.


Regards,
Gerry