Re: [ovirt-users] Couple issues found with oVirt 3.6.0 Third Beta Release

2015-08-30 Thread Yaniv Dary
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109

Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary


On Fri, Aug 28, 2015 at 4:19 AM, SULLIVAN, Chris (WGK) 
chris.sulli...@woodgroupkenny.com wrote:

 Hi,

 I recently re-installed my test oVirt environment, upgrading from 3.5.2 to
 3.6.0 beta 3 (Engine 3.6.0-0.0.master.20150819134454.gite6b79a7.el7.centos,
 VDSM 4.17.3-0.el7.centos, GlusterFS 3.7.3-1.el7) in the process. Due to a
 software issue outside of oVirt I had to start with a clean install for
 3.6, however I kept all the old storage domains. All hosts and the engine
 are running CentOS 7.1 and I'm using hosted-engine.

 During the setup/recovery process I encountered the following issues:

 :: Could not create GlusterFS Data domain due to 'General Exception'
 I attempted to create a Data domain using a FQDN associated with a
 floating IP, so that hosts could still mount the domain when the specific
 GlusterFS host used to define the storage was down. This FQDN was
 resolvable and contactable on each host in the farm. The floating IP is
 shared between two of the four GlusterFS hosts. The logs reported an
 unhandled exception ('x not in list') raised by the below statement (line
 340 in
 https://github.com/oVirt/vdsm/blob/master/vdsm/storage/storageServer.py ):
 def _get_backup_servers_option(self):
 servers = [brick.split(:)[0] for brick in self.volinfo['bricks']]
 servers.remove(self._volfileserver)   #--- Exception thrown here
 if not servers:
 return 

 return backup-volfile-servers= + :.join(servers)

 My assumption (without looking too deep in the code) was that since I used
 a FQDN that did not have any bricks associated with it,
 'self._volfileserver' would be set to a name that would not appear in
 'servers', resulting in the exception. I patched it as per the following:
 def _get_backup_servers_option(self):
 servers = [brick.split(:)[0] for brick in self.volinfo['bricks']]
 if self._volfileserver in servers:
 self.log.warn(Removing current volfileserver %s... %
 self._volfileserver)
 servers.remove(self._volfileserver)
 else:
 self.log.warn(Current volfileserver not in servers.)
 if not servers:
 return 

 return backup-volfile-servers= + :.join(servers)

 Once patched the Data domain created successfully and appears to be
 working normally, although I'm not sure if the above change has any
 negative knock-on effects throughout the code or in specific situations.
 I'd suggest that the _get_backup_servers_option method be tweaked to handle
 this configuration gracefully by someone with more knowledge of the code,
 either by allowing the configuration or rejecting it with a suitable error
 message if the configuration is intended to be unsupported.

 :: Could not import VMs from old Data domain due to unsupported video type
 (VGA)
 Once the new data center was up and running, I attached the old Data
 domain and attempted to import the VMs/templates. Template import worked
 fine, however VM import failed with an error stating the video device
 (which came up as VGA) was not supported. I attempted to fix this by
 specifically defining the video type as 'qxl' in the .ovf file for the VM
 in the OVF_STORE for the old storage however the VM would always come up
 with video type VGA in the import dialog, and the import dialog does not
 permit the value to be changed.

 The workaround was to add 'vnc/vga' to the supported protocols list in a
 .properties file in the engine OSinfo folder, e.g.:
 os.other.devices.display.protocols.value =
 spice/qxl,vnc/cirrus,vnc/qxl,vnc/vga

 Once the engine was restarted the VM import process worked fine, and there
 have been no issues starting the VM with a VGA device or accessing the VM's
 console. To resolve the issue I'd suggest that either:
  - 'vnc/vga' be added to the default supported protocols list; or
 - the video type defined in the .ovf file for the VM to be imported is
 recognized/honoured by the import dialog; or
 - if the import dialog defaults to a particular video device, that it
 default to one that is supported by the engine for the OS defined in the
 VM's .ovf file.

 I can create Bugzilla entries for the above if required.



Please do.
Thanks!



 Cheers,

 Chris




 PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY
 NEED TO.

 This email and its attachments may contain information which is
 confidential and/or legally privileged. If you are not the intended
 recipient of this e-mail please notify the sender immediately by e-mail and
 delete this e-mail and its attachments from your computer and IT systems.
 You must not copy, re-transmit, use or disclose (other than to the sender)
 the existence or contents of this email or its attachments or permit anyone
 else to do so.

 

Re: [ovirt-users] Couple issues found with oVirt 3.6.0 Third Beta Release

2015-08-30 Thread Maor Lipchuk




- Original Message -
 From: Yaniv Dary yd...@redhat.com
 To: Chris SULLIVAN (WGK) chris.sulli...@woodgroupkenny.com
 Cc: users@ovirt.org
 Sent: Sunday, August 30, 2015 2:28:16 PM
 Subject: Re: [ovirt-users] Couple issues found with oVirt 3.6.0 Third Beta
 Release
 
 
 
 Yaniv Dary
 Technical Product Manager
 Red Hat Israel Ltd.
 34 Jerusalem Road
 Building A, 4th floor
 Ra'anana, Israel 4350109
 
 Tel : +972 (9) 7692306
 8272306
 Email: yd...@redhat.com IRC : ydary
 
 On Fri, Aug 28, 2015 at 4:19 AM, SULLIVAN, Chris (WGK) 
 chris.sulli...@woodgroupkenny.com  wrote:
 
 
 Hi,
 
 I recently re-installed my test oVirt environment, upgrading from 3.5.2 to
 3.6.0 beta 3 (Engine 3.6.0-0.0.master.20150819134454.gite6b79a7.el7.centos,
 VDSM 4.17.3-0.el7.centos, GlusterFS 3.7.3-1.el7) in the process. Due to a
 software issue outside of oVirt I had to start with a clean install for 3.6,
 however I kept all the old storage domains. All hosts and the engine are
 running CentOS 7.1 and I'm using hosted-engine.
 
 During the setup/recovery process I encountered the following issues:
 
 :: Could not create GlusterFS Data domain due to 'General Exception'
 I attempted to create a Data domain using a FQDN associated with a floating
 IP, so that hosts could still mount the domain when the specific GlusterFS
 host used to define the storage was down. This FQDN was resolvable and
 contactable on each host in the farm. The floating IP is shared between two
 of the four GlusterFS hosts. The logs reported an unhandled exception ('x
 not in list') raised by the below statement (line 340 in
 https://github.com/oVirt/vdsm/blob/master/vdsm/storage/storageServer.py ):
 def _get_backup_servers_option(self):
 servers = [brick.split(:)[0] for brick in self.volinfo['bricks']]
 servers.remove(self._volfileserver) #--- Exception thrown here
 if not servers:
 return 
 
 return backup-volfile-servers= + :.join(servers)
 
 My assumption (without looking too deep in the code) was that since I used a
 FQDN that did not have any bricks associated with it, 'self._volfileserver'
 would be set to a name that would not appear in 'servers', resulting in the
 exception. I patched it as per the following:
 def _get_backup_servers_option(self):
 servers = [brick.split(:)[0] for brick in self.volinfo['bricks']]
 if self._volfileserver in servers:
 self.log.warn(Removing current volfileserver %s... % self._volfileserver)
 servers.remove(self._volfileserver)
 else:
 self.log.warn(Current volfileserver not in servers.)
 if not servers:
 return 
 
 return backup-volfile-servers= + :.join(servers)
 
 Once patched the Data domain created successfully and appears to be working
 normally, although I'm not sure if the above change has any negative
 knock-on effects throughout the code or in specific situations. I'd suggest
 that the _get_backup_servers_option method be tweaked to handle this
 configuration gracefully by someone with more knowledge of the code, either
 by allowing the configuration or rejecting it with a suitable error message
 if the configuration is intended to be unsupported.
 
 :: Could not import VMs from old Data domain due to unsupported video type
 (VGA)
 Once the new data center was up and running, I attached the old Data domain
 and attempted to import the VMs/templates. Template import worked fine,
 however VM import failed with an error stating the video device (which came
 up as VGA) was not supported. I attempted to fix this by specifically
 defining the video type as 'qxl' in the .ovf file for the VM in the
 OVF_STORE for the old storage however the VM would always come up with video
 type VGA in the import dialog, and the import dialog does not permit the
 value to be changed.
 
 The workaround was to add 'vnc/vga' to the supported protocols list in a
 .properties file in the engine OSinfo folder, e.g.:
 os.other.devices.display.protocols.value =
 spice/qxl,vnc/cirrus,vnc/qxl,vnc/vga
 
 Once the engine was restarted the VM import process worked fine, and there
 have been no issues starting the VM with a VGA device or accessing the VM's
 console. To resolve the issue I'd suggest that either:
 - 'vnc/vga' be added to the default supported protocols list; or
 - the video type defined in the .ovf file for the VM to be imported is
 recognized/honoured by the import dialog; or
 - if the import dialog defaults to a particular video device, that it default
 to one that is supported by the engine for the OS defined in the VM's .ovf
 file.


Once the Storage Domain is attached all the ovf data from the OVF_STORE disk is 
being copied to a DB table called unregistered_ovf_of_entities.
This table is being used to determine the VM configuration once you 
register(import) a VM to the setup.
You probably still saw VGA after changing the OVF file since the data in this 
table has not been changed.

 
 I can create Bugzilla entries for the above if required.
 
 
 Please do.
 Thanks!
 
 
 
 Cheers,
 
 Chris
 
 
 
 
 PLEASE