- Users - oVirt List Archives

Migrating old VMWare VM to oVirt?
by Chris Adams 01 Sep '15

01 Sep '15

I have an ancient VM that I need to migrate to oVirt if possible. It is Windows 2000 Server on VMWare ESXi 4.1 (yeah, I know, please don't laugh). Is there any possiblity of making this work? Reinstalling the Windows system (or upgrading) is just not practical at this time, and I need to get this thing off of the old VMWare box. -- Chris Adams <cma(a)cmadams.net>

3 3

mirrorlist-ovirt-3.4-fc$releasever not available
by Пузиков Константин 01 Sep '15

01 Sep '15

http://resources.ovirt.org/pub/yum-repo/mirrorlist-ovirt-3.4-fc$releasever Error: Cannot find a valid baseurl for repo: ovirt-3.4-stable

1 0

Migration from all-in-one to self hosted engine tips?
by Gianluca Cecchi 01 Sep '15

01 Sep '15

Hello, considering that all-in-one could become deprecated, any tips in migrating from: workstation with Fedora 20 + oVirt 3.5.3 All-In-One and local disks to (when 3.6 released): same workstation with Fedora 22 + oVirt 3.6.0 Self Hosted Engine ? I already tested direct migration from Fedora 20 to Fedora 22 on another workstation (without oVirt). Only bugs found in that case: - default kernel after migration is not the updated one (and had a bug with Intel ICH8 sound modules) --> update of grub2 default kernel solves it - nvidia kernel modules don't load and no graphic environment available due to this --> solved booting in init 3 and making a "depmod -a" and then kernel modules are correctly loaded So it would be nice to get any suggestion, that I can eventually test on a dev environment. Thanks in advance, Gianluca

2 1

Feature request: bind mounting filesystems
by Steve Kilduff 01 Sep '15

01 Sep '15

Hi, Bind mounting paths would be a great feature. It would hopefully make storage backends transparent and not tie us to nfs or gluster. Idea is shared storage is available on all servers at /mnt/share, ovirt would bind mount this source on all servers. Maybe this even works, but in that case I cant find documentation or examples. Cheers, Steve Kilduff

2 1

[ANN] Release Process changes
by Sandro Bonazzola 01 Sep '15

01 Sep '15

The oVirt Team strive to provide a stable solution and provide timely updates to improve on that solution. After GA of every major release we try to provide updates to discovered issues on a monthly basis. In the current process we announce a release date just after the previous release (usually a month ahead) and aim to fix to scoped issues for this date. Sometimes we fail to meet that date when we see that the scope was not met or that the stability is not up to the release standard. This means that we have to change the announced date and this might happen several times. In order to improve on this process, maintenance (not like major) releases will not have a declared date and will be released when ready. We will remain attentive to needs of urgent issues and will continue to aim for monthly release, but instead we will provide weekly updates on current status of development and testing of maintenance releases and gaps we are working to close for that release. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 3.5.3 and Network Unified Persistence issues?
by Simon Barrett 01 Sep '15

01 Sep '15

--_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm running into a problem with my upgrades to oVirt 3.5.3 and wanted to ch= eck if the following is a known issue. I have multiple vlan tagged interfaces configured. The files are being gen= erated as expected by vdsm. The vlan 108 interface below is used by the ovi= rtmgmt bridge. The uatdev_ben, bond0.192, dev_office, bond0.124 interface d= efinitions all have ONBOOT=3Dno. root@host> grep -i onboot ifcfg* | grep -v bak ifcfg-bond0:ONBOOT=3Dyes ifcfg-bond0.108:ONBOOT=3Dyes ifcfg-bond0.124:ONBOOT=3Dno ifcfg-bond0.192:ONBOOT=3Dno ifcfg-dev_office:ONBOOT=3Dno ifcfg-eth0:ONBOOT=3Dyes ifcfg-eth1:ONBOOT=3Dyes ifcfg-eth2:ONBOOT=3Dno ifcfg-eth3:ONBOOT=3Dno ifcfg-lo:ONBOOT=3Dyes ifcfg-ovirtmgmt:ONBOOT=3Dyes ifcfg-uatdev_ben:ONBOOT=3Dno The persistence configuration files are where they should be (I think): root@host> ls -l /var/lib/vdsm/persistence/netconf/nets/ total 12 -rw-r--r-- 1 root root 121 Aug 24 22:44 dev_office -rw-r--r-- 1 root root 173 Aug 24 22:44 ovirtmgmt -rw-r--r-- 1 root root 121 Aug 24 22:44 uatdev_ben If I were to do a "service network restart" on the node, the uatdev_ben, de= v_office, bond0.124 & bond0.192 are removed and then not restored as the "O= NBOOT=3Dno". I assumed that vdsmd would re-create the dev_office and uatdev= _ben interfaces so restarted vdsmd but they were not restored. I tried a "v= dsm-tool restore-nets" to see if that would restore the interfaces but no j= oy. Am I missing something? Is there another method I should use to recover the= missing interfaces? Should the ifcfg files all be configured with "ONBOOT= =3Dyes" just in case someone does run a "service network restart"? My oVirt nodes are CentOS 6.5, I'm not using the node iso. Many thanks in advance for any assistance. Regards, Simon Barrett --_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> I’m running into a problem with my upgrades to= oVirt 3.5.3 and wanted to check if the following is a known issue.<o:p></o= :p> <o:p> </o:p> I have  multiple vlan tagged interfaces configu= red. The files are being generated as expected by vdsm. The vlan 108 interf= ace below is used by the ovirtmgmt bridge. The uatdev_ben, bond0.192, dev_o= ffice, bond0.124 interface definitions all have ONBOOT=3Dno.<o:p></o:p> <o:p> </o:p> root@host> grep -i o= nboot ifcfg* | grep -v bak<o:p></o:p> ifcfg-bond0:ONBOOT=3Dye= s<o:p></o:p> ifcfg-bond0.108:ONBOOT= =3Dyes<o:p></o:p> ifcfg-bond0.124:ONBOOT= =3Dno<o:p></o:p> ifcfg-bond0.192:ONBOOT= =3Dno<o:p></o:p> ifcfg-dev_office:ONBOOT= =3Dno<o:p></o:p> ifcfg-eth0:ONBOOT=3Dyes= <o:p></o:p> ifcfg-eth1:ONBOOT=3Dyes= <o:p></o:p> ifcfg-eth2:ONBOOT=3Dno<= o:p></o:p> ifcfg-eth3:ONBOOT=3Dno<= o:p></o:p> ifcfg-lo:ONBOOT=3Dyes<o= :p></o:p> ifcfg-ovirtmgmt:ONBOOT= =3Dyes<o:p></o:p> ifcfg-uatdev_ben:ONBOOT= =3Dno<o:p></o:p> <o:p> </o:p> The persistence configuration files are where they s= hould be (I think):<o:p></o:p> <o:p> </o:p> root@host> ls -l /va= r/lib/vdsm/persistence/netconf/nets/<o:p></o:p> total 12<o:p></o:p> -rw-r--r-- 1 root root = 121 Aug 24 22:44 dev_office<o:p></o:p> -rw-r--r-- 1 root root = 173 Aug 24 22:44 ovirtmgmt<o:p></o:p> -rw-r--r-- 1 root root = 121 Aug 24 22:44 uatdev_ben<o:p></o:p> <o:p> </o:p> If I were to do a “service network restart&#82= 21; on the node, the uatdev_ben, dev_office, bond0.124 & bond0.192 are = removed and then not restored as the “ONBOOT=3Dno”. I assumed t= hat vdsmd would re-create the dev_office and uatdev_ben interfaces so restarted vdsmd but they were not restored. I tried a “vdsm-tool = restore-nets” to see if that would restore the interfaces but no joy.= <o:p></o:p> <o:p> </o:p> Am I missing something? Is there another method I sh= ould use to recover the missing interfaces? Should the ifcfg files all be c= onfigured with “ONBOOT=3Dyes” just in case someone does run a &= #8220;service network restart”?<o:p></o:p> <o:p> </o:p> My oVirt nodes are CentOS 6.5, I’m not using t= he node iso. <o:p> </o:p> <o:p> </o:p> Many thanks in advance for any assistance.<o:p></o:p= > <o:p> </o:p> Regards,<o:p></o:p> <o:p> </o:p> Simon Barrett<o:p></o:p> </div> </body> </html> --_000_D86C48DF8800164BBE50B87623F7AC9580A16459ln2wio001devtra_--

3 3

[3.6 deep dive] - Hosted Engine support for glusterfs and FC
by Sandro Bonazzola 01 Sep '15

01 Sep '15

Hi, [3.6 deep dive] - Hosted Engine support for glusterfs and FC is going to start in 1 hour, attached the slides of the deep dive. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Couple issues found with oVirt 3.6.0 Third Beta Release
by SULLIVAN, Chris (WGK) 01 Sep '15

01 Sep '15

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. 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. ----------------------------- -----Original Message----- Date: Thu, 20 Aug 2015 16:06:29 +0200 From: Sandro Bonazzola <sbonazzo(a)redhat.com> To: announce(a)ovirt.org, devel(a)ovirt.org, users <users(a)ovirt.org> Subject: [ovirt-users] [ANN] oVirt 3.6.0 Third Beta Release is now available for testing Message-ID: <CAPQRNT=3VKsCpmL7PKS9zJ1LO9pm7iOBC1hJcFyiozHXrTKZzQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" The oVirt Project is pleased to announce the availability of the Third Beta release of oVirt 3.6 for testing, as of August 20th, 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. This release is available now for Fedora 22, Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release supports Hypervisor Hosts running Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar), Fedora 21 and Fedora 22. Highly experimental support for Debian 8.1 Jessie has been added too. This release of oVirt 3.6.0 includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. New Node ISO and oVirt Live ISO will be available soon as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ovirt.org_OVirt-5F3… [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__plain.resources.ovirt.o… <https://urldefense.proofpoint.com/v2/url?u=http-3A__plain.resources.ovirt.o… > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ovirt.org_Repositor… -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 7

New storage domain on nfs share
by gregor 31 Aug '15

31 Aug '15

Hi, what is the right way to create a storage on an NFS share to use as data storage for virtual machines? It is only possible to create a storage "ISO/NFS" or "Export/NFS" where I can not create disks for a virtual machine. cheers gregor

4 5

Canceled: [3.6 deep dive] - Hosted Engine support for glusterfs and FC
by Raymond 31 Aug '15

31 Aug '15

----_com.android.email_65930459842440 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2hlbjogU2VwIDEsIDIwMTUgMzozMDowMCBQTQpXaGVyZTogeW91dHViZTogaHR0cHM6Ly93d3cu eW91dHViZS5jb20vd2F0Y2g/dj1aU2UxZEJIUWZuQQotLQpBYnN0cmFjdDoKRXh0ZXJuYWwgR2x1 c3RlckZTIGFuZCBGaWJlciBDaGFubmVsIHN0b3JhZ2Ugc3VwcG9ydCBmb3IgSG9zdGVkIEVuZ2lu ZQogCkZlYXR1cmUgcGFnZXM6Cmh0dHA6Ly93d3cub3ZpcnQub3JnL0ZlYXR1cmVzL1NlbGZfSG9z dGVkX0VuZ2luZV9HbHVzdGVyX1N1cHBvcnQKaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMv U2VsZl9Ib3N0ZWRfRW5naW5lX0ZDX1N1cHBvcnQKCnlvdXR1YmxlIGxpbms6IHlvdXR1YmU6IGh0 dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9WlNlMWRCSFFmbkEKZ29vZ2xlIGV2ZW50czog aHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vdS8wL2V2ZW50cy9jamozMnN2N2hwaHVqdG5idTdzdDg3 ODI3bzgKClZpZXcgeW91ciBldmVudCBhdCBodHRwczovL3d3dy5nb29nbGUuY29tL2NhbGVuZGFy L2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1abTh6TVRJek4ydHZNVEp3TjI4NE4yaDJjblZtTW01bU1t OGdkWE5sY25OQWIzWnBjblF1YjNKbiZ0b2s9TVRnalltRjZkV3hoZVVCeVpXUm9ZWFF1WTI5dFlq STVZakpsWldaaU56ZGxZVEUzTm1FNU1qVmhNMkZrTURrM05qVXlZemcwT1RObU9EWXpNQSZjdHo9 QXNpYS9KZXJ1c2FsZW0maGw9ZW4u ----_com.android.email_65930459842440 Content-Type: text/calendar; method=CANCEL; name="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6QW5kcm9pZEVtYWlsDQpWRVJT SU9OOjIuMA0KQkVHSU46VkVWRU5UDQpVSUQ6Zm8zMTIzN2tvMTJwN284N2h2cnVmMm5mMm9AZ29v Z2xlLmNvbQ0KRFRTVEFNUDoyMDE1MDgzMVQxNzQyNTlaDQpEVFNUQVJUOjIwMTUwOTAxVDEzMzAw MFoNCkRURU5EOjIwMTUwOTAxVDE0MzAwMFoNCkxPQ0FUSU9OOnlvdXR1YmU6IGh0dHBzOi8vd3d3 LnlvdXR1YmUuY29tL3dhdGNoP3Y9WlNlMWRCSFFmbkENClNVTU1BUlk6WzMuNiBkZWVwIGRpdmVd IC0gSG9zdGVkIEVuZ2luZSBzdXBwb3J0IGZvciBnbHVzdGVyZnMgYW5kIEZDDQpERVNDUklQVElP TjpXaGVuOiBTZXAgMVwsIDIwMTUgMzozMDowMCBQTVxuV2hlcmU6IHlvdXR1YmU6IGh0dHBzOi8v d3d3LnkNCglvdXR1YmUuY29tL3dhdGNoP3Y9WlNlMWRCSFFmbkFcbi0tXG5BYnN0cmFjdDpcbkV4 dGVybmFsIEdsdXN0ZXJGUyBhbmQgRg0KCWliZXIgQ2hhbm5lbCBzdG9yYWdlIHN1cHBvcnQgZm9y IEhvc3RlZCBFbmdpbmVcbiBcbkZlYXR1cmUgcGFnZXM6XG5odHRwDQoJOi8vd3d3Lm92aXJ0Lm9y Zy9GZWF0dXJlcy9TZWxmX0hvc3RlZF9FbmdpbmVfR2x1c3Rlcl9TdXBwb3J0XG5odHRwOi8vd3cN Cgl3Lm92aXJ0Lm9yZy9GZWF0dXJlcy9TZWxmX0hvc3RlZF9FbmdpbmVfRkNfU3VwcG9ydFxuXG55 b3V0dWJsZSBsaW5rOiB5bw0KCXV0dWJlOiBodHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92 PVpTZTFkQkhRZm5BXG5nb29nbGUgZXZlbnRzOiBodHRwDQoJczovL3BsdXMuZ29vZ2xlLmNvbS91 LzAvZXZlbnRzL2NqajMyc3Y3aHBodWp0bmJ1N3N0ODc4MjdvOFxuXG5WaWV3IHlvdXINCgkgZXZl bnQgYXQgaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jYWxlbmRhci9ldmVudD9hY3Rpb249VklFVyZl aWQ9Wm04ek1USQ0KCXpOMnR2TVRKd04yODROMmgyY25WbU1tNW1NbThnZFhObGNuTkFiM1pwY25R dWIzSm4mdG9rPU1UZ2pZbUY2ZFd4aGVVQnlaDQoJV1JvWVhRdVkyOXRZakk1WWpKbFpXWmlOemRs WVRFM05tRTVNalZoTTJGa01EazNOalV5WXpnME9UTm1PRFl6TUEmY3R6PUENCglzaWEvSmVydXNh bGVtJmhsPWVuLg0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpBVFRFTkRFRTtS T0xFPVJFUS1QQVJUSUNJUEFOVDtDTj0ic2JvbmF6em9AcmVkaGF0LmNvbSI6TUFJTFRPOnNib25h enpvQHINCgllZGhhdC5jb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO0NOPSJkZmVk aXVja0ByZWRoYXQuY29tIjpNQUlMVE86ZG9yb25AcmVkaA0KCWF0LmNvbQ0KQVRURU5ERUU7Uk9M RT1SRVEtUEFSVElDSVBBTlQ7Q049InN0aXJhYm9zQHJlZGhhdC5jb20iOk1BSUxUTzpzdGlyYWJv c0ByDQoJZWRoYXQuY29tDQpBVFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtDTj0iYmF6dWxh eUByZWRoYXQuY29tIjpNQUlMVE86YmF6dWxheUByZWQNCgloYXQuY29tDQpBVFRFTkRFRTtST0xF PVJFUS1QQVJUSUNJUEFOVDtDTj0iaWhlaW1AcmVkaGF0LmNvbSI6TUFJTFRPOmloZWltQHJlZGhh dC4NCgljb20NCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO0NOPSJ1c2Vyc0BvdmlydC5v cmciOk1BSUxUTzp1c2Vyc0BvdmlydC5vcg0KCWcNCkFUVEVOREVFO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO0NOPSJkZXZlbEBvdmlydC5vcmciOk1BSUxUTzpkZXZlbEBvdmlydC5vcg0KCWcNCkNMQVNT OlBVQkxJQw0KU1RBVFVTOkNBTkNFTExFRA0KVFJBTlNQOk9QQVFVRQ0KUFJJT1JJVFk6NQ0KU0VR VUVOQ0U6MA0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K ----_com.android.email_65930459842440--

1 0