[Users] desktop virtualization documentation
hi, is there any documentation to configure/setup desktop virtualization with ovirt? had anyone domented it somewhere? please share it with me. -- Regards, Umarzuki Mochlis http://debmal.my ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Ang: ovirt 3.1 engine install fails - fedora 17 with selinux disabled
Did you try setting it to enabled and then to permissive? I seem to remember that when you turn SELInux back on, it has to reindex or something. Maybe you have to go to enabled first before permissive to get it to do that. Then again, my memory could just be haywire. On Fri, Aug 10, 2012 at 11:18 AM, Johan Kragsterman < johan.kragster...@capvert.se> wrote: > Hi! > > I encountered the same problem, and I found this bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=835100 > > reported by Ofer Schreiber. > > So it is not intended. > > I do have another problem, related to this,though! > > I can't set my SELinux to permissive...? In the /etc/selinux/conf file, I > change and put in permissive, save the file and reboot. When the system > starts sestatus reports disabled...? I tried this a couple of times, and I > don't know why it's sort of stuck there... > > Idea's...? > > regards Johan > > -users-boun...@ovirt.org skrev: - > Till: > Från: David Elliott > Sänt av: users-boun...@ovirt.org > Datum: 2012.08.10 16:41 > Ärende: [Users] ovirt 3.1 engine install fails - fedora 17 with selinux > disabled > > Hi > > Thanks to all for the great work getting 3.1 out the door, 3.0 is working > well for us and looking forward to playing with all the new features. > > At the moment, am having a small problem during initial engine setup where > it fails if selinux is configured as "disabled" - is this intended > behaviour? > > - selinux disabled > - reports nfs domain setup as failed > > [root@ovirt-m-2 ~]# engine-setup > --answer-file=ovirt-answers.ovirt-m-2.shazamteam.com > > -- snip- > > Configuring the Default ISO Domain... [ ERROR ] > > -- snip > > [root@ovirt-m-2 ~]# engine-cleanup > > - After setting CONFIG_NFS=no, in the answer file; it gives an explicit > error about selinux during the HTTPD phase (OVERRIDE_HTTPD_CONFIG=yes) > > [root@ovirt-m-2 ~]# engine-setup > --answer-file=ovirt-answers.ovirt-m-2.shazamteam.com > > -- snip > > Handling HTTPD... [ ERROR ] > Failed to enable SELinux boolean > > -- snip - > > - set selinux to permissive and reboot > - install succeeds (OVERRIDE_HTTPD_CONFIG=yes, CONFIG_NFS=yes) > > Cheers, > Dave > > > > > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > -- Gary Scarborough IST Lab Manager Rochester Institute of Technology Rochester NY ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification
On Thu, Aug 09, 2012 at 05:22:09PM +0100, Ricardo Esteves wrote: > [root@blade4 ~]# virsh -r cpu-compare /tmp/cpu.xml > Host CPU is a superset of CPU described in /tmp/cpu.xml > > -Original Message- > From: Dan Kenigsberg > To: Itamar Heim , g...@redhat.com > Cc: Ricardo Esteves , users@ovirt.org > Subject: Re: [Users] oVIrt 3.1 - Xeon E5530 - Wrong cpu identification > Date: Thu, 9 Aug 2012 18:57:29 +0300 > > > On Thu, Aug 09, 2012 at 05:17:14PM +0300, Itamar Heim wrote: > > On 08/09/2012 04:17 PM, Ricardo Esteves wrote: > > > > > >Ok, i fixed the ssl problem, my ovirt manager machine iptables was > > >blocking the 8443 port. > > > > > >I also reinstalled the lastest version of the node > > >(ovirt-node-iso-2.5.1-1.0.fc17.iso), but ovirt manager still doesn't > > >recognize the CPU. > > > > > >The host status remains Non Operational : > > > > > >Host localhost.localdomain moved to Non-Operational state as host does > > >not meet the cluster's minimum CPU level. Missing CPU features : > > >model_Nehalem > > > > danken - libvirt reports nehalem, yet vdsm reports conroe? > > Interesting... > > If yo put > NehalemIntel > in /tmp/cpu.xml > > what does > > virsh -r cpu-compare /tmp/cpu.xml > > report? (top posting make it very difficult to follow a long thread) I have a hunch that this is something that has been fixed by http://gerrit.ovirt.org/#/c/5035/ Find vendor for all cpu models, including those based on another cpu module. it is accpeted upstream, but unfortunately did not make it into the ovirt-3.1 release. Could you apply the patch to Vdsm and see if it fixes the reported cpu level? Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Wondering about updating ovirt from 3.0 to 3.1
TOP POSTING, as I got this question number of times: oVirt 3.0 was the first release of the oVirt project. It was based on Fedora16, and a special JBoss package (ovirt-engine-jbossas) which we created as a temporary solution until JBoss will get into Fedora. 3.1 is Fedora 17 based, and supports the official JBoss. Due to those huge changes (packaging wise mainly), our upgrade path is non-trivial. Actually, even if we didn't have the (huge) packaging changes, 3.0 to 3.1 upgrade would require a big amount of downtime, due to the need to upgrade you base OS (Fedora 16 to 17). As we mentioned in the release notes, we have two options to do the upgrade: 1. RECOMMENDED - Export all templates ans vms and import them into a new setup - Downtime depends on the total size of VMs + Templates 2. NOT RECOMMENDED - Follow http://wiki.ovirt.org/wiki/OVirt_3.0_to_3.1_upgrade - Downtime depends on the F16 -> 17 upgrade + few manual steps I understand both flows are not perfect, but we had to do those changes. As a result, future upgrades should be much faster. Thanks, Ofer - Original Message - > On 08/09/2012 02:35 PM, Gavin Spurgeon wrote: > > Eli/Ofer/Juan - what was the result of fixing the upgrade script to > work > from 3.0 to 3.1? > > > Hash: SHA1 > > > > > > > > On 08/09/2012 11:55 AM, Jacob Wyatt wrote: > >> See the migration instructions at the bottom of the relese notes. > >> Basically you shut down all of your VMs, export them to your > >> export > >> domain. Now all you have to do is preserve that export domain > >> storage. Everything else should be blown away and rebuilt as a > >> completely new install. Then you import that storage domain you > >> saved and restore the VM's. It worked just fine for me. > > > > But this requires that my entire Production Environment being > > off-line, to do a point update of the oVirt from 3.0 to 3.1. > > > > oVirt Nodes can run without a Manager being present and all Guest > > will > > stay Up and running. What if, Taking the whole environment off > > line, > > is not an option... > > > > - From a DR point of view, oVirt needs a Backup solution to backup > > the > > Manager, and more importantly a Restore Option that would mean you > > can > > bring an oVirt Manager Back online without the whole lot being > > off-line. > > > >> From: > >> users-boun...@ovirt.org [users-boun...@ovirt.org] on behalf of > >> Gavin Spurgeon [gspurg...@dageek.co.uk] Sent: Wednesday, August > >> 08, > >> 2012 11:35 AM To: users@ovirt.org Cc: Dale Macartney Subject: Re: > >> [Users] Wondering about updating ovirt from 3.0 to 3.1 > >> > >> > >> Hi All, > >> > >> I know I am not the 1st to ask, and I know I will not be the > >> last > >> > >> I have oVirt3.0 on F16, The Release Notes for 3.1 give a guide on > >> how to upgrade oVirt to 3.1 via a Fedora Upgrade... > >> > >> Can I do the same thing via a Clean Install of F17 (I do not like > >> Upgrades of OS's) ? > >> > >> Or is there a documented DR procedure assuming the host was backed > >> up and a new Host/OS had to be used to get oVirt back on-line ? > >> > >> Basically, What do I need to backup to then bring down the > >> F16/oVirt3.0 Box and replace it with a F17/oVirt3.1 Box ? > >> > >> Is this Documented yet ? > >> > >> > >> -- This message was scanned by DaGeek Spam Filter and is believed > >> to be clean. > >> > >> ___ Users mailing list > >> Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users > >> > >> > >> > >> -- This message was scanned by DaGeek Spam Filter and is believed > >> to be clean. Click here to report this message as spam. > >> https://spam.dc.dageek.co.uk/cgi-bin/learn-msg.cgi?id=CCB7E27DF7.B3479 > >> > >> > >> > > > > - -- > > > > Gavin Spurgeon. > > AKA Da Geek > > > > - > > -- > > "The happiest of people don't necessarily have the best of > > everything, > > they just make the most of everything that comes along their way.." > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.12 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAlAjoGcACgkQvp6arS3vDioQPQCbB55CGX5q3lGJ3dnJ5LY+bjKA > > AgoAmgOn20QMNUWTBek3ONUknPFvgLhU > > =sHwm > > -END PGP SIGNATURE- > > > > -- > > This message was scanned by DaGeek Spam Filter and is believed to > > be clean. > > > > ___ > > Users mailing list > > Users@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] EL 6.3+ nodes and 3.1 compatibility?
Rebuilding vdsm - "ovirt-3.1" from GIT and according dependent packages did
the trick to get the node added into the 3.1 cluster (EG: logrotate,
gluster, etc). Next I ran into the issue with the current RHEL 6.3 sanlock
not starting due to wdmd failing startup due to a watchdog not being loaded
(https://bugzilla.redhat.com/show_bug.cgi?id=832935). Fixed that by
building and installing a newer sanlock where this was fixed.
- DHC
On Sat, Aug 11, 2012 at 4:31 PM, Itamar Heim wrote:
> On 08/10/2012 04:21 PM, Dead Horse wrote:
>
>> When I try adding an EL 6.3 based node to an ovirt 3.1 cluster, ovirt
>> complains that the host must be run in 3.0 compatibility mode and then
>> bombs out.
>>
>
> you should create a 3.0 dc/cluster for this version of vdsm.
> RHEL does not yet have a VDSM version with 3.1 support.
>
>
>> The version of VDSM on the node is:
>> vdsm-4.9-113.1.el6.x86_64
>> vdsm-cli-4.9-113.1.el6.x86_64
>>
>> Other misc versions:
>> kernel-2.6.32-279.2.1.el6.x86_
>> 64
>> libvirt-0.9.10-21.el6_3.3.x86_**64
>> libvirt-python-0.9.10-21.el6_**3.3.x86_64
>> qemu-img-0.12.1.2-2.295.el6_3.**1.x86_64
>> qemu-kvm-0.12.1.2-2.295.el6_3.**1.x86_64
>> gpxe-roms-qemu-0.9.7-6.9.el6.**noarch
>> qemu-kvm-tools-0.12.1.2-2.295.**el6_3.1.x86_64
>> spice-server-0.10.1-10.el6.**x86_64
>>
>> 'vdsClient -s 0 getVdsCaps' is does not seem to work since I have SSL
>> disabled for vdsm so here is the output from the vdsm.log:
>> Thread-13::DEBUG::2012-08-10 00:46:26,202::clientIF::59::**vds::(wrapper)
>> return getVdsCapabilities with {'status': {'message': 'Done', 'code':
>> 0}, 'info': {'HBAInventory': {'iSCSI': [{'InitiatorName':
>> 'iqn.1994-05.com.redhat:**decf7eb6ff3f'}], 'FC': []}, 'packages2':
>> {'kernel': {'release': '279.2.1.el6.x86_64', 'buildtime': 1342732135.0,
>> 'version': '2.6.32'}, 'spice-server': {'release': '10.el6', 'buildtime':
>> '1340343617', 'version': '0.10.1'}, 'vdsm': {'release': '113.1.el6',
>> 'buildtime': '1344576418', 'version': '4.9'}, 'qemu-kvm': {'release':
>> '2.295.el6_3.1', 'buildtime': '1343643134', 'version': '0.12.1.2'},
>> 'libvirt': {'release': '21.el6_3.3', 'buildtime': '1342618149',
>> 'version': '0.9.10'}, 'qemu-img': {'release': '2.295.el6_3.1',
>> 'buildtime': '1343643134', 'version': '0.12.1.2'}}, 'cpuModel':
>> 'Intel(R) Xeon(R) CPU E5540 @ 2.53GHz', 'hooks': {},
>> 'vmTypes': ['kvm'], 'supportedProtocols': ['2.2', '2.3'], 'networks':
>> {'ovirtmgmt': {'addr': '192.168.1.22', 'cfg': {'IPV6INIT': 'no',
>> 'IPADDR': '192.168.1.22', 'DELAY': '0', 'PREFIX': '24', 'BOOTPROTO':
>> 'none', 'STP': 'off', 'DEVICE': 'ovirtmgmt', 'TYPE': 'Bridge', 'ONBOOT':
>> 'yes'}, 'ports': ['eth0'], 'netmask': '255.255.255.0', 'stp': 'off',
>> 'gateway': '192.168.1.1'}, 'virbr0': {'addr': '192.168.122.1', 'cfg':
>> {}, 'ports': ['virbr0-nic'], 'netmask': '255.255.255.0', 'stp': 'on',
>> 'gateway': '0.0.0.0'}}, 'uuid':
>> 'FF28----**00212883B51A_00:21:28:83:B5:**16', 'nics':
>> {'eth3': {'hwaddr': '00:21:28:83:B5:19', 'netmask': '', 'speed': 0,
>> 'addr': ''}, 'eth2': {'hwaddr': '00:21:28:83:B5:18', 'netmask': '',
>> 'speed': 0, 'addr': ''}, 'eth1': {'hwaddr': '00:21:28:83:B5:17',
>> 'netmask': '', 'speed': 0, 'addr': ''}, 'eth0': {'hwaddr':
>> '00:21:28:83:B5:16', 'netmask': '', 'speed': 1000, 'addr': ''}},
>> 'software_revision': '113.1', 'management_ip': '', 'clusterLevels':
>> ['3.0'], 'cpuFlags':
>> u'fpu,vme,de,pse,tsc,msr,pae,**mce,cx8,apic,mtrr,pge,mca,**
>> cmov,pat,pse36,clflush,dts,**acpi,mmx,fxsr,sse,sse2,ss,ht,**
>> tm,pbe,syscall,nx,rdtscp,lm,**constant_tsc,arch_perfmon,**
>> pebs,bts,rep_good,xtopology,**nonstop_tsc,aperfmperf,pni,**
>> dtes64,monitor,ds_cpl,vmx,est,**tm2,ssse3,cx16,xtpr,pdcm,dca,**
>> sse4_1,sse4_2,popcnt,lahf_lm,**ida,dts,tpr_shadow,vnmi,**
>> flexpriority,ept,vpid,model_**486,model_pentium,model_**
>> pentium2,model_pentium3,model_**pentiumpro,model_qemu32,model_**
>> cpu64-rhel5,model_cpu64-rhel6,**model_kvm32,model_coreduo,**
>> model_kvm64,model_core2duo,**model_n270,model_Conroe,model_**
>> Penryn,model_Nehalem,model_**Opteron_G1',
>> 'ISCSIInitiatorName': 'iqn.1994-05.com.redhat:**decf7eb6ff3f', 'memSize':
>> '36140', 'reservedMem': '256', 'bondings': {'bond4': {'hwaddr':
>> '00:00:00:00:00:00', 'cfg': {}, 'netmask': '', 'addr': '', 'slaves':
>> []}, 'bond0': {'hwaddr': '00:00:00:00:00:00', 'cfg': {}, 'netmask': '',
>> 'addr': '', 'slaves': []}, 'bond1': {'hwaddr': '00:00:00:00:00:00',
>> 'cfg': {}, 'netmask': '', 'addr': '', 'slaves': []}, 'bond2': {'hwaddr':
>> '00:00:00:00:00:00', 'cfg': {}, 'netmask': '', 'addr': '', 'slaves':
>> []}, 'bond3': {'hwaddr': '00:00:00:00:00:00', 'cfg': {}, 'netmask': '',
>> 'addr': '', 'slaves': []}}, 'software_version': '4.9', 'cpuSpeed':
>> '1600.000', 'cpuSockets': '2', 'vlans': {}, 'cpuCores': '8',
>> 'kvmEnabled': 'true', 'guestOverhead': '65', 'supportedRHEVMs': ['3.0'],
>> 'version_name': 'Snow Man', 'emulatedMachines': [u'rhel6.3.0', u'pc',
>> u'rhel6.2.0', u'rhel6.1.0', u'rhel6.0.0', u'rhel5
