- Users - oVirt List Archives

Live Snapshot issue (once more) with the new QEMU Packages (V5.10) from CENTOS Updates
by Christian Rebel 13 Jun '14

13 Jun '14

Hi all, after today's CentOS "yum update", I had once more the Problem with LIVE Snapshots due to the new "qemu packages". Can anyone explain me why there is such a huge difference between the "CENTOS QEMU Packages" and the "Jenkins RHEV qemu Packages". CENTOS QEMU = LIVE Snapshot failed (tested with qemu versions V5.8 and 5.10) * VDSErrorException: VDSGenericException: VDSErrorException: Failed to SnapshotVDS, error = Snapshot failed, code = 48 JENKINS QEMU = LIVE Snapshots ok (tested with qemu versions V5.8 and 5.10) * Command CreateAllSnapshotsFromVm, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) returned status finished, result 'success'. Thanks! Christian

1 0

Network traffic being mirrored
by Jim Rippon 13 Jun '14

13 Jun '14

--=_4ab7acf68b2ea1ad39d80d5183539e8e Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi guys, I am seeing network traffic being sent to all my VMs on one of my oVirt hosts, but not the other two in that same datacentre. The VMs are running CentOS, and I've been monitoring the sessions with iptraf, and can see traffic from all other VMs on that network being received by all other VMs running on this host which have an interface on that same network. Is this something anyone has seen, or could anyone suggest anything I should be looking at to further diagnose? Many thanks, Jim Rippon --=_4ab7acf68b2ea1ad39d80d5183539e8e Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> <html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri= f'> Hi guys, I am seeing network traffic being sent to all my VMs on one of my oVirt = hosts, but not the other two in that same datacentre.  The VMs are run= ning CentOS, and I've been monitoring the sessions with iptraf, and can see= traffic from all other VMs on that network being received by all other VMs= running on this host which have an interface on that same network. Is this something anyone has seen, or could anyone suggest anything I sh= ould be looking at to further diagnose? Many thanks, Jim Rippon <div> </div> </body></html> --=_4ab7acf68b2ea1ad39d80d5183539e8e--

2 2

Re: [ovirt-users] [ ERROR ] Failed to execute stage 'Closing up': Command '/bin/systemctl' failed to execute
by Gianluca Cecchi 13 Jun '14

13 Jun '14

Il 13/giu/2014 19:14 "Todd" <tdsan(a)yahoo.com> ha scritto: > > This is what I found, thank you for sharing: > > [root@ovirt ~]# journalctl -r -a -u ovirt-engine > > -- Logs begin at Wed 2014-06-04 10:56:26 EDT, end at Fri 2014-06-13 13:04:02 EDT > > Jun 12 17:02:18 ovirt.od.itots.local ovirt-engine.py[6127]: 2014-06-12 17:02:18, > > Jun 12 17:02:17 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... > > Jun 12 17:01:28 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. > > -- Reboot -- > > Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter > > Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. > > Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc > > Jun 11 00:11:07 ovirt.od.itots.local ovirt-engine.py[6504]: 2014-06-11 00:11:07, > > Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... > > Jun 11 00:10:39 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. > > Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter > > Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. > > Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc > > Jun 11 00:02:02 ovirt.od.itots.local ovirt-engine.py[3623]: 2014-06-11 00:02:02, > > Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... > > Jun 11 00:01:34 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. > > Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter > > Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. > > Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc > > Jun 10 20:31:22 ovirt.od.itots.local ovirt-engine.py[31568]: 2014-06-10 20:31:22 > > Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... > > Jun 10 20:30:53 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. > > Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter > > Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. > > Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc > > Jun 10 20:29:11 ovirt.od.itots.local ovirt-engine.py[28721]: 2014-06-10 20:29:11 > > Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... > > Jun 10 20:28:12 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. > > > > [root@ovirt ~]# systemctl status ovirt-engine > > ovirt-engine.service - oVirt Engine > > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; disabled) > > Active: failed (Result: exit-code) since Thu 2014-06-12 17:02:18 EDT; 20h ago > > Main PID: 6127 (code=exited, status=1/FAILURE) > > CGroup: /system.slice/ovirt-engine.service > > > > Jun 12 17:02:18 ovirt.od.itots.local ovirt-engine.py[6127]: 2014-06-12 17:02:... > > Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main ...E > > Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. > > Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service e.... > > Hint: Some lines were ellipsized, use -l to show in full. > > > > Todd > > > > From: Gianluca Cecchi [mailto:gianluca.cecchi@gmail.com] > Sent: Thursday, June 12, 2014 6:35 PM > To: Todd; users > > Subject: Re: [ovirt-users] [ ERROR ] Failed to execute stage 'Closing up': Command '/bin/systemctl' failed to execute > > > > On Fri, Jun 13, 2014 at 12:23 AM, Todd <tdsan(a)yahoo.com> wrote: > > One thing I did, I added an additional 4 to make it 8GB to the machine. > > > > And it still does the same thing, but it is saying there is a problem with the systemctl “Closing up” error. > > > > How is that related to the amount of memory, at present, I just want to bring up the web interface and get it installed. > > > > Todd > > > > > > Keep replies on list, so that other can help too if necessary. > I think the init service should have been installed anyway. > What you get from the command > > # systemctl status ovirt-engine > > for example on my system I get this > > > [g.cecchi@tekkaman ~]$ sudo systemctl status ovirt-engine > ovirt-engine.service - oVirt Engine > Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; enabled) > Active: active (running) since Fri 2014-06-13 00:24:55 CEST; 2min 49s ago > Main PID: 1899 (ovirt-engine.py) > CGroup: name=systemd:/system/ovirt-engine.service > ├─1899 /usr/bin/python /usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py --redirect-output --system... > └─2370 ovirt-engine -server -XX:+TieredCompilation -Xms1g -Xmx1g -XX:PermSize=256m -XX:MaxPermSize=256m -Djava.... > > Jun 13 00:24:54 tekkaman.localdomain.local systemd[1]: Starting oVirt Engine... > Jun 13 00:24:55 tekkaman.localdomain.local systemd[1]: Started oVirt Engine. > > And also the command > > # journalctl -r -a -u ovirt-engine > > for example I had a failure on November and the comamnd at a certain point gives: > > Nov 24 20:27:29 tekkaman.localdomain.local systemd[1]: Unit ovirt-engine.service entered failed state. > Nov 24 20:27:29 tekkaman.localdomain.local systemd[1]: Failed to start oVirt Engine. > Nov 24 20:27:29 tekkaman.localdomain.local systemd[1]: ovirt-engine.service: control process exited, code=exited status=1 > Nov 24 20:27:29 tekkaman.localdomain.local engine-service[2598]: Starting engine-service: [FAILED] > Nov 24 20:27:29 tekkaman.localdomain.local engine-service[2598]: The directory "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64" doesn' > Nov 24 20:27:29 tekkaman.localdomain.local systemd[1]: Starting oVirt Engine... > > so your output should contain something useful. > > Also, id you run > > engine-cleanup > > before running engine-setup again after adding memory? It should help too. > > Gianluca > > ________________________________ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4142 / Virus Database: 3604/6715 - Release Date: 10/01/13 > Internal Virus Database is out of date. What about engine-cleanup? Did you run it? Also, engine-setup generates a log file (you should find its reference in output). share it with the list so that one of the developers could help you....

1 0

[ ERROR ] Failed to execute stage 'Closing up': Command '/bin/systemctl' failed to execute
by Todd 13 Jun '14

13 Jun '14

This is a multipart message in MIME format. ------=_NextPart_000_03B4_01CF870A.56908BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have increased the amount of Ram from 4GB to 8GB This is what I found: [root@ovirt ~]# journalctl -r -a -u ovirt-engine -- Logs begin at Wed 2014-06-04 10:56:26 EDT, end at Fri 2014-06-13 13:04:02 EDT Jun 12 17:02:18 ovirt.od.itots.local ovirt-engine.py[6127]: 2014-06-12 17:02:18, Jun 12 17:02:17 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... Jun 12 17:01:28 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. -- Reboot -- Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc Jun 11 00:11:07 ovirt.od.itots.local ovirt-engine.py[6504]: 2014-06-11 00:11:07, Jun 11 00:11:07 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... Jun 11 00:10:39 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc Jun 11 00:02:02 ovirt.od.itots.local ovirt-engine.py[3623]: 2014-06-11 00:02:02, Jun 11 00:02:02 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... Jun 11 00:01:34 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc Jun 10 20:31:22 ovirt.od.itots.local ovirt-engine.py[31568]: 2014-06-10 20:31:22 Jun 10 20:31:22 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... Jun 10 20:30:53 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service enter Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main proc Jun 10 20:29:11 ovirt.od.itots.local ovirt-engine.py[28721]: 2014-06-10 20:29:11 Jun 10 20:29:11 ovirt.od.itots.local systemd[1]: Starting oVirt Engine... Jun 10 20:28:12 ovirt.od.itots.local systemd[1]: Stopped oVirt Engine. [root@ovirt ~]# systemctl status ovirt-engine ovirt-engine.service - oVirt Engine Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; disabled) Active: failed (Result: exit-code) since Thu 2014-06-12 17:02:18 EDT; 20h ago Main PID: 6127 (code=exited, status=1/FAILURE) CGroup: /system.slice/ovirt-engine.service Jun 12 17:02:18 ovirt.od.itots.local ovirt-engine.py[6127]: 2014-06-12 17:02:... Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: ovirt-engine.service: main ...E Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: Failed to start oVirt Engine. Jun 12 17:02:18 ovirt.od.itots.local systemd[1]: Unit ovirt-engine.service e.... Hint: Some lines were ellipsized, use -l to show in full. Todd ---------------------------------------------------------------------------- ------------------------------------------- Message: 3 Date: Thu, 12 Jun 2014 21:51:20 +0200 From: Gianluca Cecchi < <mailto:gianluca.cecchi@gmail.com> gianluca.cecchi(a)gmail.com> To: Todd < <mailto:tdsan@yahoo.com> tdsan(a)yahoo.com> Cc: users < <mailto:users@ovirt.org> users(a)ovirt.org> Subject: Re: [ovirt-users] [ ERROR ] Failed to execute stage 'Closing up': Command '/bin/systemctl' failed to execute Message-ID: < <mailto:CAG2kNCw5wLniTXsz2BJGmJZr1o_dMHPzzucoqOwAOA4mFRHVDg@mail.gmail.com> CAG2kNCw5wLniTXsz2BJGmJZr1o_dMHPzzucoqOwAOA4mFRHVDg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" How much ram do you have on this system?

1 0

localdomain
by Koen Vanoppen 13 Jun '14

13 Jun '14

Hi Guys, It's bin a while :-). Luckily :-). I have a quick question. Is there a way to change the default .localdomain for the FQDN in ovirt? I would be handy if we just had to fill in the hostname of our vm (we are using 3.4, with the cloud-init feature) and he automatically adds our domain in stead of .localdomain. Kind regards, Koen

3 4

oVirt - Node install on CentOS
by Simon Barrett 13 Jun '14

13 Jun '14

--_000_D86C48DF8800164BBE50B87623F7AC9548391A9Fln2wio001devtra_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Could anyone please confirm the correct process to run oVirt node on a stan= dard CentOS install, rather than using the node iso? I'm currently doing the following: - Install CentOS 6.5 - Install qemu-kvm-rhev rpm's to resolve live snapshot issues on t= he CentOS supplied rpm's - Yum install vdsm ovirt-node-plugin-vdsm vdsm-reg o I have to remove noexec from /tmp or the config fails - I then add the node from the ovirt-engine gui After resolving some problems with group memberships and vdsm requiring sud= o access, all is working. Live snapshots and storage migration are OK (test= ed NFS and Gluster as well). I couldn't really find any docs on how to do this so I just wanted to confi= rm if what I am doing makes sense. I also don't have the text configuration interface that I would normally ge= t on the oVirt node iso. Can I install this and use it on a non node iso in= stall? Many thanks for any assistance. Simon --_000_D86C48DF8800164BBE50B87623F7AC9548391A9Fln2wio001devtra_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Could anyone please confirm the correct process to r= un oVirt node on a standard CentOS install, rather than using the node iso?= <o:p></o:p> <o:p> </o:p> I’m currently doing the following:<o:p></o:p><= /p> <o:p> </o:p> <![if !supportLists]>-     &= nbsp;    <![endif]>Install CentOS 6.5<o:p></o:p> <![if !supportLists]>-     &= nbsp;    <![endif]>Install qemu-kvm-rhev rpm’s to resolve live s= napshot issues on the CentOS supplied rpm’s<o:p></o:p> <![if !supportLists]>-     &= nbsp;    <![endif]>Yum install vdsm ovirt-node-plugin-vdsm vdsm-reg<o:= p></o:p> <![if !supportLists]><s= pan style=3D"mso-list:Ignore">o   <![endif]>I have to remove noexec from /tmp or the con= fig fails<o:p></o:p> <![if !supportLists]>-     &= nbsp;    <![endif]>I then add the node from the ovirt-engine gui<o:p><= /o:p> <o:p> </o:p> After resolving some problems with group memberships= and vdsm requiring sudo access, all is working. Live snapshots and storage= migration are OK (tested NFS and Gluster as well). <o:p></o:p> <o:p> </o:p> I couldn’t really find any docs on how to do t= his so I just wanted to confirm if what I am doing makes sense. <o:p></o:p> <o:p> </o:p> I also don’t have the text configuration inter= face that I would normally get on the oVirt node iso. Can I install this an= d use it on a non node iso install?<o:p></o:p> <o:p> </o:p> Many thanks for any assistance.<o:p></o:p> <o:p> </o:p> Simon<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_D86C48DF8800164BBE50B87623F7AC9548391A9Fln2wio001devtra_--

4 7

novnc error
by Garrett Baltezegar 13 Jun '14

13 Jun '14

Hello everyone, I'm running into an error getting novnc up and running with ovirt, and I'm hoping someone can help. My system is a CentOS minimal x86_64 install running ovirt fine. I have created VMs and I'm able to configure the console options. When I attempt to connect to them, however, I get a Server disconnected (code: 1006) error. I've searched online for a solution, but everything seems to point to simply running the engine-setup configuration utility and installing the ca.crt. I have tried both of these things, but I keep getting the same message, in Internet Explorer, Chrome and Firefox. Disabled iptables and selinux. Connected directly to VM with VNC Checked ovirt-websocket-proxy, and it is running - haven't touched config file - SSL=true Installed ca.crt - multiple times Reinstalled ovirt - clean first, the reinstall. Reinstalled ca.crt Nothing has helped so far. Does anyone have any ideas? I have a straight-forward setup using engine-setup; accepting the default answer most of the time. GlusterFS being one of the non-defaults. I appreciate your suggestions! GB

3 13

python-sdk: attach disk snapshot to another virtual machine
by Michael Ablassmeier 13 Jun '14

13 Jun '14

hi guys, according to an commit in Oct. 2013 there was a patch added to the SDK which allows to attach an existing snapshot to a virtual machine: commit 72e67dd5406f3c193234697ce88d92dbe64759d7 Author: Michael pasternak <mpastern(a)redhat.com> Date: Wed Oct 30 11:24:19 2013 +0200 sdk: regenerate against the latest api [..] - added ability to attach a disk snapshot to the virtual machine [..] I think this may be related to the new backup API: http://www.ovirt.org/Features/Backup-Restore_API_Integration can anyone give me an pointer on how to this through the python-sdk? Or is there an example for this anywhere to be found? Thanks! bye, - michael

2 1

KSM and cross-vm attack
by Jorick Astrego 13 Jun '14

13 Jun '14

This is a multi-part message in MIME format. --------------040006070006020209070007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Maybe I should be posting to the kvm mailing list, but I think people here should know a thing or two about it. I just read the following research paper and although the attack was done on VMWare; from what I read about it, it could be possible with KSM on KVM also. If you really need tight security it looks like it would be better to disable KSM. But don't take my word for it as IANAC (I Am Not A Cryptographer). http://soylentnews.org/article.pl?sid=14/06/12/1349234&from=rss Practical Cross-VM AES Full Key Recovery Attack <http://soylentnews.org/article.pl?sid=14/06/12/1349234> posted by janrinok <http://soylentnews.org/%7Ejanrinok/> on Thursday June 12, @02:53PM ** dbot <http://soylentnews.org/%7Edbot/> writes: Researchers from Worcester Polytechnic Institute (Worcester, MA), have published a paper illustrating a practical full Advanced Encryption Standard key recovery from AES operations preformed in one virtual machine, by another VM <http://eprint.iacr.org/2014/435.pdf> [*PDF*] running on the same hardware at the same time. The attack specifically requires memory de-duplication to be enabled, and they target VMWare's VM software. Combining various attacks on memory de-duplication, and existing side channel attacks: In summary, this works: * shows for the first time that de-duplication enables fine grain cross-VM attacks; * introduces a new Flush+Reload based attack that does not require interrupting the victim after each encryption round; * presents the first practical cross-VM attack on AES; the attack is generic and can be adapted to any table-based block ciphers. They target OpenSSL 1.0.1. It will be interesting to see if the suggested countermeasure, flushing the T table cache after each operation (effective against other Flush+Reload attacks), is added to LibreSSL. Will it be left out, in the name of performance - or will they move to a different implementation of AES (not T table-based)? Kind regards, Jorick Astrego Netbulae --------------040006070006020209070007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi, Maybe I should be posting to the kvm mailing list, but I think people here should know a thing or two about it. I just read the following research paper and although the attack was done on VMWare; from what I read about it, it could be possible with KSM on KVM also. If you really need tight security it looks like it would be better to disable KSM. But don't take my word for it as IANAC (I Am Not A Cryptographer). <blockquote><a class="moz-txt-link-freetext" href="http://soylentnews.org/article.pl?sid=14/06/12/1349234&amp;from=rss">http://soylentnews.org/article.pl?sid=14/06/12/1349234&amp;from=rss</a> <div class="generaltitle"> <div class="title"> <h3> <a href="http://soylentnews.org/article.pl?sid=14/06/12/1349234">Practical Cross-VM AES Full Key Recovery Attack</a> </h3> </div> </div> <div class="body"> posted by <a href="http://soylentnews.org/%7Ejanrinok/"> janrinok</a> on Thursday June 12, @02:53PM   <div class="intro"> <a href="http://soylentnews.org/%7Edbot/">dbot</a> writes: Researchers from Worcester Polytechnic Institute (Worcester, MA), have published a paper illustrating a <a href="http://eprint.iacr.org/2014/435.pdf">practical full Advanced Encryption Standard key recovery from AES operations preformed in one virtual machine, by another VM</a> [PDF] running on the same hardware at the same time. The attack specifically requires memory de-duplication to be enabled, and they target VMWare's VM software. Combining various attacks on memory de-duplication, and existing side channel attacks: <blockquote> <div> In summary, this works: <ul> <li>shows for the first time that de-duplication enables fine grain cross-VM attacks;</li> <li>introduces a new Flush+Reload based attack that does not require interrupting the victim after each encryption round;</li> <li>presents the first practical cross-VM attack on AES; the attack is generic and can be adapted to any table-based block ciphers.</li> </ul> </div> </blockquote> They target OpenSSL 1.0.1. It will be interesting to see if the suggested countermeasure, flushing the T table cache after each operation (effective against other Flush+Reload attacks), is added to LibreSSL. Will it be left out, in the name of performance - or will they move to a different implementation of AES (not T table-based)? </div> </div> </blockquote> Kind regards, Jorick Astrego Netbulae </body> </html> --------------040006070006020209070007--

4 7

Re: [ovirt-users] SLA : RAM scheduling
by Karli Sjöberg 13 Jun '14

13 Jun '14

--_000_5F9E965F5A80BC468BE5F40576769F0979FC230Bexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjMgbWFqIDIwMTQgMTc6MTMgc2tyZXYgPT9JU08tODg1OS0xP1E/TmF0aGFuYT1FQmxf QmxhbmNoZXQ/PSA8YmxhbmNoZXRAYWJlcy5mcj46DQo+DQo+DQo+IExlIDIzLzA1LzIwMTQgMTc6 MTEsIE5hdGhhbmHDq2wgQmxhbmNoZXQgYSDDqWNyaXQgOg0KPiA+IEhlbGxvLA0KPiA+IE9uIG92 aXJ0IDMuNCwgaXMgaXQgcG9zc2libGUgdG8gc2NoZWR1bGUgdm1zIGRpc3RyaWJ1dGlvbiBkZXBl bmRpbmcgb24NCj4gPiBob3N0IFJBTSBhdmFpbGliaWxpdHk/DQo+ID4gQ29uY3JldGx5LCBJIGhh ZCB0byBtYW51YWxseSBtb3ZlIHZtcyBhbGwgdGhlIHZtcyB0byB0aGUgc2Vjb25kIGhvc3QNCj4g PiBvZiB0aGUgY2x1c3RlciwgdGhpcyBsZWFkIHRvIHJlYWNoIDkwJSBvY2N1cGF0aW9uIG9mIG1l bW9yeSBvbiB0aGUNCj4gPiBkZXN0aW5hdGlvbiBob3N0LiBXaGVuIG15IGZpcnN0IGhvc3QgaGFz IHJlYm9vdGVkLCBub25lIHZtcyBvZiB0aGUNCj4gPiBzZWNvbmQgaG9zdCBhdXRvbWF0aWNhbGx5 IG1pZ3JhdGVkIHRvIHRoZSBmaXJzdCBvbmUgd2hpY2ggaGFkIGZ1bGwNCj4gPiBSQU0uIEhvdyB0 byBtYWtlIHRoaXMgaGFwcGVuPw0KPiA+DQo+IC4uLiBzbyBhcyB0byBib3RoIGhvc3RzIGJlIFJB TSBldmVubHkgZGlzdHJpYnV0ZWQuLi4gaG9wZSB0byBiZSBlbm91Z2gNCj4gY2xlYXIuLi4NCg0K U291bmRzIGxpa2UgeW91IGp1c3Qgd2FudCB0byBhcHBseSB0aGUgY2x1c3RlciBwb2xpY3kgZm9y IGV2ZW4gZGlzdHJpYnV0aW9uLiBIYXZlIHlvdSBhc3NpZ25lZCBhbnkgcG9saWN5IGZvciB0aGF0 IGNsdXN0ZXI/DQoNCi9LDQoNCj4NCj4gLS0NCj4gTmF0aGFuYcOrbCBCbGFuY2hldA0KPg0KPiBT dXBlcnZpc2lvbiByw6lzZWF1DQo+IFDDtGxlIGV4cGxvaXRhdGlvbiBldCBtYWludGVuYW5jZQ0K PiBEw6lwYXJ0ZW1lbnQgZGVzIHN5c3TDqG1lcyBkJ2luZm9ybWF0aW9uDQo+IDIyNyBhdmVudWUg UHJvZmVzc2V1ci1KZWFuLUxvdWlzLVZpYWxhDQo+IDM0MTkzIE1PTlRQRUxMSUVSIENFREVYIDUN Cj4gVMOpbC4gMzMgKDApNCA2NyA1NCA4NCA1NQ0KPiBGYXggIDMzICgwKTQgNjcgNTQgODQgMTQN Cj4gYmxhbmNoZXRAYWJlcy5mcg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gVXNlcnNAb3ZpcnQub3Jn DQo+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0K --_000_5F9E965F5A80BC468BE5F40576769F0979FC230Bexchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <04232DB00184AB4AA78CEAFB5A968397(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyMyBtYWogMjAxNCAxNzoxMyBza3JldiA9P0lTTy04ODU5LTE/UT9OYXRoYW5h PUVCbF9CbGFuY2hldD89ICZsdDtibGFuY2hldEBhYmVzLmZyJmd0Ozo8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgTGUgMjMvMDUvMjAxNCAxNzoxMSwgTmF0aGFuYcOrbCBCbGFuY2hldCBh IMOpY3JpdCA6PGJyPg0KJmd0OyAmZ3Q7IEhlbGxvLDxicj4NCiZndDsgJmd0OyBPbiBvdmlydCAz LjQsIGlzIGl0IHBvc3NpYmxlIHRvIHNjaGVkdWxlIHZtcyBkaXN0cmlidXRpb24gZGVwZW5kaW5n IG9uIDxicj4NCiZndDsgJmd0OyBob3N0IFJBTSBhdmFpbGliaWxpdHk/PGJyPg0KJmd0OyAmZ3Q7 IENvbmNyZXRseSwgSSBoYWQgdG8gbWFudWFsbHkgbW92ZSB2bXMgYWxsIHRoZSB2bXMgdG8gdGhl IHNlY29uZCBob3N0IDxicj4NCiZndDsgJmd0OyBvZiB0aGUgY2x1c3RlciwgdGhpcyBsZWFkIHRv IHJlYWNoIDkwJSBvY2N1cGF0aW9uIG9mIG1lbW9yeSBvbiB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGRl c3RpbmF0aW9uIGhvc3QuIFdoZW4gbXkgZmlyc3QgaG9zdCBoYXMgcmVib290ZWQsIG5vbmUgdm1z IG9mIHRoZSA8YnI+DQomZ3Q7ICZndDsgc2Vjb25kIGhvc3QgYXV0b21hdGljYWxseSBtaWdyYXRl ZCB0byB0aGUgZmlyc3Qgb25lIHdoaWNoIGhhZCBmdWxsIDxicj4NCiZndDsgJmd0OyBSQU0uIEhv dyB0byBtYWtlIHRoaXMgaGFwcGVuPzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgLi4uIHNvIGFz IHRvIGJvdGggaG9zdHMgYmUgUkFNIGV2ZW5seSBkaXN0cmlidXRlZC4uLiBob3BlIHRvIGJlIGVu b3VnaCA8YnI+DQomZ3Q7IGNsZWFyLi4uPC9wPg0KPHAgZGlyPSJsdHIiPlNvdW5kcyBsaWtlIHlv dSBqdXN0IHdhbnQgdG8gYXBwbHkgdGhlIGNsdXN0ZXIgcG9saWN5IGZvciBldmVuIGRpc3RyaWJ1 dGlvbi4gSGF2ZSB5b3UgYXNzaWduZWQgYW55IHBvbGljeSBmb3IgdGhhdCBjbHVzdGVyPzwvcD4N CjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyAtLSA8YnI+ DQomZ3Q7IE5hdGhhbmHDq2wgQmxhbmNoZXQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTdXBlcnZpc2lv biByw6lzZWF1PGJyPg0KJmd0OyBQw7RsZSBleHBsb2l0YXRpb24gZXQgbWFpbnRlbmFuY2U8YnI+ DQomZ3Q7IETDqXBhcnRlbWVudCBkZXMgc3lzdMOobWVzIGQnaW5mb3JtYXRpb248YnI+DQomZ3Q7 IDIyNyBhdmVudWUgUHJvZmVzc2V1ci1KZWFuLUxvdWlzLVZpYWxhPGJyPg0KJmd0OyAzNDE5MyBN T05UUEVMTElFUiBDRURFWCA1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxicj4NCiZndDsgVMOpbC4gMzMgKDApNCA2NyA1NCA4NCA1NTxicj4NCiZndDsgRmF4Jm5i c3A7IDMzICgwKTQgNjcgNTQgODQgMTQ8YnI+DQomZ3Q7IGJsYW5jaGV0QGFiZXMuZnI8YnI+DQom Z3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBVc2Vyc0BvdmlydC5v cmc8YnI+DQomZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy czxicj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F9E965F5A80BC468BE5F40576769F0979FC230Bexchange21_--

8 15