- Users - oVirt List Archives

Re: [ovirt-users] oVirt 4.0 wishlist: oVirt Self Hosted Engine Setup
by Giuseppe Ragusa 25 Nov '15

25 Nov '15

On Wed, Nov 25, 2015, at 12:13, Simone Tiraboschi wrote: > > > On Mon, Nov 23, 2015 at 10:10 PM, Giuseppe Ragusa <giuseppe.ragusa(a)hotmail.com> wrote: >> 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, oVirt Engine and VDSM. >> >> oVirt Self Hosted Engine Setup: >> >> *) allow virtual hardware customizations for locally-created Engine vm, specifically: allow to add an arbitrary number of NICs (asking for MAC address and local bridge to connect to) and maybe also an arbitrary number of disks (asking for size) as these seem to be the only/most_useful items missing; maybe the prebuilt appliance image too may be inspected by setup to detect a customized one and connect any further NICs to custom local bridges (which the user should be asked for) > > For 3.6.1 (it should be in 3.6.0 but it's bugged) you will be able to edit some parameter of the engine VM from the engine (than of course you need to reboot to make them effective). > I'm not sure if it's worth to make the setup more complex or if it's better to keep it simple (single nic, single disk) and then let you edit the VM only from the engine as for other VMs. Thanks Simone for your reply! You are right: I was bothering you with this setup wishlist item *mainly* because further Engine vm modification was impossible/awkward/difficult before 3.6.1 Nonetheless I have seen many cases in which at least a second NIC would be absolutely needed to complete the Engine installation: it is a well known best practice to keep the management network (maybe conflated with the IPMI network in smaller cases) completely isolated from other services and to allow only limited access to/from it, and that network would be the ovirtmgmt-bridge-connected network (the only one available to the Engine, as of now); now think of a kickstart-based Engine OS installation/update from a local repository/mirror which would be reachable on a different network only (further access to the User/Administration Web portal could have similar needs but could be more easily covered by successive Engine vm modifications) The "additional disks" part was (maybe "artificially") added by me out of fantasy, but I know of at least one enterprise customer that by policy mandates separate disks for OS and data (mainly on FC LUNs, to be honest, but FC is supported by hosted Engine now, isn't it?) I absolutely don't know how the setup code is structured (and the recent logical "duplication" between mixins.py and vm.conf.in scares me a bit, actually ;), but I naively hope that changing the two single hardcoded nic/hdd questions into two loops of minimum 1 iteration (with a corresponding generalization of related otopi parameters) should not increase the complexity too much (and could be an excuse to rationalize/unify it further). Obviously I could stand instantly corrected by anyone who really knows the code, but in exchange I would gain for free some interesting pointers/insights into the setup code/structure ;) >> Regards, >> Giuseppe >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users

1 0

Updated Invitation: [Deep dive] Host Network QoS - oVirt 3.6 @ Wed Dec 2, 2015 5pm - 6pm (ibarkan@redhat.com)
by ibarkan＠redhat.com 25 Nov '15

25 Nov '15

This event has been changed. Title: [Deep dive] Host Network QoS - oVirt 3.6 Hangouts on air: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g you tube link: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g When: Wed Dec 2, 2015 5pm - 6pm Jerusalem (changed) Calendar: ibarkan(a)redhat.com Who: * ibarkan(a)redhat.com - organizer * users(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NGZxZXU0dDRka2ZrMmd1c… 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

Import OVA
by Massimo Mad 25 Nov '15

25 Nov '15

Hi, How i cam inport a virtual appliance (OVA), what should I write in the field "path" ? I try with 10.10.10.73:/export/nfsshare but i have this error: VDSM ovirtsrv102 command failed: ['Permission denied, please try again.', 'Permission denied, please try again.', 'Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).', '/usr/bin/tar: 10.10.10.73\\:/export/nfsshare: Cannot open: Input/output error', '/usr/bin/tar: Error is not recoverable: exiting now'] I try to add the memory on a running vm ad i have this error: Failed to hot set memory to VM CoverterV2V-REL6. Underlying error message: unsupported configuration: unknown device type 'memory' VDSM ovirtsrv104 command failed: unsupported configuration: unknown device type 'memory' Regards Massimo

3 5

[ANN] oVirt 3.6.1 First Release Candidate is now available for testing
by Sandro Bonazzola 25 Nov '15

25 Nov '15

The oVirt Project is pleased to announce the availability of the First Release Candidate of oVirt 3.6.1 for testing, as of November 25th, 2015. 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) and Fedora 22. Highly experimental support for Debian 8.1 Jessie has been added too. This release of oVirt 3.6.1 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. A new oVirt Live ISO is also 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.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [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 1

oVirt Node roadmap
by Fabian Deutsch 25 Nov '15

25 Nov '15

Hey, in the last few months the Node team spent a lot of efforts in stabilizing Node by closing tons of bugs, rebasing Node onto CentOS 7.2, and in addition adding features like Hosted-Engine - to get Node in shape for the recently released oVirt 3.6.0. But we were also seeing how Node is showing it's age. It becomes more and more challenging to solve bugs and implement features in Node's current architecture. To address these problems, and let Node adjust better to new changes, a few months ago we started to look at how we can change Node, to make it easier to develop, test, and use. This comparison [1] shows a brief summary of our investigations. We especially looked at Atomic and containers [2]. At the bottom line both of them provided us an architecture which would help us to achieve something like 70% of what we need. But during early trials we quickly ran into issues which we experience in similar ways with today's Node. Finally we settled an approach - the idea was around since right from the beginning - which aligns very well with existing technologies which we already use in the oVirt and Fedora/CentOS scope. The new Node will be using anaconda for installation, LVM for upgrades and rollbacks, and Cockpit [3] for administration. The future design is taking care that packages don't need to take special care to work on Node - which was a major obstacle in the past. Node will rather behave (mostly) like a regular host - but with the advantages of an easy & ready to use image, image based delivery and a robust rollback. The current design principles and links to some additional resources are in the wiki [4]. Stay tuned, we are just getting started. On behalf of the Node Team fabian -- [1] http://www.ovirt.org/Node/Specs#Comparison:_Possible_Implementations [2] http://www.projectatomic.io/ ~ http://docker.com/ [3] http://cockpit-project.org/ [4] http://www.ovirt.org/Node/4.0

1 0

Re: [ovirt-users] 3.6 master hosted engine setup error
by Gianluca Cecchi 25 Nov '15

25 Nov '15

On Tue, Nov 17, 2015 at 6:29 PM, Simone Tiraboschi wrote: > > > On Tue, Nov 17, 2015 at 5:04 PM, Gianluca Cecchi wrote: > >> >> >> Yes, I know. No problem for me. >> I'm using master because I want to test Italian layout so that I can >> change current translation where necessary. >> But do I have to start from scratch or is there any command to clean the >> current half-completed setup? >> > > No, unfortunately is still not available for hosted-engine-setup > > >> >> Gianluca >> >> > Hello, retrying from master, as the problem solution should have been merged. But it seems the package for the appliance is not available now... [root@ovc71 ~]# yum install ovirt-engine-appliance Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile * base: mi.mirror.garr.it * extras: mi.mirror.garr.it * ovirt-master-epel: fr2.rpmfind.net * ovirt-master-snapshot: ftp.plusline.net * ovirt-master-snapshot-static: ftp.plusline.net * updates: mi.mirror.garr.it No package ovirt-engine-appliance available. Error: Nothing to do Any alternative manually downloading the ova file or other strategy? Gianluca

2 5

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

25 Nov '15

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_UUID@,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,domainID:@SD_UUID@,optional:false,deviceId:@IMG_UUID@,address:{bus:0x00, slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shared: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:@CONSOLE_UUID@,alias:console0} >> vmName=@NAME@ >> spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,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=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/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.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/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.guest_agent.0 -chardev socket,id=charchannel2,path=/var/lib/libvirt/qemu/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.hosted-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): ************************************************************************************ --- 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 >>

2 2

Problem with Adding Pre-Configured Domain
by Roger Meier 25 Nov '15

25 Nov '15

This is a multi-part message in MIME format. --------------050208060806020800020208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi All, I don't know if this is a Bug or an error on my side. At the moment, i have a oVirt 3.6 installation with two Nodes and Two Storage Server, which are configured themselfs als master/slave (solaris zfs snapshot copy from master to slave all 2 hours) Now i try to do some tests for some failure use cases like, master storage isn't available anymore or one of the virtual machines must be restored from the snapshot. Because the data n the slave is a snapshot copy, all data which are on the Data Domain NFS Storage, are also on the slave NFS Storage. I tried it to add over WebUI over the option "Import Domain" (Import Pre-Configured Domain) with both Domain Functions (Data and Export) but nothing happens, expect some errors in the vdsm.log Logfile. Something like this Thread-253746::ERROR::2015-11-24 11:44:41,758::hsm::2549::Storage.HSM::(disconnectStorageServer) Could not disconnect from storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2545, in disconnectStorageServer conObj.disconnect() File "/usr/share/vdsm/storage/storageServer.py", line 425, in disconnect return self._mountCon.disconnect() File "/usr/share/vdsm/storage/storageServer.py", line 254, in disconnect self._mount.umount(True, True) File "/usr/share/vdsm/storage/mount.py", line 256, in umount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';umount: /rhev/data-center/mnt/192.168.1.13:_oi-srv2-sasData1_oi-srv1-sasData1_nfsshare1: mountpoint not found\n') I checked with nfs-check.py if all permissions are ok, the tool say this: Konsole output [root@lin-ovirt1 contrib]# python ./nfs-check.py 192.168.1.13:/oi-srv2-sasData1/oi-srv1-sasData1/nfsshare1 Current hostname: lin-ovirt1 - IP addr 192.168.1.14 Trying to /bin/mount -t nfs 192.168.1.13:/oi-srv2-sasData1/oi-srv1-sasData1/nfsshare1... Executing NFS tests.. Removing vdsmTest file.. Status of tests [OK] Disconnecting from NFS Server.. Done! Greetings Roger Meier --------------050208060806020800020208 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi All, I don't know if this is a Bug or an error on my side. At the moment, i have a oVirt 3.6 installation with two Nodes and Two Storage Server, which are configured themselfs als master/slave (solaris zfs snapshot copy from master to slave all 2 hours) Now i try to do some tests for some failure use cases like, master storage isn't available anymore or one of the virtual machines must be restored from the snapshot. Because the data n the slave is a snapshot copy, all data which are on the Data Domain NFS Storage, are also on the slave NFS Storage. I tried it to add over WebUI over the option "Import Domain" (Import Pre-Configured Domain) with both Domain Functions (Data and Export) but nothing happens, expect some errors in the vdsm.log Logfile. Something like this Thread-253746::ERROR::2015-11-24 11:44:41,758::hsm::2549::Storage.HSM::(disconnectStorageServer) Could not disconnect from storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2545, in disconnectStorageServer conObj.disconnect() File "/usr/share/vdsm/storage/storageServer.py", line 425, in disconnect return self._mountCon.disconnect() File "/usr/share/vdsm/storage/storageServer.py", line 254, in disconnect self._mount.umount(True, True) File "/usr/share/vdsm/storage/mount.py", line 256, in umount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';umount: /rhev/data-center/mnt/192.168.1.13:_oi-srv2-sasData1_oi-srv1-sasData1_nfsshare1: mountpoint not found\n') I checked with nfs-check.py if all permissions are ok, the tool say this: <title>Konsole output</title> <div> [root@lin-ovirt1 contrib]# python ./nfs-check.py 192.168.1.13:/oi-srv2-sasData1/oi-srv1-sasData1/nfsshare1 Current hostname: lin-ovirt1 - IP addr 192.168.1.14 Trying to /bin/mount -t nfs 192.168.1.13:/oi-srv2-sasData1/oi-srv1-sasData1/nfsshare1... Executing NFS tests.. Removing vdsmTest file.. Status of tests [OK] Disconnecting from NFS Server.. Done! </div> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Greetings Roger Meier </body> </html> --------------050208060806020800020208--

2 2

Move cluster between datacenters
by Dael Maselli 24 Nov '15

24 Nov '15

Hello, I have an environment with two data centers with some clusters in each one. Each cluster has one or more dedicated FC storage domains. We have some management problem because adding storage to one cluster means to add it to all nodes of all clusters in the same data center, by the way I found this a little overkill and I think it should be managed like networks. Anyway, to resolve out problems we would like to create a new datacenter and move a cluster from old data center to the new one, obviously with it's own storage domain. Is there a way to do this without export/import all vms? Thank you. Regards, Dael Maselli. -- ___________________________________________________________________ Dael Maselli --- INFN-LNF Computing Service -- +39.06.9403.2214 ___________________________________________________________________ * http://www.lnf.infn.it/~dmaselli/ * ___________________________________________________________________ Democracy is two wolves and a lamb voting on what to have for lunch ___________________________________________________________________

2 1

oVirt 4.0 wishlist: oVirt Node
by Giuseppe Ragusa 24 Nov '15

24 Nov '15

Hi all, I'm trying to organize my wishes/hopes for oVirt 4.0 These items derive 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...) Since I have related interests/wishes also for Engine and VDSM, I'll send a separate message for each one. Let's start from the oVirt Node: *) oVirt Node complete convergence with Atomic Host: start from Project Atomic tools and define an ISO-installable Atomic Host variant [1] to include gluster, qemu, libvirt, vdsm and all the packages/configurations that an oVirt Node would need (remove unneeded parts) *) add Samba, CTDB and Ganesha to oVirt Node to allow it to be used as a full storage appliance (specifically, I'm thinking of the GlusterFS integration); there are related wishlist items on configuring/managing Samba/CTDB/Ganesha on the Engine and on VDSM *) add oVirt Node ability to host containers (independent of the above mentioned convergence with Atomic); note that Atomic Host has Docker/Kubernetes, but libvirt already has a LXC driver [2] and the Engine could benefit from some added smartness in managing groups of guests etc. in the vm case too; there are related wishlist items on configuring/managing containers on the Engine and on VDSM *) add Open vSwitch direct support (not Neutron-mediated); there are related wishlist items on configuring/managing Open vSwitch on the Engine and on VDSM *) add DRBD9 as a supported Storage Domain type, maybe for HC and HE too; there are related wishlist items on configuring/managing DRBD9 on the Engine and on VDSM *) add oVirt Node ability to fully perform as a stand-alone hypervisor: I hear that Cockpit is coming, so why not Kimchi too? ;) Regards, Giuseppe [1] product.json, I suppose, but I'm starting to learn Atomic now... [2] barring a pending deprecation in RHEL7, but I suppose that a community/Centos-Virt-SIG libvirt build could restore it and maybe RedHat too could support it on a special libvirt build for RHEV (just to remove those support costs from the base RHEL OS offering)

3 2