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