* 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.