From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Davidsen Subject: qcow and updates Date: Fri, 25 Jul 2008 13:07:01 -0400 Message-ID: <488A0835.2020202@tmr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from mail.tmr.com ([64.65.253.246]:39476 "EHLO gaimboi.tmr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751357AbYGYQ65 (ORCPT ); Fri, 25 Jul 2008 12:58:57 -0400 Received: from [127.0.0.1] (gaimboi.tmr.com [127.0.0.1]) by gaimboi.tmr.com (8.12.8/8.12.8) with ESMTP id m6PH71Av032138 for ; Fri, 25 Jul 2008 13:07:01 -0400 Sender: kvm-owner@vger.kernel.org List-ID: This question came out of a discussion of nesting (or stringing if you like) disk images using qcow. If I have an unpatched install image, say CentOS-5.2 (box "A" below). and I make a copy of that with qcow and apply patches to that copy (box "B" below), everything is just fine. But if I should make a working qcow image from the patched version (box "C" below), which works fine initially, what would happen if I applied patches to the "current" version? I assume that would mess up the application version, since it's a physical copy, but I'd like to be sure. ______________ | [A] | | orig release | |______________| || {qcow copy| || ____________________ | [B] | | patched to current | |____________________| || {qcow copy} || _________________________ | [C] | | fully config. app. svr. | |_________________________| I could play with union filesystem, network mounting of /var and /usr, and other tricks, but I thought I'd check that this really is a problem, and the current version needs a "real" copy to the app server, and then the app server needs to be patched after that. -- Bill Davidsen "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot