- Users - oVirt List Archives

Re: [ovirt-users] Failed deply of ovirt-engine using ovirt-node-ng-installer-ovirt-4.2-pre-2017120512.iso
by Simone Tiraboschi 11 Dec '17

11 Dec '17

On Wed, Dec 6, 2017 at 11:38 AM, Roberto Nunin <robnunin(a)gmail.com> wrote: > Ciao Simone > thanks for really quick answer. > > 2017-12-06 11:05 GMT+01:00 Simone Tiraboschi <stirabos(a)redhat.com>: > >> Ciao Roberto, >> >> On Wed, Dec 6, 2017 at 10:02 AM, Roberto Nunin <robnunin(a)gmail.com> >> wrote: >> >>> I'm having trouble to deploy one three host hyperconverged lab using >>> iso-image named above. >>> >> >> Please note that ovirt-node-ng-installer-ovirt-4.2-pre-2017120512 >> <(201)%20712-0512>.iso is still a pre-release software. >> Your contribute testing it is really appreciated! >> > > It's a pleasure !. > > >> >> >> >>> >>> My test environment is based on HPE BL680cG7 blade servers. >>> These servers has 6 physical 10GB network interfaces (flexNIC), each one >>> with four profiles (ethernet,FCoE,iSCSI,etc). >>> >>> I choose one of these six phys interfaces (enp5s0f0) and assigned it a >>> static IPv4 address, for each node. >>> >>> After node reboot, interface ONBOOT param is still set to no. >>> Changed via iLO interface to yes and restarted network. Fine. >>> >>> After gluster setup, with gdeploy script under Cockpit interface, >>> avoiding errors coming from : >>> /usr/share/gdepply/scripts/blacklist_all_disks.sh, start hosted-engine >>> deploy. >>> >>> With the new version, I'm having an error never seen before: >>> >>> The Engine VM (10.114.60.117) and this host (10.114.60.134/24) will not >>> be in the same IP subnet. Static routing configuration are not supported on >>> automatic VM configuration. >>> Failed to execute stage 'Environment customization': The Engine VM >>> (10.114.60.117) and this host (10.114.60.134/24) will not be in the >>> same IP subnet. Static routing configuration are not supported on automatic >>> VM configuration. >>> Hosted Engine deployment failed. >>> >>> There's no input field for HE subnet mask. Anyway in our class-c ovirt >>> management network these ARE in the same subnet. >>> How to recover from this ? I cannot add /24 CIDR in HE Static IP address >>> field, it isn't allowed. >>> >> >> 10.114.60.117 and 10.114.60.134/24 are in the same IPv4 /24 subnet so it >> should't fail. >> The issue here seams different: >> >> From hosted-engine-setup log I see that you passed the VM IP address via >> answerfile: >> 2017-12-06 09:14:30,195+0100 DEBUG otopi.context >> context.dumpEnvironment:831 ENV OVEHOSTED_VM/cloudinitVMStatic >> CIDR=str:'10.114.60.117' >> >> while the right syntax should be: >> OVEHOSTED_VM/cloudinitVMStaticCIDR=str:10.114.60.117/24 >> >> Did you wrote the answerfile by yourself or did you entered the IP >> address in the cockpit wizard? if so we probably have a regression there. >> > > I've inserted it while providing data for setup, using Cockpit interface. > Tried to add CIDR (/24), but it isn't allowed from Cockpit web interface. > No manual update of answer file. > >> >> >> >>> >>> Moreover, VM FQDN is asked two times during the deploy process. It's >>> correct ? >>> >> >> No, I don't think so but I don't see it from you logs. >> Could you please explain it? >> > > Yes: first time is requested during initial setup of HE VM deploy > > The second one, instead, is asked (at least to me ) in this step, after > initial setup: > So both on cockpit side? > > [image: Immagine incorporata 1] > >> >> >>> >>> Some additional, general questions: >>> NetworkManager: must be disabled deploying HCI solution ? In my attempt, >>> wasn't disabled. >>> >> > Simone, could you confirm or not that NM must stay in place while > deploying ? This qustion was struggling since 3.6...... what is the "best > practice" ? > All of mine RHV environments (3.6 - 4.0.1 - 4.1.6 ) have it disabled, but > I wasn't able to find any mandatory rule. > In early 3.6 you had to disable it but now you can safely keep it on. > > >> There's some document to follow to perform a correct deploy ? >>> Is this one still "valid" ? : https://ovirt.org/blog/2017/ >>> 04/up-and-running-with-ovirt-4.1-and-gluster-storage/ >>> >>> Attached hosted-engine-setup log. >>> TIA >>> >>> >>> >>> -- >>> Roberto >>> 110-006-970 >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> > > > -- > Roberto Nunin > > > >

3 12

Re: [ovirt-users] 4-2rc hosted-engine don't boot error:cannot allocate kernel buffer
by Maton, Brett 11 Dec '17

11 Dec '17

Really short version ( I can't find the link to the ovirt doc at the moment) Put hosted engine in to global maintenance and power off the vm (hosted-engine command). On one of your physical hosts, make a copy of he config and update the memory cp /var/run/ovirt-hosted-engine-ha/vm.conf . vim vm.conf Then start hosted engine with the new config hosted-engine --vm-start --vm-conf=./vm.conf On 11 December 2017 at 10:36, Roberto Nunin <robnunin(a)gmail.com> wrote: > > > 2017-12-11 10:32 GMT+01:00 Maton, Brett <matonb(a)ltresources.co.uk>: > >> Hi Roberto can you check how much RAM is allocated to the HE VM ? >> >> >> virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf >> >> virsh # dominfo HostedEngine >> >> >> The last update I did seems to have changed the HE RAM from 4GB to 4MB! >> > > > Yes, you're right...... > > virsh # dominfo HostedEngine > Id: 191 > Name: HostedEngine > UUID: 6831dd96-af48-4673-ac98-f1b9ba60754b > OS Type: hvm > State: running > CPU(s): 4 > CPU time: 9053.7s > Max memory: 4096 KiB > Used memory: 4096 KiB > Persistent: yes > Autostart: disable > Managed save: no > Security model: selinux > Security DOI: 0 > Security label: system_u:system_r:svirt_t:s0:c201,c408 (enforcing) > > >> >> On 11 December 2017 at 09:08, Simone Tiraboschi <stirabos(a)redhat.com> >> wrote: >> >>> >>> >>> On Mon, Dec 11, 2017 at 9:47 AM, Roberto Nunin <robnunin(a)gmail.com> >>> wrote: >>> >>>> Hello all >>>> >>>> during weekend, I've re-tried to deploy my 4.2_rc lab. >>>> Everything was fine, apart the fact host 2 and 3 weren't imported. I >>>> had to add them to the cluster manually, with the NEW function. >>>> After this Gluster volumes were added fine to the environment. >>>> >>>> Next engine deploy on nodes 2 and 3, ended with ok status. >>>> >>>> Tring to migrate HE from host 1 to host 2 was fine, the same from host >>>> 2 to host 3. >>>> >>>> After these two attempts, no way to migrate HE back to any host. >>>> Tried Maintenance mode set to global, reboot the HE and now I'm in the >>>> same condition reported below, not anymore able to boot the HE. >>>> >>>> Here's hosted-engine --vm-status: >>>> >>>> !! Cluster is in GLOBAL MAINTENANCE mode !! >>>> >>>> >>>> >>>> --== Host 1 status ==-- >>>> >>>> conf_on_shared_storage : True >>>> Status up-to-date : True >>>> Hostname : aps-te61-mng.example.com >>>> Host ID : 1 >>>> Engine status : {"reason": "vm not running on this >>>> host", "health": "bad", "vm": "down", "detail": "unknown"} >>>> Score : 3400 >>>> stopped : False >>>> Local maintenance : False >>>> crc32 : 7dfc420b >>>> local_conf_timestamp : 181953 >>>> Host timestamp : 181952 >>>> Extra metadata (valid at timestamp): >>>> metadata_parse_version=1 >>>> metadata_feature_version=1 >>>> timestamp=181952 (Mon Dec 11 09:21:46 2017) >>>> host-id=1 >>>> score=3400 >>>> vm_conf_refresh_time=181953 (Mon Dec 11 09:21:47 2017) >>>> conf_on_shared_storage=True >>>> maintenance=False >>>> state=GlobalMaintenance >>>> stopped=False >>>> >>>> >>>> --== Host 2 status ==-- >>>> >>>> conf_on_shared_storage : True >>>> Status up-to-date : True >>>> Hostname : aps-te64-mng.example.com >>>> Host ID : 2 >>>> Engine status : {"reason": "vm not running on this >>>> host", "health": "bad", "vm": "down", "detail": "unknown"} >>>> Score : 3400 >>>> stopped : False >>>> Local maintenance : False >>>> crc32 : 67c7dd1d >>>> local_conf_timestamp : 181946 >>>> Host timestamp : 181946 >>>> Extra metadata (valid at timestamp): >>>> metadata_parse_version=1 >>>> metadata_feature_version=1 >>>> timestamp=181946 (Mon Dec 11 09:21:49 2017) >>>> host-id=2 >>>> score=3400 >>>> vm_conf_refresh_time=181946 (Mon Dec 11 09:21:49 2017) >>>> conf_on_shared_storage=True >>>> maintenance=False >>>> state=GlobalMaintenance >>>> stopped=False >>>> >>>> >>>> --== Host 3 status ==-- >>>> >>>> conf_on_shared_storage : True >>>> Status up-to-date : True >>>> Hostname : aps-te68-mng.example.com >>>> Host ID : 3 >>>> Engine status : {"reason": "failed liveliness >>>> check", "health": "bad", "vm": "up", "detail": "Up"} >>>> Score : 3400 >>>> stopped : False >>>> Local maintenance : False >>>> crc32 : 4daea041 >>>> local_conf_timestamp : 181078 >>>> Host timestamp : 181078 >>>> Extra metadata (valid at timestamp): >>>> metadata_parse_version=1 >>>> metadata_feature_version=1 >>>> timestamp=181078 (Mon Dec 11 09:21:53 2017) >>>> host-id=3 >>>> score=3400 >>>> vm_conf_refresh_time=181078 (Mon Dec 11 09:21:53 2017) >>>> conf_on_shared_storage=True >>>> maintenance=False >>>> state=GlobalMaintenance >>>> stopped=False >>>> >>>> >>>> !! Cluster is in GLOBAL MAINTENANCE mode !! >>>> >>>> (it is in global maintenance to avoid messages to be sent to admin >>>> mailbox). >>>> >>> >>> As soon as you exit the global maintenance mode, one of the hosts should >>> take care of automatically restarting the engine VM within a couple of >>> minutes. >>> >>> If you want to manually start the engine VM over a specific host while >>> in maintenance mode you can use: >>> hosted-engine --vm-start >>> on the specific host >>> >>> >>>> >>>> Engine image is available on all three hosts, gluster is working fine: >>>> >>>> Volume Name: engine >>>> Type: Replicate >>>> Volume ID: 95355a0b-1f45-4329-95c7-604682e812d0 >>>> Status: Started >>>> Snapshot Count: 0 >>>> Number of Bricks: 1 x 3 = 3 >>>> Transport-type: tcp >>>> Bricks: >>>> Brick1: aps-te61-mng.example.com:/gluster_bricks/engine/engine >>>> Brick2: aps-te64-mng.example.com:/gluster_bricks/engine/engine >>>> Brick3: aps-te68-mng.example.com:/gluster_bricks/engine/engine >>>> Options Reconfigured: >>>> nfs.disable: on >>>> transport.address-family: inet >>>> performance.quick-read: off >>>> performance.read-ahead: off >>>> performance.io-cache: off >>>> performance.low-prio-threads: 32 >>>> network.remote-dio: off >>>> cluster.eager-lock: enable >>>> cluster.quorum-type: auto >>>> cluster.server-quorum-type: server >>>> cluster.data-self-heal-algorithm: full >>>> cluster.locking-scheme: granular >>>> cluster.shd-max-threads: 8 >>>> cluster.shd-wait-qlength: 10000 >>>> features.shard: on >>>> user.cifs: off >>>> storage.owner-uid: 36 >>>> storage.owner-gid: 36 >>>> network.ping-timeout: 30 >>>> performance.strict-o-direct: on >>>> cluster.granular-entry-heal: enable >>>> features.shard-block-size: 64MB >>>> >>>> Engine qemu image seems to be ok: >>>> >>>> [root@aps-te68-mng 9998de26-8a5c-4495-b450-c8dfc1e016da]# l >>>> total 2660796 >>>> -rw-rw----. 1 vdsm kvm 53687091200 Dec 8 17:22 >>>> 35ac0f88-e97d-4710-a385-127c751a3190 >>>> -rw-rw----. 1 vdsm kvm 1048576 Dec 11 09:04 >>>> 35ac0f88-e97d-4710-a385-127c751a3190.lease >>>> -rw-r--r--. 1 vdsm kvm 285 Dec 8 11:19 >>>> 35ac0f88-e97d-4710-a385-127c751a3190.meta >>>> [root@aps-te68-mng 9998de26-8a5c-4495-b450-c8dfc1e016da]# qemu-img >>>> info 35ac0f88-e97d-4710-a385-127c751a3190 >>>> image: 35ac0f88-e97d-4710-a385-127c751a3190 >>>> file format: raw >>>> virtual size: 50G (53687091200 bytes) >>>> disk size: 2.5G >>>> [root@aps-te68-mng 9998de26-8a5c-4495-b450-c8dfc1e016da]# >>>> >>>> Attached agent and broker logs from the last host where HE startup was >>>> attempted. Only last two hours. >>>> >>>> Any hint to perform further investigation ? >>>> >>>> Thanks in advance. >>>> >>>> Environment: 3 HPE Proliant BL680cG7, OS on mirrored volume 1, gluster >>>> on mirrored volume 2, 1 TB for each server. >>>> Multiple network adapters (6), configured only one. >>>> I've used last ovirt-node-ng iso image : ovirt-node-ng-installer-ovirt- >>>> 4.2-pre-2017120512 <(201)%20712-0512>.iso and >>>> ovirt-hosted-engine-setup-2.2.1-0.0.master.20171206123553.git94f4c9e.el7.centos.noarch >>>> to work around HE static ip address not masked correctly. >>>> >>>> >>>> -- >>>> Roberto >>>> >>>> 2017-12-07 12:44 GMT+01:00 Roberto Nunin <robnunin(a)gmail.com>: >>>> >>>>> Hi >>>>> >>>>> after successfully deployed fresh 4.2_rc with ovirt node, I'm facing >>>>> with a blocking problem. >>>>> >>>>> hosted-engine won't boot. Reaching the console via vnc hook, I can see >>>>> that it is at initial boot screen, but for any OS release available, I >>>>> receive: >>>>> >>>>> [image: Immagine incorporata 1] >>>>> then >>>>> [image: Immagine incorporata 2] >>>>> >>>>> googling around, I'm not able to find suggestions. Any hints ? >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> Roberto >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> > > > -- > Roberto Nunin > > >

2 1

4-2rc hosted-engine don't boot error:cannot allocate kernel buffer
by Roberto Nunin 11 Dec '17

11 Dec '17

Hi after successfully deployed fresh 4.2_rc with ovirt node, I'm facing with a blocking problem. hosted-engine won't boot. Reaching the console via vnc hook, I can see that it is at initial boot screen, but for any OS release available, I receive: [image: Immagine incorporata 1] then [image: Immagine incorporata 2] googling around, I'm not able to find suggestions. Any hints ? Thanks -- Roberto

4 4

Best Practice Question: How many engines, one or more than one, for multiple physical locations
by Matt Simonsen 11 Dec '17

11 Dec '17

Hello all, I read with Gluster using hyper-convergence that the engine must reside on the same LAN as the nodes. I guess this makes sense by definition - ie: using Gluster storage and replicating Gluster bricks across the web sounds awful. This got me wondering about best practices for the engine setup. We have multiple physical locations (co-location data centers). In my initial plan I had expected to have my oVirt engine hosted separately from each physical location so that in the event of trouble at a remote facility the engine would still be usable. In this case, our prod sites would not have a "hyper-converged" setup if we decide to run GlusterFS for storage at any particular physical site, but I believe it would still be possible to use Gluster. In this case oVirt would have a 3 node cluster, using GlusterFS storage, but not hyper-converged since the engine would be in a separate facility. Is there any downside in this setup to having the engine off-site? Rather than having an off-site engine, should I consider one engine per physical co-location space? Thank you all for any feedback, Matt

2 1

Scheduling daily Snapshot
by Jason Lelievre 08 Dec '17

08 Dec '17

Hello, What is the best way to set up a daily live snapshot for all VM, and have the possibility to recover, for example, a specific VM to a specific day? I use a Hyperconverged Infrastructure with 3 nodes, gluster storage. Thank you,

6 6

slow performance with export storage on glusterfs
by Jiří Sléžka 08 Dec '17

08 Dec '17

This is a cryptographically signed message in MIME format. --------------ms020509020901010502070100 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, I am trying realize why is exporting of vm to export storage on glusterfs such slow. I am using oVirt and RHV, both instalations on version 4.1.7. Hosts have dedicated nics for rhevm network - 1gbps, data storage itself is on FC. GlusterFS cluster lives separate on 4 dedicated hosts. It has slow disks but I can achieve about 200-400mbit throughput in other applications (we are using it for "cold" data, backups mostly). I am using this glusterfs cluster as backend for export storage. When I am exporting vm I can see only about 60-80mbit throughput. What could be the bottleneck here? Could it be qemu-img utility? vdsm 97739 0.3 0.0 354212 29148 ? S<l 15:43 0:06 /usr/bin/qemu-img convert -p -t none -T none -f raw /rhev/data-center/2ff6d0ee-a10b-473d-b77c-be9149945f5f/ff3cd56a-1005-4426= -8137-8f422c0b47c1/images/ba42cbcc-c068-4df8-af3d-00f2077b1e27/c57acd5f-d= 6cf-48cc-ad0c-4a7d979c0c1e -O raw /rhev/data-center/mnt/glusterSD/10.20.30.41:_rhv__export/81094499-a392-4e= a2-b081-7c6288fbb636/images/ba42cbcc-c068-4df8-af3d-00f2077b1e27/c57acd5f= -d6cf-48cc-ad0c-4a7d979c0c1e Any idea how to make it work faster or what throughput should I expected?= Cheers, Jiri --------------ms020509020901010502070100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cn8wggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVuMIIEVqADAgECAhAKebGg8bOvnIyfOWAn4bpzMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTcxMTE2MDAwMDAwWhcNMTgxMjE1MTIwMDAwWjCBlDETMBEGCgmSJomT8ixkARkWA29y ZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEGCgmSJomT8ixkARkWA3RjczELMAkGA1UE BhMCQ1oxJTAjBgNVBAoTHFNpbGVzaWFuIFVuaXZlcnNpdHkgaW4gT3BhdmExHDAaBgNVBAMT E0ppcmkgU2xlemthIHNsZTAwMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/ VwOD1hlYL6l7GzxNqV1ne7/iMF/gHvPfTwejsC2s9sby7It82qXPRBVA2s1Cjb1A3ucpdlDN MXM83Lvh881XfkxhS2YLLyiZDmlSzAqfoMLxQ2/E0m1UugttzGJF7/10pEwj0FJFhnIVwA/E 8svCcbhxwO9BBpUz8JG1C6fTd0qyzJtNXVyH+WuHQbU2jgu2JJ7miiEKE1Fis0hFf1rKxTzX aVGyXiQLOn7TZDfPtXrJEG7eWYlFUP58edyuJELpWHTPHn8xJKYTy8Qq5BgFNyCRQT/6imsh tZlDBZSEeqyoSNtLsC57ZrjqgtLCEQFK9EX27dOy0/u95zS0OIWdAgMBAAGjggHbMIIB1zAf BgNVHSMEGDAWgBSMnxEu5uN6BKUeVYtGCASm7ZdwpjAdBgNVHQ4EFgQUF1mSlcyDz9wWit9V jCz+zJ9CrpswDAYDVR0TAQH/BAIwADAdBgNVHREEFjAUgRJqaXJpLnNsZXprYUBzbHUuY3ow DgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA0BgNVHSAE LTArMAwGCiqGSIb3TAUCAgEwDAYKYIZIAYb9bAQfATANBgsqhkiG90wFAgMDAzCBhQYDVR0f BH4wfDA8oDqgOIY2aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL1RFUkVOQWVTY2llbmNlUGVy c29uYWxDQTMuY3JsMDygOqA4hjZodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVEVSRU5BZVNj aWVuY2VQZXJzb25hbENBMy5jcmwwewYIKwYBBQUHAQEEbzBtMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRQYIKwYBBQUHMAKGOWh0dHA6Ly9jYWNlcnRzLmRpZ2lj ZXJ0LmNvbS9URVJFTkFlU2NpZW5jZVBlcnNvbmFsQ0EzLmNydDANBgkqhkiG9w0BAQsFAAOC AQEADtFRxKphkcHVdWjR/+i1+cdHfkbicraHlU5Mpw8EX6nemKu4GGAWfzH+Y7p6ImZwUHWf /SSbrX+57xaFUBOr3jktQm1GRmGUZESEmsUDB8UZXzdQC79/tO9MzRhvEBXuQhdxdoO64Efx VqtYAB2ydqz7yWh56ioSwaQZEXo5rO1kZuAcmVz8Smd1r/Mur/h8Y+qbrsJng1GS25aMhFts UV6z9zXuHFkT9Ck8SLdCEDzjzYNjXIDB5n+QOmPXnXrZMlGiI/aOqa5k5Sv6xCIPdH2kbpyd M1YiH/ChmU9gWJvy0Jq42KGLvWBvuHEzcb3f473Fvn4GWsXu0zDS2oh2/TGCA8MwggO/AgEB MIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlB bXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBl cnNvbmFsIENBIDMCEAp5saDxs6+cjJ85YCfhunMwDQYJYIZIAWUDBAIBBQCgggINMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTEyMDE1MjAzM1owLwYJ KoZIhvcNAQkEMSIEILmfZ4a/vSZv57MxXgCAPwjxh9wMgWdW8v78HTqqQ3zIMGwGCSqGSIb3 DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZcGCSsG AQQBgjcQBDGBiTCBhjByMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDES MBAGA1UEBxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExJjAkBgNVBAMTHVRFUkVOQSBl U2NpZW5jZSBQZXJzb25hbCBDQSAzAhAKebGg8bOvnIyfOWAn4bpzMIGZBgsqhkiG9w0BCRAC CzGBiaCBhjByMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQtSG9sbGFuZDESMBAGA1UE BxMJQW1zdGVyZGFtMQ8wDQYDVQQKEwZURVJFTkExJjAkBgNVBAMTHVRFUkVOQSBlU2NpZW5j ZSBQZXJzb25hbCBDQSAzAhAKebGg8bOvnIyfOWAn4bpzMA0GCSqGSIb3DQEBAQUABIIBAGii FiUp6Lb3R5JRu32BeDHrAGBL8Ym2pCdXh8zv4dYs3Q3dd/SQHkif4Z3qysUHfPAEQ2gz7N4C W7ALZjblD0RZRy5JlrzGLfCmruPBKmU/cLIAYZk2v78+aEjgi8oiZHSLnhIwCRQheQtxK7rG O8qkWpqZ2jmCstaBlj8kbpVb4WvNC7EbtEJLjXTP4rKAET2daeZdLqPaLx6eYND3l10GymKV k4KLh0o638Eh3fmBLIncOh79nuURZl5Q6K7bflEQacQEzWDw9+9fGf5vWc8FzTzrn6w9RPwZ NCcAVdR8SAU274u0cFWPnj+UywsJRKywJ31UWbQGU8ONy7MsAoAAAAAAAAA= --------------ms020509020901010502070100--

8 13

Best practice for iSCSI storage domains
by Richard Chan 07 Dec '17

07 Dec '17

What is the best practice for iSCSI storage domains: Many small targets vs a few large targets? Specific example: if you wanted a 8TB storage domain would you prepare a single 8TB LUN or (for example) 8 x 1 TB LUNs. -- Richard Chan

5 4

Failed Install - oVirt Node "ovirt-node-ng-installer-ovirt-4.1-2017120607"
by andreil1 07 Dec '17

07 Dec '17

Hi, I have strange error of oVrt node install "ovirt-node-ng-installer-ovirt-4.1-2017120607” on HP ProLiant ML350 G6 with hardware RAID5 3.6TB just after startup and language selection: anaconda 21.48.22.121-1 traceback … …./parted/disk.py, line 246 in add partition …. partition exception: unable to satisfy all constraints on the partition I started this server with OpenSuSE Leap 42.3 DVD, RAID 5 volume is being seen correctly by partitioner as unformatted. Installing CentOS 7 results in same error when automatic partitioning selected. May be for whatever reason installer can’t load “hpsa” module ? How to solve this problem ? Thanks in advance Andrei

2 1

critical production issue for a vm
by Nathanaël Blanchet 07 Dec '17

07 Dec '17

Hi all, I'm about to lose one very important vm. I shut down this vm for maintenance and then I moved the four disks to a new created lun. This vm has 2 snapshots. After successful move, the vm refuses to start with this message: Bad volume specification {u'index': 0, u'domainID': u'961ea94a-aced-4dd0-a9f0-266ce1810177', 'reqsize': '0', u'format': u'cow', u'bootOrder': u'1', u'discard': False, u'volumeID': u'a0b6d5cb-db1e-4c25-aaaf-1bbee142c60b', 'apparentsize': '2147483648', u'imageID': u'4a95614e-bf1d-407c-aa72-2df414abcb7a', u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', u'optional': u'false', u'deviceId': u'4a95614e-bf1d-407c-aa72-2df414abcb7a', 'truesize': '2147483648', u'poolID': u'48ca3019-9dbf-4ef3-98e9-08105d396350', u'device': u'disk', u'shared': u'false', u'propagateErrors': u'off', u'type': u'disk'}. I tried to merge the snaphots, export , clone from snapshot, copy disks, or deactivate disks and every action fails when it is about disk. I began to dd lv group to get a new vm intended to a standalone libvirt/kvm, the vm quite boots up but it is an outdated version before the first snapshot. There is a lot of disks when doing a "lvs | grep 961ea94a" supposed to be disks snapshots. Which of them must I choose to get the last vm before shutting down? I'm not used to deal snapshot with virsh/libvirt, so some help will be much appreciated. Is there some unknown command to recover this vm into ovirt? Thank you in advance. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

4 6

[ovirt-devel] FOSDEM 2018 - CFP is almost closed!
by Piotr Kliczewski 07 Dec '17

07 Dec '17

All, FOSDEM 18's Virt and IaaS CFP ends today at midnight UTC. This is your last chance to submit your session, so do not wait any longer. You can find more details in [1]. Thanks, Piotr [1] https://www.ovirt.org/blog/2017/10/come-to-fosdem-event/

1 0