WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] XenU installs

To: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Subject: Re: [Xen-users] XenU installs
From: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
Date: Wed, 06 Jun 2007 10:12:08 +0100
Cc: Andre Grove <andre.grove@xxxxxxxxx>, Mark Williamson <mark.williamson@xxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 06 Jun 2007 02:10:48 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=noVzPC/IRxaAVQGMiLuVUhj0ueQ9izJns27IrQPNCaXYC4Us370Z3x3rhqkXDLvTr4qJlbjZHoglMIMubMHlXd5l0465t4LTj64bv/7twUrQYMRzKoluV72puSVVubZmcv9n4/qTVC4+/H6OEU+rdpIbi8lOyfr3AW54obxSf0U=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=D5MCJYbV924gQeYyBdq3BhGqOO3uslet1lLY/s/9x9/i+jaVkdtkvgVeuYuF+LF23D68fxF7V3COSRgiZH5CVBuoMqg3Cr2xw4ZRt1zrX1FX50ei6ISb1rasB+j+1dU1OUWRexLWmsgjaRXigP9oC8KP98m+9A4DWfyeeeO1t14=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070605220844.GA29566@xxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <b26d41200706050941v52c00650v9aeec41527670c94@xxxxxxxxxxxxxx> <200706051838.35701.mark.williamson@xxxxxxxxxxxx> <20070605203430.GV15012@xxxxxxxxxx> <4665D426.5030804@xxxxxxxxx> <20070605220844.GA29566@xxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.12 (Windows/20070509)
Daniel P. Berrange wrote:
On Tue, Jun 05, 2007 at 10:22:46PM +0100, Nico Kadel-Garcia wrote:
Daniel P. Berrange wrote:
On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote:
It'd be kinda nice if there were a standardised spec for "how to boot an ISO in a paravirt VM". This would require some kind of agreement between the distributors to do things in a uniform way, but it would move us closer to a "just works" type setup - surely a good thing. It seems relatively unfortunate for the install procedure for each paravirt guest to be slightly different so that the user or tools has to understand those differences.
Paravirt-ops may (eventually) help here because removing the need for a
small xen kernel. Our goal in Fedora is to continue working to make paravirt boot & install process be more closely aligned to fullyvirt & baremetal. This is why we do Fedora guest installs by booting anaconda (+ optional
kickstart) instead of chroot installs, and why we default to using pygrub
and keeping kernels inside the guest image, etc. All the tools already
expect things to work in this way with bare metal & fullvirt, so having
paravirt be different is just complicating things. PXE boot of paravirt
is another thing we'd like to have too...
Is there any chance of integrating support for doing virt-manager installs on top of an *existing* domain, making sure it's shut down, then allowing the network boot to do upgrade or rescue procedures on it?

I've never really thought about that. In theory it could be doable, not
sure how hairy an actual implementation would get though. A better approach
may be just allowing more flexiblity in reconfiguring existing guest
hardware in the UI. eg, allowing you to add a CDROM device to an existing
guest & then changing the default BIOS boot device. We're sort of half
way towards being able todo the latter at the moment.
The para-virt installation procedure, at least on RHEL 5, does not use a local CDROM or DVD. It uses a network repository. Using a CD might be nice for a rescue operation, but the FC or RHEL style installation media support the very useful "rescue" option, which is my friend and would be useful for people like me, who sometimes have to seriously arrange system architectures..

I don't see a theoretical problem, just disabling the the safety check that stops the procedure if the domain already has a config file: If an /etx/xen/[DOMNAME] file exists, instead of failing, simply provide the option of booting with the settings of the already existing file and set *NO* other options except those necessary for the network boot. I'm not sure if you would need to parse the existing domain file, or simply add options to do this: I don't understand libvirt well enough to say.

Does that make sense? If you point out the right bugzilla or Wiki to me, I'd be happy to put it in as a feature request.

The "linux rescue" option is really, really my friend, as is the "pre" option. I use it laying OS tarballs on top of existing hardware and chrooting into them to do updates, feature reconfigurations, etc. And I've deployed roughly...... 20,000 servers using that kind of tool, over the last 6 years.




_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>