- Users - oVirt List Archives

[ANN] oVirt 3.5 won't receive further updates
by Sandro Bonazzola 01 Dec '15

01 Dec '15

Hi, due to the release of recent 3.6.0 major release of the oVirt project, and upcoming release of its first maintenance release 3.6.1, the last 3.5 release is 3.5.6 we released today. We recommend anyone hitting issued existing in 3.5 to upgrade to 3.6 to get the fixes since 3.5 won't receive further updates. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[ANN] oVirt 3.5.6 Final Release is now available
by Sandro Bonazzola 01 Dec '15

01 Dec '15

The oVirt Project is pleased to announce the availability of the oVirt 3.5.6 Final Release as of December 1st, 2015. This release is available now for 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 6.7, CentOS Linux 6.7 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release includes updated packages for: - ovirt-engine - ovirt-hosted-engine-ha - vdsm - ovirt-engine-sdk-python - ovirt-engine-sdk-java - ovirt-engine-cli - qemu-kvm-ev - gperftools - ipxe - libunwind - OVMF - qemu-guest-agent - seabios - sgabios - ovirt-guest-tools See the release notes [1] for a list of fixed bugs. Please refer to release notes [1] for Installation / Upgrade instructions. a new oVirt Live ISO is already available[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] http://www.ovirt.org/OVirt_3.5.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5/iso/ovirt-live/el6-3.5.6/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Windows 10
by Koen Vanoppen 01 Dec '15

01 Dec '15

Dear all, Yes, onther question :-). This time it's about windows 10. I'm running ovirt 3.5.4 and I don't manage to install windows 10 on it. Keeps giving me a blue screen (yes, I know, it's still a windows... ;-) ) on reboot. Are there any special settings you need to enable when creating the vm? Which OS do I need to select? Or shall I just wait untile the relase of ovirt 3.6 :-) ? Kind regards, Koen

4 5

Corruped disks
by Koen Vanoppen 30 Nov '15

30 Nov '15

Dear all, lately we are experience some strange behaviour on our vms... Every now and then we have disks that went corrupt. Is there a chance that ovirt is the issue here or...? It happens (luckily) on our DEV/UAT cluster. Since the last 4 weeks, we already had 6 vm's that went totaly corrupt... Kind regards, Koen

3 3

Re: [ovirt-users] Engine upgrade error - 03_06_1670_unique_vds_id_network_name_vds_interface.sql
by Yedidyah Bar David 30 Nov '15

30 Nov '15

On Mon, Nov 30, 2015 at 3:34 PM, Frank Rothenstein <f.rothenstein(a)bodden-kliniken.de> wrote: > Hello, > > I tried several times to upgrade my ovirt-engine 3.5.5 to 3.6. Every > time the setup stops at updating the DB-schema. The log revealed when > this happpens: The setup ist complaining about a duplicated key - here > is the part of the log. Of course there is only one network in the > interface. > > Can anybody help me getting a solution? > > Thnaks, Frank > > Running upgrade sql script '/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql'... > 2542964- > 2542965-2015-11-30 08:15:26 DEBUG > otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema > plugin.execute:941 execute-output: ['/usr/share/ovirt- > engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', > 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt- > engine-setup-20151130073216-erdh9f.log', '-c', 'apply'] stderr: > 2543300-psql:/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql:1: ERROR: could not create unique index > "vds_interface_vds_id_network_name_unique" > 2543487:DETAIL: Key (vds_id, network_name)=(ba954f0f-6ecb-4ec8-b169- > 7e0a1147b4cd, KHnetz) is duplicated. > 2543585-CONTEXT: SQL statement "ALTER TABLE vds_interface ADD > CONSTRAINT vds_interface_vds_id_network_name_unique unique (vds_id, > network_name)" > 2543723-PL/pgSQL function fn_db_create_constraint(character > varying,character varying,text) line 4 at EXECUTE statement > 2543835-FATAL: Cannot execute sql command: --file=/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql Can you post output of 'select * from vds_interface' from engine database? Adding Eli and changing subject. > 2543975- > 2543976-2015-11-30 08:15:26 DEBUG otopi.context > context._executeMethod:156 method exception > 2544060-Traceback (most recent call last): > 2544095- File "/usr/lib/python2.7/site-packages/otopi/context.py", > line 146, in _executeMethod > 2544183- method['method']() > 2544206- File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- > engine-setup/ovirt-engine/db/schema.py", line 291, in _misc > 2544325- oenginecons.EngineDBEnv.PGPASS_FILE > 2544365- File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line > 946, in execute > 2544445- command=args[0], > 2544466-RuntimeError: Command '/usr/share/ovirt- > engine/dbscripts/schema.sh' failed to execute > 2544552-2015-11-30 08:15:26 ERROR otopi.context > context._executeMethod:165 Failed to execute stage 'Misc > configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' > failed to execute > 2544737-2015-11-30 08:15:26 DEBUG otopi.transaction > transaction.abort:134 aborting 'Yum Transaction' > 2544830-2015-11-30 08:15:26 INFO > otopi.plugins.otopi.packagers.yumpackager yumpackager.info:95 Yum > Performing yum transaction rollback > > > > > > ______________________________________________________________________________ > BODDEN-KLINIKEN Ribnitz-Damgarten GmbH > Sandhufe 2 > 18311 Ribnitz-Damgarten > > Telefon: 03821-700-0 > Fax: 03821-700-240 > > E-Mail: info(a)bodden-kliniken.de Internet: http://www.bodden-kliniken.de > > Sitz: Ribnitz-Damgarten, Amtsgericht: Stralsund, HRB 2919, Steuer-Nr.: 079/133/40188 > Aufsichtsratsvorsitzende: Carmen Schröter, Geschäftsführer: Dr. Falko Milski > > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorge- > sehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, beachten Sie bitte, dass jede Form der Veröf- > fentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sofort den > Absender zu informieren und die E-Mail zu löschen. > > > Bodden-Kliniken Ribnitz-Damgarten GmbH 2015 > *** Virenfrei durch Kerio Mail Server und Sophos Antivirus *** > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- Didi

1 0

Re: [ovirt-users] [SOLVED] Re: Trying to make ovirt-hosted-engine-setup create a customized Engine-vm on 3.6 HC HE
by Giuseppe Ragusa 30 Nov '15

30 Nov '15

On Wed, Nov 25, 2015, at 12:10, Simone Tiraboschi wrote: > > > On Mon, Nov 23, 2015 at 10:17 PM, Giuseppe Ragusa > <giuseppe.ragusa(a)hotmail.com> wrote: >> On Tue, Oct 27, 2015, at 00:10, Giuseppe Ragusa wrote: >> > On Mon, Oct 26, 2015, at 09:48, Simone Tiraboschi wrote: >> > > >> > > >> > > On Mon, Oct 26, 2015 at 12:14 AM, Giuseppe Ragusa > > <giuseppe.ragusa(a)hotmail.com> wrote: >> > >> Hi all, >> > >> I'm experiencing some difficulties using oVirt 3.6 latest snapshot. >> > >> >> > >> I'm trying to trick the self-hosted-engine setup to create a custom > >> engine vm with 3 nics (with fixed MACs/UUIDs). >> > >> >> > >> The GlusterFS volume (3.7.5 hyperconverged, replica 3, for the > >> engine vm) and the network bridges (ovirtmgmt and other two > >> bridges, called nfs and lan, for the engine vm) have been > >> preconfigured on the initial fully-patched CentOS 7.1 host (plus > >> other two identical hosts which are awaiting to be added). >> > >> >> > >> I'm stuck at a point with the engine vm successfully starting but > >> with only one nic present (connected to the ovirtmgmt bridge). >> > >> >> > >> I'm trying to obtain the modified engine vm by means of a trick > >> which used to work in a previous (aborted because of lacking GlusterFS-by- > >> libgfapi support) oVirt 3.5 test setup (about a year ago, maybe > >> more): I'm substituting the standard /usr/share/ovirt-hosted-engine- > >> setup/templates/vm.conf.in with the following: >> > >> >> > >> vmId=@VM_UUID@ >> > >> memSize=@MEM_SIZE@ >> > >> display=@CONSOLE_TYPE@ >> > >> devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0, > >> bus:1, type:drive},specParams:{},readonly:true,deviceId:@CDROM_UUI- > >> D@,path:@CDROM@,device:cdrom,shared:false,type:disk@BOOT_CDROM@} >> > >> devices={index:0,iface:virtio,format:raw,poolID:@SP_UUID@,volumeID- > >> :@VOL_UUID@,imageID:@IMG_UUID@,specParams:{},readonly:false,domain- > >> ID:@SD_UUID@,optional:false,deviceId:@IMG_UUID@,address:{bus:0x00, > >> slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shar- > >> ed:exclusive,propagateErrors:off,type:disk@BOOT_DISK@} >> > >> devices={device:scsi,model:virtio-scsi,type:controller} >> > >> devices={index:4,nicModel:pv,macAddr:02:50:56:3f:c4:b0,linkActive:- > >> true,network:@BRIDGE@,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:@NIC_UUID@,address:{bus:0x00, > >> slot:0x03, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={index:8,nicModel:pv,macAddr:02:50:56:3f:c4:a0,linkActive:- > >> true,network:lan,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:6c467650-1837-47ea-89bc- > >> 1113f4bfefee,address:{bus:0x00, slot:0x09, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={index:16,nicModel:pv,macAddr:02:50:56:3f:c4:c0,linkActive- > >> :true,network:nfs,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:4d8e0705-8cb4-45b7-b960- > >> 7f98bb59858d,address:{bus:0x00, slot:0x0c, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={device:console,specParams:{},type:console,deviceId:@CONSO- > >> LE_UUID@,alias:console0} >> > >> vmName=@NAME@ >> > >> spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,sreco- > >> rd,ssmartcard,susbredir >> > >> smp=@VCPUS@ >> > >> cpuType=@CPU_TYPE@ >> > >> emulatedMachine=@EMULATED_MACHINE@ >> > >> >> > >> but unfortunately the vm gets created like this (output from "ps"; > >> note that I'm attaching a CentOS7.1 Netinstall ISO with an embedded > >> kickstart: the installation should proceed by HTTP on the lan > >> network but obviously fails): >> > >> >> > >> /usr/libexec/qemu-kvm -name HostedEngine -S -machine >> > >> pc-i440fx-rhel7.1.0,accel=kvm,usb=off -cpu Westmere -m 4096 - > >> realtime mlock=off >> > >> -smp 2,sockets=2,cores=1,threads=1 -uuid f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a -s >> > >> mbios type=1,manufacturer=oVirt,product=oVirt Node,version=7- > >> 1.1503.el7.centos.2 >> > >> .8,serial=2a1855a9-18fb-4d7a-b8b8-6fc898a8e827,uuid=f49da721-8aa6- > >> 4422-8b91-e91a >> > >> 0e38aa4a -no-user-config -nodefaults -chardev > >> socket,id=charmonitor,path=/var/li >> > >> b/libvirt/qemu/HostedEngine.monitor,server,nowait -mon > >> chardev=charmonitor,id=mo >> > >> nitor,mode=control -rtc base=2015-10-25T11:22:22,driftfix=slew - > >> global kvm-pit.l >> > >> ost_tick_policy=discard -no-hpet -no-reboot -boot strict=on -device > >> piix3-usb-uh >> > >> ci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi- > >> pci,id=scsi0,bus=pci.0,addr >> > >> =0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 > >> =-drive file= >> > >> /var/tmp/engine.iso,if=none,id=drive-ide0-1- > >> 0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1- > >> 0,bootindex=1 -drive file=/var/run/vdsm/storage/be4434bf-a5fd-44d7-8011- > >> d5e4ac9cf523/b3abc1cb-8a78-4b56-a9b0-e5f41fea0fdc/8d075a8d-730a- > >> 4925-8779-e0ca2b3dbcf4,if=none,id=drive-virtio- > >> disk0,format=raw,serial=b3abc1cb-8a78-4b56-a9b0- > >> e5f41fea0fdc,cache=none,werror=stop,rerror=stop,aio=threads -device > >> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio- > >> disk0,id=virtio-disk0 -netdev > >> tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net- > >> pci,netdev=hostnet0,id=net0,mac=02:50:56:3f:c4:b0,bus=pci.0,addr=0- > >> x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/chan- > >> nels/f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rh- > >> evm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qem- > >> u/channels/f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.gues- > >> t_agent.0 -chardev socket,id=charchannel2,path=/var/lib/libvirt/qe- > >> mu/channels/f49da721-8aa6-4422-8b91-e91a0e38aa4a.org.ovirt.hosted- > >> engine-setup.0,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.ovirt.hos- > >> ted-engine-setup.0 -chardev socket,id=charconsole0,path=/var/run/ovirt-vmconsole- > >> console/f49da721-8aa6-4422-8b91-e91a0e38aa4a.sock,server,nowait - > >> device virtconsole,chardev=charconsole0,id=console0 -vnc > >> 0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -msg > >> timestamp=on >> > >> >> > >> There seem to be no errors in the logs. >> > >> >> > >> I've tried reading some (limited) Python setup code but I've not > >> found any obvious reason why the trick should not work anymore. >> > >> >> > >> I know that 3.6 has different network configuration/management and > >> this could be the hot point. >> > >> >> > >> Does anyone have any further suggestion or clue (code/logs to > >> read)? >> > > >> > > The VM creation path is now a bit different cause we use just vdscli > > library instead of vdsClient. >> > > Please take a a look at mixins.py >> > >> > Many thanks for your very valuable hint: >> > >> > I've restored the original /usr/share/ovirt-hosted-engine- > setup/templates/vm.conf.in and I've managed to obtain the 3-nics- > customized vm by modifying /usr/lib/python2.7/site- > packages/ovirt_hosted_engine_setup/mixins.py like this ("diff -Naur" > output): >> >> Hi Simone, >> it seems that I spoke too soon :( >> >> A separate network issue (already reported to the list) prevented me from successfully closing up the setup in its final phase (registering the host inside the Engine), so all seemed well while being stuck there :) >> >> Now that I've solved that (for which I'm informing the list asap in a separate message) and the setup ended successfully, it seems that the last step of the HE setup (shutdown the Engine vm to place it under HA agent control) starts/creates a "different vm" and my virtual hardware customizations seem to be gone (only one NIC present, connected to ovirtmgmt). >> >> My wild guess: maybe I need BOTH the mixins.py AND the vm.conf.in customizations? ;) > > Yes, you are right: the final configuration is still generated from > the template so you need to fix both. > >> >> It seems (from /etc/ovirt-hosted-engine/hosted-engine.conf) that the Engine vm definition is now in /var/run/ovirt-hosted-engine-ha/vm.conf >> > > > the vm configuration is now read from the shared domain converting > back from the OVF_STORE, the idea is to let you edit it from the > engine without the need to write it on each host. /var/run/ovirt-hosted-engine- > ha/vm.conf is just a temporary copy. > > As you are probably still not able to import the hosted-engine storage > domain in the engine due to a well know bug, your system will fallback > to the initial vm.conf configuration still on the shared storage and > you can manually fix it: Please follow this procedure substituting > '192.168.1.115:_Virtual_ext35u36' with the mount point of hosted- > engine storage domain on your system: > > mntpoint=/rhev/data-center/mnt/192.168.1.115:_Virtual_ext35u36 > dir=`mktemp -d` && cd $dir sdUUID_line=$(grep sdUUID /etc/ovirt-hosted-engine/hosted- > engine.conf) sdUUID=${sdUUID_line:7:36} conf_volume_UUID_line=$(grep > conf_volume_UUID /etc/ovirt-hosted-engine/hosted-engine.conf) > conf_volume_UUID=${conf_volume_UUID_line:17:36} > conf_image_UUID_line=$(grep conf_image_UUID /etc/ovirt-hosted-engine/hosted- > engine.conf) conf_image_UUID=${conf_image_UUID_line:16:36} dd > if=$mntpoint/$sdUUID/images/$conf_image_UUID/$conf_volume_UUID > 2>/dev/null| tar -xvf - > # directly edit vm.conf as you need > tar -cO * | dd > of=$mntpoint/$sdUUID/images/$conf_image_UUID/$conf_volume_UUID > > When your engine will import the hosted-engine storage domain it will > generate an OVF_STORE with the configuration of the engine VM, you > will be able to edit some parameters from the engine and the agent > will read the VM configuration from there. Hi Simone, I followed your advice and modified the vm.conf inside the conf_volume tar archive. Then I put the system (still with only one physical host) in global maintenance from the host: hosted-engine --set-maintenance --mode=global Then i regularly powered off the Engine vm and confirmed it from the host: hosted-engine --vm-status Then restarted it from the host: hosted-engine --vm-start Finally, I exited maintenance from the host: hosted-engine --set-maintenance --mode=none Waited a bit and verified it: hosted-engine --vm-status It all worked as expected! Many thanks again. Regards, Giuseppe > >> >> Many thanks for your assistance (and obviously I just sent a related wishlist item on the HE setup ;) >> >> Regards, >> Giuseppe >> >> >> > *********************************************************************- > *************** >> > >> > --- mixins.py.orig 2015-10-20 16:57:40.000000000 +0200 >> > +++ mixins.py 2015-10-26 22:22:58.351223922 +0100 >> > @@ -25,6 +25,7 @@ >> >import random >> >import string >> >import time >> > +import uuid >> > >> > >> >from ovirt_hosted_engine_setup import constants as ohostedcons >> > @@ -247,6 +248,44 @@ >> >]['@BOOT_PXE@'] == ',bootOrder:1': >> >nic['bootOrder'] = '1' >> >conf['devices'].append(nic) >> > + nic2 = { >> > + 'nicModel': 'pv', >> > + 'macAddr': '02:50:56:3f:c4:a0', >> > + 'linkActive': 'true', >> > + 'network': 'lan', >> > + 'filter': 'vdsm-no-mac-spoofing', >> > + 'specParams': {}, >> > + 'deviceId': str(uuid.uuid4()), >> > + 'address': { >> > + 'bus': '0x00', >> > + 'slot': '0x09', >> > + 'domain': '0x0000', >> > + 'type': 'pci', >> > + 'function': '0x0' >> > + }, >> > + 'device': 'bridge', >> > + 'type': 'interface', >> > + } >> > + conf['devices'].append(nic2) >> > + nic3 = { >> > + 'nicModel': 'pv', >> > + 'macAddr': '02:50:56:3f:c4:c0', >> > + 'linkActive': 'true', >> > + 'network': 'nfs', >> > + 'filter': 'vdsm-no-mac-spoofing', >> > + 'specParams': {}, >> > + 'deviceId': str(uuid.uuid4()), >> > + 'address': { >> > + 'bus': '0x00', >> > + 'slot': '0x0c', >> > + 'domain': '0x0000', >> > + 'type': 'pci', >> > + 'function': '0x0' >> > + }, >> > + 'device': 'bridge', >> > + 'type': 'interface', >> > + } >> > + conf['devices'].append(nic3) >> > >> >cli = self.environment[ohostedcons.VDSMEnv.VDS_CLI] >> >status = cli.create(conf) >> > >> > *********************************************************************- > *************** >> > >> > Obviously this is a horrible ad-hoc hack that I'm not able to generalize/clean- > up now: doing so would involve (apart from a deeper understanding of > the whole setup code/workflow) some well-thought-out design decisions > and, given the effective deprecation of the aforementioned easy-to- > modify vm.conf.in template substituted by hardwired Python program > logic, it seems that such a functionality is not very high on the > development priority list atm ;) >> > >> > Many thanks again! >> > >> > Kind regards, >> > Giuseppe >> > >> > >> Many thanks in advance. >> > >> >> > >> Kind regards, >> > >> Giuseppe >> > >> >> > >> PS: please keep also my address in replying because I'm > >> experiencing some problems between Hotmail and oVirt-mailing- > >> list >> > >> >> > >> _______________________________________________ >> > >> >> > Users mailing list >> > >>Users(a)ovirt.org >> > >>http://lists.ovirt.org/mailman/listinfo/users >> > >>

1 0

Issue with kernel 2.6.32-573.3.1.el6.x86_64?
by Michael Kleinpaste 30 Nov '15

30 Nov '15

So I patched my vhosts and updated the kernel to 2.6.32-573.3.1.el6.x86_64. Afterwards the networking became unstable for my vyatta firewall vm. Lots of packet loss and out of order packets (based on my tshark at the time). Has anybody else experienced this? -- *Michael Kleinpaste* Senior Systems Administrator SharperLending, LLC. www.SharperLending.com Michael.Kleinpaste(a)SharperLending.com (509) 324-1230 Fax: (509) 324-1234

4 7

oVirt 4.0 wishlist: oVirt Engine
by Giuseppe Ragusa 30 Nov '15

30 Nov '15

Hi all, I go on with my wishlist, derived from both solitary mumblings and community talks at the the first Italian oVirt Meetup. I offer to help in coding (work/family schedules permitting) but keep in mind that I'm a sysadmin with mainly C and bash-scripting skills (but hoping to improve my less-than-newbie Python too...) I've sent separate wishlist messages for oVirt Node and VDSM. oVirt Engine: *) add Samba/CTDB/Ganesha capabilities (maybe in the GlusterFS management UI); there are related wishlist items on configuring/managing Samba/CTDB/Ganesha on oVirt Node and on VDSM *) add the ability to manage containers (maybe initially as an exclusive cluster type but allowing it to coexist with GlusterFS); there are related wishlist items on supporting containers on the oVirt Node and on VDSM *) add Open vSwitch direct support (not Neutron-mediated); there are related wishlist items on configuring/managing Open vSwitch on oVirt Node and on VDSM *) add DRBD9 as a supported Storage Domain type, HC/HE too, managed from the Engine UI similarly to GlusterFS; there are related wishlist items on configuring/managing DRBD9 on oVirt Node and on VDSM *) add support for managing/limiting GlusterFS heal/rebalance bandwidth usage in HC setup [1]; this is actually a GlusterFS wishlist item first and foremost, but I hope our use case could be considered compelling enough to "force their hand" a bit ;) Regards, Giuseppe [1] bandwidth limiting seems to be supported only for geo-replication on GlusterFS side; it is my understanding that on non-HC setups the heal/rebalance traffic could be kept separate from hypervisor/client traffic (if a separate, Gluster-only, network is physically available and Gluster cluster nodes have been peer-probed on those network addresses)

1 1

Re: [ovirt-users] Strange permissions on Hosted Engine HA Agent log files
by Giuseppe Ragusa 30 Nov '15

30 Nov '15

On Fri, Nov 27, 2015, at 18:15, Simone Tiraboschi wrote: > > > On Wed, Nov 25, 2015 at 11:53 PM, Giuseppe Ragusa <giuseppe.ragusa(a)hotmail.com> wrote: >> Hi all, >> I'm installing oVirt (3.6) in self-hosted mode, hyperconverged with GlusterFS (3.7.6). >> >> I'm using the oVirt snapshot generated the night between the 18th and 19th of November, 2015. >> >> The (single, at the moment) host and the Engine are both CentOS 7.1 fully up-to-date. >> >> After ovirt-hosted-engine-setup successful completion, I found the following (about 3 days after setup completed) "anomalies": >> >> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log >> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-23 >> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log >> 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-23 >> >> The listing above comes from a custom security checking script that gives: >> >> "octal permissions" "number of links" "owner" "group" - "absolute pathname" >> >> Is the ominous "666" mark actually intended/necessary? ;-) > > Thanks for the report Giuseppe, I double checked on one of my test systems. > > [root@c71het20151028 ~]# ls -l /var/log/ovirt-hosted-engine-ha/* > -rw-r--r--. 1 root root 10136 Nov 27 18:08 /var/log/ovirt-hosted-engine-ha/agent.log > -rw-r--r--. 1 root root 1769029 Oct 29 17:20 /var/log/ovirt-hosted-engine-ha/agent.log.2015-10-28 > -rw-rw-rw-. 1 vdsm kvm 97685 Oct 29 18:21 /var/log/ovirt-hosted-engine-ha/agent.log.2015-10-29 > -rw-r--r--. 1 root root 3620102 Nov 25 12:09 /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-24 > -rw-rw-rw-. 1 vdsm kvm 715086 Nov 25 17:01 /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-25 > -rw-r--r--. 1 root root 13904 Nov 27 18:09 /var/log/ovirt-hosted-engine-ha/broker.log > -rw-r--r--. 1 root root 9711872 Oct 29 17:20 /var/log/ovirt-hosted-engine-ha/broker.log.2015-10-28 > -rw-rw-rw-. 1 vdsm kvm 468475 Oct 29 18:21 /var/log/ovirt-hosted-engine-ha/broker.log.2015-10-29 > -rw-r--r--. 1 root root 14066693 Nov 25 12:09 /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-24 > -rw-rw-rw-. 1 vdsm kvm 4505277 Nov 25 17:01 /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-25 > > > So I've something 644 root:root and something at 666 vdsm:kvm depending from the rotation date (???). > The directory is 700 vdsm:kvm so it's not really an issue but I think it's still worth to open a bug on that. Many thanks Simone for your confirmation: bug opened https://bugzilla.redhat.com/show_bug.cgi?id=1286568 Regards, Giuseppe >> Do I need to open a bugzilla notification for this? >> Many thanks in advance for your attention. >> >> Regards, >> Giuseppe >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users

1 0

ovirt-engine-sdk-python too slow
by John Hunter 30 Nov '15

30 Nov '15

Hi guys, I am using the ovirt-engine-sdk-python to communicate with the ovirt-engine, I am ok to list the vms but the processing time is too long, like 4.5 seconds, and this line: from ovirtsdk.api import API take almost 3 seconds. This seems a little bit longer than I expected it to be, so I am asking is there a quicker way to communicate with the ovirt-engine? -- Best regards Junwang Zhao Department of Computer Science &Technology Peking University Beijing, 100871, PRC

4 14