- Users - oVirt List Archives

VM time offset
by Aslam, Usman 10 Aug '15

10 Aug '15

Hi guys, I'm having an issue where the VMs do not keep correct time upon reboot. The clock is always off by ~4 hours. I've checked and time and time zone on engine/host nodes is correct. Correct time zone is specified in the ovirt vm configuration as well. The VM in question is a clean CentOS 7 install. It did not have NTP enabled. I've tried setting it up with a local server and no dice. Upon reboot it always gets messed up. [root@xyz-dev ~]# date Fri Aug 7 17:18:09 EDT 2015 [root@xyz-dev ~]# reboot Connection to sso-dev closed by remote host. [root@xyz-dev ~]# date Fri Aug 7 13:20:47 EDT 2015 [root@xyz-dev ~]# ntpdate ntp1.xyz.domain.org 7 Aug 17:21:05 ntpdate[2151]: step time server 130.64.25.6 offset 14410.388931 sec Thanks, --Usman

3 2

[ATN] LDAP Users please read
by Alon Bar-Lev 10 Aug '15

10 Aug '15

Hello LDAP Users, If you migrated from 3.4 or if you used engine-managed-domains to add LDAP support into engine - this message is for you. In 3.5 we introduced a new LDAP provider[1][2], it is superset of the previous implementation, highlights includes: * Better response times. * Simplicity, Use of LDAP protocol only - kerberos is no longer needed. * More LDAP implementations are supported. * Flexible configuration, can be customized on site to support special setups. * Supportability, better logs and feedbacks to enable remote support. * Variety of fallback policies, examples: srvrecord, failover, round-robin and more. * Active Directory: supports multiple domain in forest. In 3.5 the previous LDAP provider is marked as legacy, users' issues will be resolved by migration to the new provider. Upgrade to 4.0 will not be possible if legacy provider is being used. The new provider is working without any issue for quite some time, we would like to eliminate the remaining usage of the legacy provider as soon as possible. A tool was created[3] to automate the process, it should perform everything in safe and automatic process, while enables customization if such required. The one prerequisite that we could not automate easily is obtaining the CA certificate used by the LDAP server to communicate using SSL/TLS, you should acquire this manually and provide it as parameter. We (Ondra CCed and I) will help anyone that is experiencing issues with the process, please do not delay migration to the point it becomes emergency. Let's define a virtual goal -- in 1 month no legacy LDAP usage anywhere. Regards, Alon Bar-Lev. [1] http://www.ovirt.org/Features/AAA [2] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blo… [3] https://github.com/machacekondra/ovirt-engine-kerbldap-migration/releases

6 11

Hosted Engine on SAS storage array
by Cristian Mammoli 10 Aug '15

10 Aug '15

I see oVirt 3.6 support HE on fibre channel, what if I have a SAS SAN? Is it supported as well?

2 2

Partition type
by Robert Fitzpatrick 10 Aug '15

10 Aug '15

I am brand new to Ovirt looking to migrate some virtual machines now on a KVM server and wanted to get some advice. Setting up my first CentOS 7 server following this document to have a self-hosted engine and storage... http://community.redhat.com/blog/2014/10/up-and-running-with-ovirt-3-5/ I've never used GlusterFS either and my question is what benefits it provides, why this doc suggests using it and how it could provide redundancy. The server has 4 SSD drives and a RAID controller, but is that beneficial and would using LVM be any benefit to store the partitions/bricks? Thanks for any advice. -- Robert

1 0

is it possible to change IOS and Export domain?
by Will K 10 Aug '15

10 Aug '15

------=_Part_1339180_164855655.1439083930612 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable hi, I have oVirt 3.3.3-2.el6 on a 2-node setup. =C2=A0Node1 has an ISO domain t= hrough NFS while node2 has a NFS export domain. =C2=A0 It does't sound right after extensive usage on this setup. I would like to = change them to an export on another NFS server. =C2=A0On the overt GUI, I'm= not allowed to change the ISO and the NFS domain. =C2=A0I'm allowed to add= another "Data/GlusterFS" domain. Please let me know if it is possible to make changes to the ISO and NFS dom= ain. ThanksWill ------=_Part_1339180_164855655.1439083930612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:16px"><div id=3D"yui_3_16_0_1_1439066928785_27514">hi,</div><div id= =3D"yui_3_16_0_1_1439066928785_27514"><br></div><div id=3D"yui_3_16_0_1_143= 9066928785_27514" dir=3D"ltr">I have oVirt 3.3.3-2.el6 on a 2-node setup. &= nbsp;Node1 has an ISO domain through NFS while node2 has a NFS export domai= n.  </div><div id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr"><br= ></div><div id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr">It does't s= ound right after extensive usage on this setup. I would like to change them= to an export on another NFS server.  On the overt GUI, I'm not allowe= d to change the ISO and the NFS domain.  I'm allowed to add another "D= ata/GlusterFS" domain.</div><div id=3D"yui_3_16_0_1_1439066928785_27514" di= r=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr= ">Please let me know if it is possible to make changes to the ISO and NFS d= omain.</div><div id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr"><br></= div><div id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr">Thanks</div><d= iv id=3D"yui_3_16_0_1_1439066928785_27514" dir=3D"ltr">Will</div></div></bo= dy></html> ------=_Part_1339180_164855655.1439083930612--

3 2

Invitation: [3.6 deep dive] - ceph-cinder integration @ Wed 2015-08-12 16:00 - 17:00 (bazulay@redhat.com)
by Barak Azulay 09 Aug '15

09 Aug '15

You have been invited to the following event. Title: [3.6 deep dive] - ceph-cinder integration Abstract: Ceph is a storage platform designed to present object, block, and file storage from a single distributed computer cluster.The data replicated with Ceph, making it fault tolerant and also scalable to the exabyte level. In this deep dive we'll cover Ceph Storage with oVirt : - What it is - How it works (engine vdsm ... qemu) - Obstacles we have encountered in the process and how we managed solve them. - Demo - Future plans Feature page: http://www.ovirt.org/Features/Cinder_Integration Hangout link: https://plus.google.com/events/c8e22pbk3fii0k8o86b0qao2ut0 youtube link: https://www.youtube.com/watch?v=elEkGfjLITs When: Wed 2015-08-12 16:00 - 17:00 Jerusalem Where: https://www.youtube.com/watch?v=elEkGfjLITs Calendar: bazulay(a)redhat.com Who: * Barak Azulay - organizer * mlipchuk(a)redhat.com * amureini(a)redhat.com * iheim(a)redhat.com * users(a)ovirt.org * devel(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=b3BhcGk0MG8zbjJwZ2lkb… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account users(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Invitation: [3.6 deep dive] - orchestrate pvresize across hosts @ Tue 2015-08-11 16:00 - 16:45 (bazulay@redhat.com)
by Barak Azulay 09 Aug '15

09 Aug '15

You have been invited to the following event. Title: [3.6 deep dive] - orchestrate pvresize across hosts Abstract: Users need the ability to increase storage space available in oVirt storage data domains (ISCSI & FC) without increasing the number of LUNs presented to it. Feature Page: http://www.ovirt.org/Features/LUN_Resize Hangout link : https://plus.google.com/events/c0dibhieipgo87n6iefs48oddv8 youtube link: https://www.youtube.com/watch?v=VxvurM-8n5s When: Tue 2015-08-11 16:00 - 16:45 Jerusalem Where: https://www.youtube.com/watch?v=VxvurM-8n5s Calendar: bazulay(a)redhat.com Who: * Barak Azulay - organizer * frolland(a)redhat.com * amureini(a)redhat.com * iheim(a)redhat.com * users(a)ovirt.org * devel(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NHQxaW43M2l2cmlpZzM0b… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account users(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Failed to Reconstruct Master Domain for Data Center
by Will K 09 Aug '15

09 Aug '15

------=_Part_1293889_1273479607.1439071641695 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Yes, I got this failed to active master storage domain issue. =C2=A0I'm sor= t of not sure where to start after a few attempts and many google results. = Is a good lead on how to troubleshoot this master storage failed to start i= ssue? I have a 2 node ovirt setup. It is a simple setup with GlusterFS with =C2= =A0one volume only. Both nodes were put to "maintenance mode" before reboot= . =C2=A0After reboot, I checked the followings were all up:vdsmd, ovirt-eng= ine,=C2=A0ovirt-websocket-proxy, nfs, nfslock, glusterd,=C2=A0glusterfsd I can reach to both nodes and I can activate them in overt. however, the ma= ster storage can't be activated. I tried to start with just node1. It worked fine and storage domain was up.= =C2=A0But once I booted up and activated node2, the NFS export domain just= fails followed by the Master domain failure.=C2=A0 Any suggestion where to start? Will ------=_Part_1293889_1273479607.1439071641695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:16px"><div id=3D"yui_3_16_0_1_1439066928785_9170">Hi all,</div><div= id=3D"yui_3_16_0_1_1439066928785_9037"><br></div><div id=3D"yui_3_16_0_1_1= 439066928785_9026" dir=3D"ltr">Yes, I got this failed to active master stor= age domain issue.  I'm sort of not sure where to start after a few att= empts and many google results. Is a good lead on how to troubleshoot this m= aster storage failed to start issue?</div><div id=3D"yui_3_16_0_1_143906692= 8785_9026" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439066928785_9026= " dir=3D"ltr">I have a 2 node ovirt setup. It is a simple setup with Gluste= rFS with  one volume only. Both nodes were put to "maintenance mode" b= efore reboot.  After reboot, I checked the followings were all up:</di= v><div id=3D"yui_3_16_0_1_1439066928785_9026" dir=3D"ltr" class=3D"">vdsmd,= ovirt-engine, ovirt-websocket-proxy, nfs, nfslock, glusterd, glu= sterfsd</div><div id=3D"yui_3_16_0_1_1439066928785_9026" dir=3D"ltr" class= =3D""><br></div><div id=3D"yui_3_16_0_1_1439066928785_9026" dir=3D"ltr" cla= ss=3D"">I can reach to both nodes and I can activate them in overt. however= , the master storage can't be activated.<br></div><div id=3D"yui_3_16_0_1_1= 439066928785_9026" dir=3D"ltr" class=3D""><br></div><div id=3D"yui_3_16_0_1= _1439066928785_9026" dir=3D"ltr" class=3D"">I tried to start with just node= 1. It worked fine and storage domain was up.  But once I booted up and= activated node2, the NFS export domain just fails followed by the Master d= omain failure. </div><div id=3D"yui_3_16_0_1_1439066928785_9026" dir= =3D"ltr" class=3D""><br></div><div id=3D"yui_3_16_0_1_1439066928785_9026" d= ir=3D"ltr" class=3D"">Any suggestion where to start?</div><div id=3D"yui_3_= 16_0_1_1439066928785_9026" dir=3D"ltr" class=3D""><br></div><div id=3D"yui_= 3_16_0_1_1439066928785_9026" dir=3D"ltr" class=3D"">Will</div><div id=3D"yu= i_3_16_0_1_1439066928785_9026" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_= 1_1439066928785_9026" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1439066= 928785_9026" dir=3D"ltr"><br></div></div></body></html> ------=_Part_1293889_1273479607.1439071641695--

2 1

VM status is not shown in webgui after start of VM
by Christophe TREFOIS 07 Aug '15

07 Aug '15

--_000_9589B8E38C754076A075A0EE1D0DB66Eunilu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYW0gcnVubmluZyAzLjUuMi0xLmVsNy5jZW50b3Mgb24gMSBub2RlLCBz ZWxmIGhvc3RlZCBpbnN0YWxsLg0KDQpXaGVuIEkgc3RhcnQgYSBWTSB0aGUgVk0gaXMgdXAgKEkg Y2FuIGNvbm5lYyB0byBpdCksIGJ1dCB0aGUgc3RhdHVzIGluIHRoZSBHVUkgYmVjb21lcyDigJxn cmV54oCdIHdpdGggYW4gdXAtYXJyb3cgYW5kIHRoZSDigJxMYXVuY2hpbmcgVk3igKbigJ0gdGFz ayBoYXMgYSBzYW5kLWNsb2NrIGF0IOKAnEV4ZWN1dGluZ+KAnS4NCkJlY2F1c2Ugb2YgdGhpcywg SSBjYW7igJl0IHJlYWxseSBjb25uZWMgdG8gdGhlIGNvbnNvbGUsIGFuZCBpdCBqdXN0IHNlZW1z IHdlaXJkLg0KDQpDb3VsZCB5b3UgcGxlYXNlIGd1aWRlIG1lIGFzIHRvIGhvdyB0byBkZWJ1ZyB0 aGlzIHByb2JsZW0/DQoNClRoYW5rcyBpbiBhZHZhbmNlLA0KDQrigJQNCkNocmlzdG9waGUNCg0K RHIgQ2hyaXN0b3BoZSBUcmVmb2lzLCBEaXBsLi1JbmcuDQpUZWNobmljYWwgU3BlY2lhbGlzdCAv IFBvc3QtRG9jDQoNClVOSVZFUlNJVMOJIERVIExVWEVNQk9VUkcNCg0KTFVYRU1CT1VSRyBDRU5U UkUgRk9SIFNZU1RFTVMgQklPTUVESUNJTkUNCkNhbXB1cyBCZWx2YWwgfCBIb3VzZSBvZiBCaW9t ZWRpY2luZQ0KNywgYXZlbnVlIGRlcyBIYXV0cy1Gb3VybmVhdXgNCkwtNDM2MiBFc2NoLXN1ci1B bHpldHRlDQpUOiArMzUyIDQ2IDY2IDQ0IDYxMjQNCkY6ICszNTIgNDYgNjYgNDQgNjk0OQ0KaHR0 cDovL3d3dy51bmkubHUvbGNzYg0KDQpbRmFjZWJvb2tdPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNv bS90cmVmZXg+ICBbVHdpdHRlcl0gPGh0dHBzOi8vdHdpdHRlci5jb20vVHJlZmV4PiAgIFtHb29n bGUgUGx1c10gPGh0dHBzOi8vcGx1cy5nb29nbGUuY29tLytDaHJpc3RvcGhlVHJlZm9pcy8+ICAg W0xpbmtlZGluXSA8aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2luL3RyZWZvaXNjaHJpc3RvcGhl PiAgIFtza3lwZV0gPGh0dHA6Ly9za3lwZTpUcmVmZXg/Y2FsbD4NCg0KLS0tLQ0KVGhpcyBtZXNz YWdlIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlv bi4NCkl0IGlzIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50IG9ubHkuDQpJZiB5b3Ug cmVjZWl2ZSBpdCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IG1lIGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGFueSBjb3BpZXMuDQotLS0tDQoNCg0KDQo= --_000_9589B8E38C754076A075A0EE1D0DB66Eunilu_ Content-Type: text/html; charset="utf-8" Content-ID: <B1AFE5638EE82B4A8675FB242CEC0739(a)uni.lux> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBhbGwsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHJ1bm5pbmcmbmJz cDszLjUuMi0xLmVsNy5jZW50b3Mgb24gMSBub2RlLCBzZWxmIGhvc3RlZCBpbnN0YWxsLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hl biBJIHN0YXJ0IGEgVk0gdGhlIFZNIGlzIHVwIChJIGNhbiBjb25uZWMgdG8gaXQpLCBidXQgdGhl IHN0YXR1cyBpbiB0aGUgR1VJIGJlY29tZXMg4oCcZ3JleeKAnSB3aXRoIGFuIHVwLWFycm93IGFu ZCB0aGUg4oCcTGF1bmNoaW5nIFZN4oCm4oCdIHRhc2sgaGFzIGEgc2FuZC1jbG9jayBhdCDigJxF eGVjdXRpbmfigJ0uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlY2F1c2Ugb2YgdGhpcywgSSBjYW7i gJl0IHJlYWxseSBjb25uZWMgdG8gdGhlIGNvbnNvbGUsIGFuZCBpdCBqdXN0IHNlZW1zIHdlaXJk LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Q291bGQgeW91IHBsZWFzZSBndWlkZSBtZSBhcyB0byBob3cgdG8gZGVidWcgdGhpcyBwcm9i bGVtPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VGhhbmtzIGluIGFkdmFuY2UsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hyaXN0 b3BoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQ7IGxpbmUtaGVpZ2h0 OiAxNnB4OyBjb2xvcjogcmdiKDMzLCAzMywgMzMpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGlu ZTsiIGNsYXNzPSIiPkRyIENocmlzdG9waGUgVHJlZm9pcywgRGlwbC4tSW5nLjwvc3Bhbj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+DQo8c3BhbiBzdHls ZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDYxLCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IGZvbnQtc2l6 ZTogNy41cHQ7IiBjbGFzcz0iIj5UZWNobmljYWwgU3BlY2lhbGlzdCAvIFBvc3QtRG9jPC9zcGFu PjwvcD4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogNy41cHQ7IGxpbmUtaGVpZ2h0OiAxNnB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGluZTsi IGNsYXNzPSIiPlVOSVZFUlNJVMOJIERVIExVWEVNQk9VUkc8L3NwYW4+PGJyIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiByZ2IoNjEsIDU5LCA1 OSk7IGRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPkxVWEVNQk9VUkcgQ0VOVFJFIEZPUiBTWVNU RU1TIEJJT01FRElDSU5FPC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDYxLCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj5DYW1wdXMgQmVsdmFs IHwgSG91c2Ugb2YgQmlvbWVkaWNpbmU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxiciBjbGFzcz0iIj4NCjcsIGF2ZW51ZSBkZXMgSGF1dHMtRm91cm5lYXV4PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N CkwtNDM2MiBFc2NoLXN1ci1BbHpldHRlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEs IDU5LCA1OSk7IGRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPlQ6PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IHJnYig2MSwgNTksIDU5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+JiM0MzszNTIgNDYg NjYgNDQgNjEyNDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1 OSk7IGRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPkY6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2 MSwgNTksIDU5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+JiM0MzszNTIgNDYgNjYgNDQg Njk0OTwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pLmx1L2xjc2IiIHN0eWxlPSJjb2xvcjog cmdiKDAsIDEwOSwgMTg5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+aHR0cDovL3d3dy51 bmkubHUvbGNzYjwvYT48L3A+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAxNnB4OyIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5mYWNlYm9vay5jb20vdHJlZmV4IiBzdHlsZT0iZGlzcGxheTogaW5s aW5lOyIgY2xhc3M9IiI+PGltZyB3aWR0aD0iMjQiIGhlaWdodD0iMjQiIGRhdGEtZmlsZW5hbWU9 ImZhY2Vib29rLnBuZyIgc3JjPSJodHRwczovL3MzLmFtYXpvbmF3cy5jb20vaHRtbHNpZy1hc3Nl dHMvcm91bmRlZC9mYWNlYm9vay5wbmciIGFsdD0iRmFjZWJvb2siIGNsYXNzPSIiPjwvYT48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+DQo8YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL1RyZWZleCIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiIGNsYXNz PSIiPjxpbWcgd2lkdGg9IjI0IiBoZWlnaHQ9IjI0IiBkYXRhLWZpbGVuYW1lPSJ0d2l0dGVyLnBu ZyIgc3JjPSJodHRwczovL3MzLmFtYXpvbmF3cy5jb20vaHRtbHNpZy1hc3NldHMvcm91bmRlZC90 d2l0dGVyLnBuZyIgYWx0PSJUd2l0dGVyIiBjbGFzcz0iIj48L2E+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPg0KPGEgaHJlZj0iaHR0cHM6Ly9wbHVzLmdv b2dsZS5jb20vJiM0MztDaHJpc3RvcGhlVHJlZm9pcy8iIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7 IiBjbGFzcz0iIj4NCjxpbWcgd2lkdGg9IjI0IiBoZWlnaHQ9IjI0IiBkYXRhLWZpbGVuYW1lPSJn b29nbGVwbHVzLnBuZyIgc3JjPSJodHRwczovL3MzLmFtYXpvbmF3cy5jb20vaHRtbHNpZy1hc3Nl dHMvcm91bmRlZC9nb29nbGVwbHVzLnBuZyIgYWx0PSJHb29nbGUgUGx1cyIgY2xhc3M9IiI+PC9h PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi90cmVmb2lzY2hyaXN0b3BoZSIgc3R5bGU9 ImRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPg0KPGltZyB3aWR0aD0iMjQiIGhlaWdodD0iMjQi IGRhdGEtZmlsZW5hbWU9ImxpbmtlZGluLnBuZyIgc3JjPSJodHRwczovL3MzLmFtYXpvbmF3cy5j b20vaHRtbHNpZy1hc3NldHMvcm91bmRlZC9saW5rZWRpbi5wbmciIGFsdD0iTGlua2VkaW4iIGNs YXNzPSIiPjwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+DQo8YSBocmVmPSJodHRwOi8vc2t5cGU6VHJlZmV4P2NhbGwiIHN0eWxlPSJkaXNwbGF5OiBp bmxpbmU7IiBjbGFzcz0iIj48aW1nIHdpZHRoPSIyNCIgaGVpZ2h0PSIyNCIgZGF0YS1maWxlbmFt ZT0ic2t5cGUucG5nIiBzcmM9Imh0dHBzOi8vczMuYW1hem9uYXdzLmNvbS9odG1sc2lnLWFzc2V0 cy9yb3VuZGVkL3NreXBlLnBuZyIgYWx0PSJza3lwZSIgY2xhc3M9IiI+PC9hPjwvcD4NCjxwIGNs YXNzPSJiYW5uZXItY29udGFpbmVyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAxNnB4OyI+DQo8L3A+DQo8cCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDYxLCA1OSwgNTkp OyBmb250LXNpemU6IDlweDsgbGluZS1oZWlnaHQ6IDE2cHg7IiBjbGFzcz0iIj4NCi0tLS08YnIg Y2xhc3M9IiI+DQpUaGlzIG1lc3NhZ2UgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBw cml2aWxlZ2VkIGluZm9ybWF0aW9uLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpJdCBpcyBpbnRlbmRlZCBmb3IgdGhlIG5hbWVk IHJlY2lwaWVudCBvbmx5LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpJZiB5b3UgcmVjZWl2ZSBpdCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IG1lIGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5k IGFueSBjb3BpZXMuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiciBjbGFzcz0iIj4NCi0tLS08YnIgY2xhc3M9IiI+DQo8L3A+DQombmJzcDs8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+IDwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9589B8E38C754076A075A0EE1D0DB66Eunilu_--

1 0

Ubuntu guest doesn't reboot properly
by Alan Murrell 07 Aug '15

07 Aug '15

I have an Ubuntu 14.04 guest (actually Zentyal server). Guest additions are installed from respository (and even displays the extra info like IP address, host name, memory use) in the oVirt dash board. Whenever I either reboot the guest or shut it down, it never seems to come up properly. It shows that it is powered on and it responds to ping, but I cannot SSH in (says connection refused). The SPICE console display just shows black with some slightly coloured bars in the upper left of the screen, so I am unable to determine what stage of the boot process it is on and/or if it is even at a login screen. I have a Windows 7 guest VM that reboots with no issue. I currently do not have another Linux guest VM to test with, but I plan on installing a Debian guest, CentOS guest, as well as a "vanilla" Ubuntu 14.04 guest to see if it is a Linux thing, and Ubuntu thing, or just something odd with the Zentyal spin of Ubuntu. I will report on my results (it may take a bit), but I wanted to check here to see if anyone else has already troubleshot this and what the findings and conclusions were? Thanks! :-) -Alan

2 1