* EL6 initscript feedback.
@ 2013-05-21 3:01 Steven Haigh
2013-05-21 11:20 ` Stefano Stabellini
0 siblings, 1 reply; 8+ messages in thread
From: Steven Haigh @ 2013-05-21 3:01 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
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.
Thanks.
--
Steven Haigh
Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
[-- Attachment #2: xendomains --]
[-- Type: text/plain, Size: 6821 bytes --]
#!/bin/bash
#
# /etc/init.d/xendomains
# Start / stop domains automatically when domain 0 boots / shuts down.
#
# chkconfig: 345 99 00
# description: Start / stop Xen domains.
#
# Re-written from scratch by Steven Haigh <netwiz@crc.id.au> for EL6 as stock
# script has a lot of problems. May work on other distros, YMMV.
#
### BEGIN INIT INFO
# Provides: xendomains
# Required-Start: $syslog $remote_fs xenstored xenconsoled
# Should-Start: xend
# Required-Stop: $syslog $remote_fs xenstored xenconsoled
# Should-Stop: xend
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start/stop secondary xen domains
# Description: Start / stop domains automatically when domain 0
# boots / shuts down.
### END INIT INFO
## Check if Xend is running, if so, use xm, else xl.
XEND=`pidof -x xend`
if [ $? -eq 0 ]; then
CMD=`which xm`
else
CMD=`which xl`
fi
## Check to see if we're running as Dom0. If so, the following file should
## exist.
if ! [ -e /proc/xen/privcmd ]; then
echo "Not running as Domain0. Exiting..."
exit 0
fi
## Load the xendomains options, bailing if we can't.
if [ -r /etc/sysconfig/xendomains ]; then
. /etc/sysconfig/xendomains
else
echo "/etc/sysconfig/xendomains not found or unreadable. This is an issue. Exiting..."
exit 0
fi
if [ -d /var/lock/subsys ]; then
LOCKFILE=/var/lock/subsys/xendomains
else
LOCKFILE=/var/lock/xendomains
fi
## Source function library.
. /etc/init.d/functions
get_domu_name() {
DOMU_NAME=$(awk '/^name/ {print $3}' $1)
}
watchdog() {
## Launch a command and wait until the timeout before killing forcefully.
for WAIT in `seq 0 $XENDOMAINS_STOP_MAXWAIT`; do
RESULT=`ps -p $PID`
if [ $? -eq 1 ]; then
success; echo
break
fi
echo -n "."
sleep 1
done
RESULT=`ps -p $PID`
if [ $? -eq 0 ]; then
warning; echo
kill $PID
fi
echo
}
start() {
touch $LOCKFILE
## Check to see if we should restore saved DomUs on start
## Also check if the restore directory actually exists.
if [ "$XENDOMAINS_RESTORE" = "true" ] && [ -d $XENDOMAINS_SAVE ] && [ -n "$XENDOMAINS_SAVE" ]; then
for DOMU in $XENDOMAINS_SAVE/*; do
if [ -r $DOMU ]; then
HEADER=`head -c 16 $DOMU | head -n 1 2> /dev/null`
if [ "$HEADER" = "LinuxGuestRecord" ] || [ "$HEADER" = "Xen saved domain" ]; then
echo -n "Restoring Xen Domain ${DOMU##*/}"
RESULT=`$CMD restore $DOMU 2>&1 1>/dev/null`
if [ $? -ne 0 ]; then
failure; echo
else
success; echo
fi
rm -f "$DOMU"
fi
fi
done
fi
## Check to see if our autostart directory exists and is actually set.
if [ -d $XENDOMAINS_AUTO ] && [ -n $XENDOMAINS_AUTO ]; then
## Start each domain in our autostart directory.
for DOMU in $XENDOMAINS_AUTO/*; do
get_domu_name $DOMU
echo -n $"Starting Xen auto domain $DOMU_NAME: "
## Check if domain is already running.
RESULT=`$CMD list $DOMU_NAME >& /dev/null`
if [ $? -eq 0 ] && [ $? -ne 2 ]; then
## DomU is already running.
echo -n " (Skipped - Already running)"
else
## Start the DomU...
RESULT=`$CMD create $DOMU >& /dev/null`
if [ $? -eq 0 ]; then
usleep $XENDOMAINS_CREATE_USLEEP
success; echo
else
failure; echo
fi
fi
done
fi
return 0
}
stop() {
## Check to see if we should send a SysRq to the DomUs
if [ -n "$XENDOMAINS_SYSRQ" ]; then
IFS=$'\n'
echo -n "Sending SYSRQs to Xen Domains:"
for DOMU in `$CMD list | tail -n +3 | sort`; do
unset IFS
DOMU_NAME=`echo "$DOMU" | awk '{ print $1 }'`
for sysrq in $XENDOMAINS_SYSRQ; do
$CMD sysrq $DOMU_NAME $sysrq
echo -n "."
done
done
success; echo
fi
## Check to see if we should migrate running domains...
if [ -n "$XENDOMAINS_MIGRATE" ]; then
## We should be doing a migrate. We don't really do much, just pass the
## values to XM/XL - if it fails, save or shutdown can have a go.
IFS=$'\n'
for DOMU in `$CMD list | tail -n +3 | sort`; do
unset IFS
DOMU_NAME=`echo "$DOMU" | awk '{ print $1 }'`
echo -n "Migrating Xen domain $DOMU_NAME: "
$CMD migrate $DOMU_NAME $XENDOMAINS_MIGRATE 2>&1 1>/dev/null &
PID=$!
watchdog
done
fi
## Check to see if we are to save domains...
if [ -d $XENDOMAINS_SAVE ] && [ -n "$XENDOMAINS_SAVE" ]; then
## Cycle through the domains running and do what we need to do.
IFS=$'\n'
for DOMU in `$CMD list | tail -n +3 | sort`; do
unset IFS
DOMU_NAME=`echo "$DOMU" | awk '{ print $1 }'`
## Now we set our ionice to lower than realtime as we don't want the
## system to become unresponsive while saving a DomU. It still may
## need to fulfil requests from other DomUs etc.
ionice -c 2 -n 7 -p $$
echo -n "Saving Xen Domain $DOMU_NAME: "
$CMD save $DOMU_NAME $XENDOMAINS_SAVE/$DOMU_NAME > /dev/null 2>&1 &
PID=$!
watchdog
done
fi
## Shut down the remaining domains...
if [ -n "$XENDOMAINS_SHUTDOWN" ]; then
if [ "$CMD" = `which xm` ]; then
echo -n "Sending shutdown to all DomUs: "
$CMD shutdown --all
success; echo
else
IFS=$'\n'
for DOMU in `$CMD list | tail -n +3 | sort`; do
unset IFS
DOMU_NAME=`echo "$DOMU" | awk '{ print $1 }'`
echo -n "Sending shutdown to DomU $DOMU_NAME:"
$CMD shutdown -F "$DOMU_NAME"
success; echo
done
fi
echo "Waiting for all DomUs to complete shutdown"
for WAIT in `seq 0 $XENDOMAINS_STOP_MAXWAIT`; do
echo -n "."
## Check to see how many guests are still running.
NUM_DOMU=$((`$CMD list | wc -l`-2))
if [ $NUM_DOMU -eq "0" ]; then
success; echo
break
fi
sleep 1
done
## Look for stray DomUs
NUM_DOMU=$((`$CMD list | wc -l`-2))
if [ $NUM_DOMU -ne "0" ]; then
## Forcefully close any remaining DomUs
warning; echo
IFS=$'\n'
for DOMU in `$CMD list | tail -n +3 | sort`; do
unset IFS
DOMU_NAME=`echo "$DOMU" | awk '{ print $1 }'`
ID=`echo "$DOMU" | awk '{ print $2 }'`
if [ -n "$ID" ]; then
echo -n "Forcefully destroying $DOMU_NAME:"
$CMD destroy $DOMU_NAME 2>&1 1>/dev/null &
success; echo
fi
done
fi
fi
rm -f $LOCKFILE
return 0
}
status() {
## We've already passed the test to see if Xen Dom0 is running, so here
## we check the number of lines returned from a list command and minus
## 2 from it (Header + Domain-0) and also some memory stats.
NUM_DOMU=$((`$CMD list | wc -l`-2))
MEM_FREE=`$CMD info | grep free_memory | cut -f2 -d":"`
MEM_TOTAL=`$CMD info | grep total_memory | cut -f2 -d":"`
echo "Xen running with $NUM_DOMU DomUs. $MEM_FREE MB of$MEM_TOTAL MB free."
return 0
}
case "$1" in
start)
start
RETVAL=$?
;;
stop)
stop
RETVAL=$?
;;
status)
status
RETVAL=$?
;;
restart)
stop
start
;;
esac
[-- Attachment #3: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 3:01 EL6 initscript feedback Steven Haigh
@ 2013-05-21 11:20 ` Stefano Stabellini
2013-05-21 11:30 ` Steven Haigh
0 siblings, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2013-05-21 11:20 UTC (permalink / raw)
To: Steven Haigh; +Cc: xen-devel
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 11:20 ` Stefano Stabellini
@ 2013-05-21 11:30 ` Steven Haigh
2013-05-21 11:47 ` Gordan Bobic
0 siblings, 1 reply; 8+ messages in thread
From: Steven Haigh @ 2013-05-21 11:30 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
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?
--
Steven Haigh
Email: netwiz@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 11:30 ` Steven Haigh
@ 2013-05-21 11:47 ` Gordan Bobic
2013-05-21 12:02 ` Stefano Stabellini
0 siblings, 1 reply; 8+ messages in thread
From: Gordan Bobic @ 2013-05-21 11:47 UTC (permalink / raw)
To: Steven Haigh; +Cc: xen-devel, Stefano Stabellini
On Tue, 21 May 2013 21:30:27 +1000, Steven Haigh <netwiz@crc.id.au>
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.
Gordan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 11:47 ` Gordan Bobic
@ 2013-05-21 12:02 ` Stefano Stabellini
2013-05-21 17:00 ` Pasi Kärkkäinen
0 siblings, 1 reply; 8+ messages in thread
From: Stefano Stabellini @ 2013-05-21 12:02 UTC (permalink / raw)
To: Gordan Bobic; +Cc: xen-devel, Steven Haigh, Stefano Stabellini
On Tue, 21 May 2013, Gordan Bobic wrote:
> On Tue, 21 May 2013 21:30:27 +1000, Steven Haigh <netwiz@crc.id.au> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 12:02 ` Stefano Stabellini
@ 2013-05-21 17:00 ` Pasi Kärkkäinen
2013-05-21 18:25 ` Gordan Bobic
0 siblings, 1 reply; 8+ messages in thread
From: Pasi Kärkkäinen @ 2013-05-21 17:00 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Gordan Bobic, Steven Haigh, xen-devel
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@crc.id.au> 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).
-- Pasi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 17:00 ` Pasi Kärkkäinen
@ 2013-05-21 18:25 ` Gordan Bobic
2013-05-21 18:46 ` Pasi Kärkkäinen
0 siblings, 1 reply; 8+ messages in thread
From: Gordan Bobic @ 2013-05-21 18:25 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: xen-devel, Steven Haigh, Stefano Stabellini
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@crc.id.au> 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.
Gordan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: EL6 initscript feedback.
2013-05-21 18:25 ` Gordan Bobic
@ 2013-05-21 18:46 ` Pasi Kärkkäinen
0 siblings, 0 replies; 8+ messages in thread
From: Pasi Kärkkäinen @ 2013-05-21 18:46 UTC (permalink / raw)
To: Gordan Bobic; +Cc: xen-devel, Steven Haigh, Stefano Stabellini
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@crc.id.au> 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 virt-install,
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" commands
to generate a normal xen text cfgfile for the VM.
-- Pasi
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-05-21 18:46 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-21 3:01 EL6 initscript feedback Steven Haigh
2013-05-21 11:20 ` Stefano Stabellini
2013-05-21 11:30 ` Steven Haigh
2013-05-21 11:47 ` Gordan Bobic
2013-05-21 12:02 ` Stefano Stabellini
2013-05-21 17:00 ` Pasi Kärkkäinen
2013-05-21 18:25 ` Gordan Bobic
2013-05-21 18:46 ` Pasi Kärkkäinen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.