<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Vmotion on BAFM</title><link>https://christian.blog.pakiheim.de/tags/vmotion/</link><description>Recent content in Vmotion on BAFM</description><generator>Hugo -- 0.160.1</generator><language>en</language><lastBuildDate>Sat, 16 Aug 2014 09:49:58 +0000</lastBuildDate><atom:link href="https://christian.blog.pakiheim.de/tags/vmotion/index.xml" rel="self" type="application/rss+xml"/><item><title>Extending vMotion compatiblity</title><link>https://christian.blog.pakiheim.de/posts/2014-08-16_extending-vmotion-compatiblity/</link><pubDate>Sat, 16 Aug 2014 09:49:58 +0000</pubDate><guid isPermaLink="false">http://blog.barfoo.org/?p=482</guid><description>&lt;p&gt;Today I did something horrible. I yet again noticed that I bought the wrong CPU&amp;rsquo;s (basically I bought Xeon DP&amp;rsquo;s with four cores). Those have apparently a feature called SSSE3, which makes vMotion with our old Xeon DP&amp;rsquo;s (dual cores) fail before even trying.&lt;/p&gt;
&lt;p&gt;But as we had a cooling outage today (basically &amp;lsquo;cause it broke), I needed to turn off some ESX servers. Thus leaving me with the new ones and one of the old ones. * &lt;strong&gt;yuck&lt;/strong&gt;*&lt;/p&gt;</description></item><item><title>VMs in Alarm state after scheduled maintainance</title><link>https://christian.blog.pakiheim.de/posts/2012-07-22_vms-in-alarm-state-after-scheduled-maintainance/</link><pubDate>Sun, 22 Jul 2012 10:38:04 +0000</pubDate><guid isPermaLink="false">http://blog.barfoo.org/?p=4318</guid><description>&lt;p&gt;Well, I&amp;rsquo;m back at work after three weeks of vacation (some pictures to follow) and the provider hosting our disaster datacenter had their annual (or is it monthly now?) SAN maintainance, so we shut down everything over there by 9:00 am.&lt;/p&gt;
&lt;p&gt;After things were back up around 5pm, I booted the ESX hosts, however the VMs we&amp;rsquo;re all displaying the alert state - as if either the VMs had an HA event or we&amp;rsquo;re using to much CPU time. It didn&amp;rsquo;t matter whether or not the VM was running or not, the state persisted.&lt;/p&gt;</description></item><item><title>Extending VMotion compatiblity (continued)</title><link>https://christian.blog.pakiheim.de/posts/2008-07-14_extending-vmotion-compatiblity-continued/</link><pubDate>Mon, 14 Jul 2008 17:41:40 +0000</pubDate><guid isPermaLink="false">http://blog.barfoo.org/?p=500</guid><description>&lt;p&gt;Remember my &lt;a href="https://christian.blog.pakiheim.de/posts/2008-07-14_extending-vmotion-compatiblity-continued" title="Extending vMotion compatiblity"&gt;last post about cpu masking&lt;/a&gt; ? Well, turns out that you can do it to a &amp;ldquo;template&amp;rdquo;.&lt;/p&gt;
&lt;p&gt;The only point you don&amp;rsquo;t need to do, is to mark the &lt;strong&gt;VM&lt;/strong&gt; as a &amp;quot; &lt;em&gt;template&lt;/em&gt;&amp;quot;. You still can clone it and move it around and all that other stuff, but the good part is, that the cloned VM keeps the cpu mask set to the &amp;quot; &lt;em&gt;template&lt;/em&gt;&amp;quot; &amp;#x1f937;&lt;/p&gt;</description></item></channel></rss>