CentOS virt - Dec 2015 - win2008r2 update on centos 6 host made system unbootable

On 09.12.2015 13:47, Patrick Bervoets wrote:
> 
> 
> Op 09-12-15 om 01:00 schreef Dennis Jacobfeuerborn:
>> On 09.12.2015 00:39, NightLightHosts Admin wrote:
>>> On Tue, Dec 8, 2015 at 5:26 PM, Dennis Jacobfeuerborn
>>> <dennisml at conversis.de> wrote:
>>>> Hi,
>>>> today we ran into a strange problem: When performing a regular
Windows
>>>> 2008r2 update apparently among other things the following was
>>>> installed:
>>>> "SUSE - Storage Controller - SUSE Block Driver for
Windows"
>>>>
>>>> [...]
>>>> [...]
>>>> What worries me is that I want to update other win2008r2 guests
as well
>>>> but now fear that they will all be rendered unbootable by such
an
>>>> update.
>>>>
>>>> Regards,
>>>>    Dennis
>>>>
>>>> _______________________________________________
>>>> CentOS-virt mailing list
>>>> CentOS-virt at centos.org
>>>> https://lists.centos.org/mailman/listinfo/centos-virt
>>>>
> 
> Which virtualization are you using? KVM?
> 
> How did you get that update offered?
> 
> I can't reproduce it, but then my servers are on a patch management
> software.
> And I can't check on WU because I don't want to install the new
update
> client.
> 
> Anyway, I would uncheck that patch when updating the other guests if I
> were you. And work on a copy / snapshot.
Yes, this is a CentOS 6 Host using regular libvirt based virtualization.
The Suse driver is apparently an optional update that gets delivered
using the regular Microsoft update mechanism.
It's hard to believe that they didn't catch a completely broken driver
during QA so my hypothesis is that maybe the new Virtio driver is
incompatible only with the older Kernel of CentOS 6 and that this wasn't
properly tested. To verify this one could check if the same thing
happens on a CentOS 7 Host but at the moment I'm to busy the check this.

Regards,
  Dennis

Op 09-12-15 om 14:23 schreef Dennis Jacobfeuerborn:
> Yes, this is a CentOS 6 Host using regular libvirt based virtualization.
The Suse driver is apparently an optional update that gets delivered using the
regular Microsoft update mechanism. It's hard to believe that they
didn't catch a completely broken driver during QA so my hypothesis is that
maybe the new Virtio driver is incompatible only with the older Kernel of CentOS
6 and that this wasn't properly tested. To verify this one could check if
the same thing happens on a CentOS 7 Host but at the moment I'm to busy the
check this. Regards, Dennis
Regrettably Microsoft has picked up the habbit of giving out buggy patches.
Sysadmins are becoming betatesters.

I wish I could test it but haven't got no C7 host yet.

Hope you didn't got bitten too hard and thanks for the heads -up.
Patrick





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3287 bytes
Desc: S/MIME-cryptografische ondertekening
URL:
<http://lists.centos.org/pipermail/centos-virt/attachments/20151209/154f8b2d/attachment-0002.p7s>

On Wed, Dec 9, 2015 at 8:31 PM, Patrick Bervoets
<patrick.bervoets at psc-elsene.be> wrote:
>
>
> Op 09-12-15 om 14:23 schreef Dennis Jacobfeuerborn:
>>
>> Yes, this is a CentOS 6 Host using regular libvirt based
virtualization.
>> The Suse driver is apparently an optional update that gets delivered
using
>> the regular Microsoft update mechanism. It's hard to believe that
they
>> didn't catch a completely broken driver during QA so my hypothesis
is that
>> maybe the new Virtio driver is incompatible only with the older Kernel
of
>> CentOS 6 and that this wasn't properly tested. To verify this one
could
>> check if the same thing happens on a CentOS 7 Host but at the moment
I'm to
>> busy the check this. Regards, Dennis
>
>
> Regrettably Microsoft has picked up the habbit of giving out buggy patches.
> Sysadmins are becoming betatesters.
Well to be fair to Microsoft, the only reason SuSE driver would even
load on RHEL is if the virtio devices running on SuSE look to Windows
sufficiently like the virtio devices running on RHEL.  It's not the
normal thing to have two completely different vendors writing drivers
for nearly identical (yet incompatible) hardware, so it's not terribly
surprising that they didn't start out with checks for this kind of
thing.

 -George