[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] EL6 initscript feedback.

On Tue, May 21, 2013 at 07:25:00PM +0100, Gordan Bobic wrote:
> On 05/21/2013 06:00 PM, Pasi Kärkkäinen wrote:
> >On Tue, May 21, 2013 at 01:02:35PM +0100, Stefano Stabellini wrote:
> >>On Tue, 21 May 2013, Gordan Bobic wrote:
> >>>On Tue, 21 May 2013 21:30:27 +1000, Steven Haigh <netwiz@xxxxxxxxx> wrote:
> >>>>On 05/21/2013 09:20 PM, Stefano Stabellini wrote:
> >>>>>On Tue, 21 May 2013, Steven Haigh wrote:
> >>>>>>Hi all,
> >>>>>>
> >>>>>>I'm throwing in my initscript here that I've been pushing to autostart
> >>>>>>xen
> >>>>>>domains on system boot.
> >>>>>>
> >>>>>>There are at least one issue right now that I'm not 100% sure how to
> >>>>>>handle -
> >>>>>>and that is domains created by libvirt. These continue to show in an
> >>>>>>xm/xl
> >>>>>>list output even when they are not paused / running / blocked - causing
> >>>>>>my
> >>>>>>initscript to think they are still running.
> >>>>>>
> >>>>>>The ways I can think of detecting this are *very* hacky and I wouldn't
> >>>>>>feel
> >>>>>>comfortable to including them in widely used packages.
> >>>>>>
> >>>>>>I'm wondering if people have some spare time that they review the logic
> >>>>>>in
> >>>>>>this initscript and provide feedback / suggestions / fixes /
> >>>>>>improvements that
> >>>>>>I can roll into the scripts to enhance them for all.
> >>>>>
> >>>>>Is it actually a good idea to mix and match different toolstacks on the
> >>>>>same host? If somebody intends to use libvirt, surely she would want to
> >>>>>use it for everything?
> >>>>
> >>>>This is the interesting question... which probably leads into a more
> >>>>important question... What is the best practices for config management
> >>>>and defining configuration for DomU's?
> >>>>
> >>>>While I recommend that people use a plain text config file in
> >>>>/etc/xen (although really the files can be just about anywhere) and
> >>>>then links to various auto-start DomU's in /etc/xen/auto as a general
> >>>>rule.
> >>>>
> >>>>Am I correct in thinking that libvirt only keeps details of domains
> >>>>in the xenstore? Is this recommended? Although more a libvirt question
> >>>>- can libvirt be configured to use config files in /etc/xen or
> >>>>similar?
> >>>
> >>>I think this is largely distribution dependant. In the case of EL/Fedora,
> >>>libvirt seems to be the distro's intended way of managing VMs, at least for
> >>>their primary supported virtualization method (KVM).
> >>>
> >>>In the interest of clarity and maintainability I have seen the light
> >>>and converted my VMs to simple text files in /etc/xen/ (there seems to be
> >>>no documentation on how to edit most of the settings in xenstore). Some
> >>>consensus on the best way would be good, though.
> >>
> >>I think that using simple text files in /etc/xen for VM configs is
> >>clearly the right way to go from the Xen POV.
> >>
> >
> >Earlier libvirt versions, such as the default version in rhel5/centos5,
> >creates /etc/xen/<vm> text files upon VM creation. Later libvirt versions 
> >changed the model
> >to use xend managed domains with libvirt xml configs.
> >
> >I wonder if that behaviour could be changed with some config option.. would 
> >be nice.
> >
> >Also to convert from libvirt xml to xen text files you can use this:
> >
> >virsh dumpxml vm_name > /tmp/a
> >virsh domxml-to-native xen-xm /tmp/a > /etc/xen/vm_name
> >
> >Works for me on centos6 Xen (libvirt 0.10.2).
> EL6 seems to keep the VM configs in xenstore, not in xml files.

EL6 doesn't ship with Xen, so it's good to mention which 3rdparty Xen/libvirt 
rpms you're using.

Anyway, with Centos6 Xen/libvirt rpms, when I install a new Xen VM with 
it shows up in "virsh list", and also as a xend managed domain in "xm list",
and I can use the libvirt "virsh dumpxml" and "virsh domxml-to-native xen-xm" 
to generate a normal xen text cfgfile for the VM.

-- Pasi

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.