nyuuzyou/wikis huggingface dataset:
Shutting down a VM

This page shows how to use the XenAPI to shut down a VM. The examples are written in python (feel free to add translations to other languages) and will use the API via the local Unix domain socket.
== Shutting down cleanly ==
To request a clean shutdown of a VM with a given uuid: (Note this will block for up to 20 minutes while the VM is shutting down)
 #!/usr/bin/env python
 import XenAPI, sys
 
 if len(sys.argv) <> 2:
 print "Usage:"
 print sys.argv[0], "<VM uuid>"
 sys.exit(1)
 uuid = sys.argv[1]
 
 session = XenAPI.xapi_local()
 session.xenapi.login_with_password("root", "")
 try:
 vm = session.xenapi.VM.get_by_uuid(uuid)
 session.xenapi.VM.clean_shutdown(vm)
 finally:
 session.xenapi.session.logout()
== Forcibly shutting down ==
On recent version of xapi we can use:
 #!/usr/bin/env python
 import XenAPI, sys
 
 if len(sys.argv) <> 2:
 print "Usage:"
 print sys.argv[0], "<VM uuid>"
 sys.exit(1)
 uuid = sys.argv[1]
 
 session = XenAPI.xapi_local()
 session.xenapi.login_with_password("root", "")
 try:
 vm = session.xenapi.VM.get_by_uuid(uuid)
 session.xenapi.VM.hard_shutdown(vm)
 finally:
 session.xenapi.session.logout()
On older versions of xapi the above code will block, and eventually timeout, if a clean_shutdown is in progress. To forcibly shutdown a VM on older versions of xapi we must therefore cancel any running tasks operating on that VM:
 #!/usr/bin/env python
 import XenAPI, sys
 
 if len(sys.argv) <> 2:
 print "Usage:"
 print sys.argv[0], "<VM uuid>"
 sys.exit(1)
 uuid = sys.argv[1]
 
 session = XenAPI.xapi_local()
 session.xenapi.login_with_password("root", "")
 try:
 # find the VM
 vm = session.xenapi.VM.get_by_uuid(uuid)
 fields = session.xenapi.VM.get_record(vm)
 # cancel any tasks operating on the VM (e.g. clean_shutdown)
 current = fields["current_operations"]
 for t in current.keys():
 try:
 print "\n Cancelling operation on VM: %s" % fields["name_label"],
 sys.stdout.flush()
 session.xenapi.task.cancel(t)
 except Exception, e:
 print "Failed to cancel task: %s" % t,
 sys.stdout.flush()
 raise e
 session.xenapi.VM.hard_shutdown(vm)
 finally:
 session.xenapi.session.logout()
Sprint wk32

== Xapi Project Sprint wk32 - 2013.08.06 ==
=== Xapi sprint ===
This is a list the work items for the xapi team's week 32 sprint. This table references an internal ticket tracking system (CA, CP numbers). We are unable to publish this ticket system externally, but since these ticket numbers are referenced in commit messages, we are publishing the ticket numbers and their titles here. These are not meant to be full descriptions of the work to be done, but an overall summary of work that we hope to accomplish in this sprint. For discussion, please email the xen-api@lists.xen.org mailing list with a reference to the ticket number in the subject.
Internal ticket	Title of ticket 	Category
CP-5679 	XOP-375 - Unable to create a VIF with VIF_LOCKING disabled if the XS Pool has a vSwitch controller connected 	Story
CP-5643 	XAPI: preserve VGPUs' types across export/import 	Work item
CP-5642 	XAPI: preserve VGPUs' types across VM snapshot/revert/clone/copy 	Work item
CP-5607 	Compile rrdd from separate repository 	Work item
CP-5605 	Build networkd from a separate repository 	Work item
CP-5603 	Planex: Design caching / release bumping 	Work item
CP-5601 	Train & Sprint Overview Dashboard 	Work item
CP-5599 	XAPI: Make use of xenopsd VGPU type in xapi_xenops.ml 	Work item
CP-5598 	XENOPSD: Add VGPU type to xenops_interface 	Work item
CP-5574 	xenopsd/libxl: ensure no xenctrl calls are used anywhere 	Work item
CP-5573 	xenopsd/libxl: use libxl events instead of xenstore watches 	Work item
CP-5572 	xenopsd/libxl: cleanup/remove unused code 	Work item
CP-5340 	Ability to toggle-off Xapi startup actions 	Story
CP-4408 	Use xcp-idl for all interfaces 	Work item
CA-105903 	Surprise remove not checked in Tampa 	Bug
CA-105021 	Incorrect console URL with HMN disabled 	Bug
CA-104877 	XOP-218 document semantics of VM.xenstore_data 	Bug
CA-86347 	PR-1255: Cross Pool VM migration fails when VM is force rebooted using command "reboot -f" from inside VM's console	Bug
Storage driver domains

This guide will focus on setting up a Linux or FreeBSD guest that will serve disk backends to other guests.
===Linux storage domain set up===
The first step is to create a Linux PV guest, this will not be explained in this guide since it's assumed that the user has the basic knowledge about how to create new guests. Once the guest is set up, you will need to clone the Xen source code inside the guest:
$ git clone git://xenbits.xen.org/xen.git
$ cd xen
Now we will install the hotplug scripts, udev rules and the necessary Xen tools in order to detect and attach the storage devices to the guest, we need to install a couple of dependencies in order to install all this tools:
# apt-get install build-essential python-dev gettext bcc bin86 iasl uuid-dev ncurses-dev libglib2.0-dev libyajl-dev
# ./configure
# make -C tools/include/ install
# make -C tools/libxc/ install
# make -C tools/xenstore/ install
# make -C tools/hotplug/ install
# mkdir -p /var/log/xen
Now we have the store domain correctly set up, but we have to manually mount xenfs each time the system boots, using the following command:
# mount -t xenfs xenfs /proc/xen
This can be added to /etc/rc.local so it is executed automatically at system boot.
===FreeBSD storage domain set up===
Setting up a FreeBSD storage driver domain using ZFS is easier than doing it with Linux, first we need a FreeBSD DomU that's running the XENHVM kernel if using FreeBSD 9, or the GENERIC kernel if using FreeBSD 10 or newer versions. In the next steps we will setup a ZFS RAIDZ and we will create a volume that will be used as a disk for another DomU:
# echo 'zfs_enable="YES"' >> /etc/rc.conf
# zpool create tank raidz ad1 ad2
# zfs create -V 5g tank/guest
Replace ad1 and ad2 with the physical disks you would like to use to setup the RAIDZ, and guest with the desired name of the volume you wish to create. This are the only steps necessary to setup the volumes inside the driver domain, now on your DomU config file you should use the following path: /dev/zvol/tank/guest.
===Guest configuration===
In order to use a disk that resides in a domain different than Dom0, the guest config file should use a disk specification similar to the following:
'format=raw,backendtype=phy,backend=<driver_domain_name>,vdev=xvda,target=<block_device_path_in_driver_domain>',
It is not possible to use driver domains with pygrub or HVM guests yet, so it will only work with PV guests that have the kernel in Dom0.
Category:Tutorial
Category:HowTo
Category:FreeBSD
Category:Xen
Category:Users
Category:Security
Storage options

This document lists some common considerations for when you are instaling a host OS with the intention of running Xen.
==Guest Storage==
Before installing a host (domain 0) OS it is useful to consider where you are intending to store the guest OS disk images. This is especially important if you are intending to store the guest disk images locally.
===Local Storage===
There are two main choices for local storage of guest disk images. You can either use a tool such a Linux's LVM to carve up your physical disk into multiple block devices, each of which can be used as a guest disk, or you can store guest disk images as files (using either raw, qcow2 or vhd format) on a local filesystem.
Using a block device based storage configuration, such as LVM, allows you to take advantage of the blkback driver which performs better than the drivers which support disk image storage (e.g. blktap or qdisk). Disk image based solutions typically offer slower performance but are more flexible in some areas (e.g. snapshotting, master/gold image deployments)
It is possible to mix and match the two approaches, for example by setting up the system using LVM and creating a single large Logical Volume with a file system to contain disk images.
It is recommended to plan for LVM when installing your host and to use it where possible.
====Linux Logical Volume Manager (LVM)====
In order to use Logical Volumes (LVs) as guest disks you should be sure to set aside enough of your physical disk space to create a LVM Volume Group (VG) to contain your disk images. This means that at installation time you will need to setup your partitioning scheme with a large partition configuration for use as an LVM Physical Volume (PV).
You may also be able to use LVM for your host OS root partition, swap, etc depending on the domain 0 OS. There is no particular harm in storing these host level volumes in the same VG as you intend to use for guest storage.
For a system which is to be a dedicated Xen Project host primarily used to run guests (i.e. only minimal services in domain 0) a good rule of thumb is to set aside 4-8GB (depending on host OS) for the domain 0 root filesystem, plus some amount of swap space and if necessary a small /boot partition and to leave the rest of the disk (or PV) spare to serve as guest storage.
====File Backed Storage====
There are fewer install time considerations with file backend storage since you can, if you like, just use the large root filesystem of your domain 0 install.
However even if you intend to use solely file backed storage you should consider configuring LVM with a single large Logical Volume in order to give yourself flexibility in the future.
===Remote Storage===
If you intend to store guest disk images remotely (e.g. on the network using NFS or iSCSI) then there isn't much to be considered at host OS installation time.
Category:Host Install
Category:Host Configuration
Category:Users
Category:Beginners
Category:Performance
Category:Fundamentals
StubDom

Stubdoms (or stub domains) are lightweight 'service' or 'driver' domain to run device models and one technique to implement Dom0 Disaggregation. The initial purpose of stub domains were to offload qemu workloads from dom0 into a seperate domain.
So with stub domains, a separate unprivileged stub domain is created per HVM guest. This boosts performance and makes your system more secure.
= Xen 4.x : Device Model Stub Domains =
For XL and newer versions of Xen, please see Device Model Stub Domains, which contains simple configuration examples for how to set up.
= Xen 3.x =
For older version of Xen, stub domains are harder to set up.
== Configuration Example ==
* /etc/xen/OVM_EL5U1_X86_HVM_4GB:
<nowiki>
name = 'OVM_EL5U1_X86_HVM_4GB'
uuid = 'de0edfdc-c6f1-4d2b-a2a3-88c035208c79'
builder = 'hvm'
device_model = '/usr/lib/xen/bin/stubdom-dm'
kernel = '/usr/lib/xen/boot/hvmloader'
memory = '256'
vif = [ 'mac=00:16:3e:6b:66:d7,bridge=xenbr0', ]
disk = [ 'file:/share/vm/OVM_EL5U1_X86_HVM_4GB/system.img,hda,w!', ]
acpi = 1
apic = 1
pae = 1
vcpus = 1
sdl = 0
vnc = 1
vnclisten = '192.168.1.199'
on_crash = 'restart'
on_reboot = 'restart'
</nowiki>
Note: you can comment the disk statement here; but if you want use pvhvm drivers, you should leave it uncommented.
* /etc/xen/OVM_EL5U1_X86_HVM_4GB-dm:
<nowiki>
disk = [ 'file:/share/vm/OVM_EL5U1_X86_HVM_4GB/system.img,hda,w!', ]
kernel = "/usr/lib/xen/boot/ioemu-stubdom.gz"
#vfb = [ 'type=sdl' ]
#vfb = [ 'type=vnc' ]
vif = [ 'ip=192.168.1.199', 'mac=00:16:3e:6b:66:d7,bridge=xenbr0', ]
</nowiki>
* Create the VM:
<nowiki>
# mkdir -p /exports/usr/share/xen/qemu
# ln -s /usr/share/xen/qemu/keymaps /exports/usr/share/xen/qemu
# mkdir -p /exports/var/lib
# ln -s /var/lib/xen /exports/var/lib
# /usr/sbin/fs-backend &
# xm create OVM_EL5U1_X86_HVM_4GB
</nowiki>
* Connect to the VNC:
<nowiki>
$ vncviewer 192.168.1.199
</nowiki>
Note: you should make sure the host running vncviewer is in the same subnet 192.168.1.0.
= Reference =
* 2008 Boston Xen Summit slides on Stubdom.
* Xen 3.3 Feature: Stub Domains.
* Xen 3.3 Feature: HVM Device Model Domain.
* Stubdom README.
Category:Xen
Category:Users
Category:Performance
Category:Security
TCT Meeting/April 2014 Minutes

= Attendees =
* Ian Campbell
* Konrad Rzeszutek Wilk
* James Bulpin
* Aravind Gopalakrishnan
* Paul Durrant
* Jun Nakajima
* Jan Beulich
* Olaf Herring
* Suravee Suthikulpanit
* Simon Rowe
* Daniel Kiper
* Boris Ostrovsky
= Call membership =
= Review ACTION items =
* Action Don & Jun: Don and Jun will chase up VMX maintainers inside Intel re: GPU Passthrough and cache attributes to "comment on certain aspects of EPT and why IOMMU related things are done the way they are".
** Jan: The particular issue was acked. But better responsiveness to issue brought up on the list is desirable
** Don: Intel have taken this on board and are working improve responsiveness.
** Konrad: Boris' patches for perf have not been acked by VMX maintainers for 3 weeks now.
** Don: Will chase this
= Current technical challenges =
* Release Manager for 4.5
** Jan: Where are we with finding a release manager. Do we want to have one
** Ian: George was searching for a successor, but didn't managed to sync up with him. We should have an RM.
** Konrad: What is required, thinking of putting his hat in the ring.
** Ian: Keeping the backlog list and saying no to people. Speak to George?
= Coordination on current and future work =
* Konrad: KVP. Microsoft has a mechanism where the host and guest can communicate banal information such as host type, IP, and set the IP of the guest.
** Oracle have a similar tool.
** XenServer does too.
** Distros all have the MS userspace daemon and kernel space driver.
** Should the host expose via libxl or vendor specific bits of toolstack?
** Paul: Can the driver be replaced and leave the userspace alone?
** Konrad: I think so, but the daemon uses a socket. Can do network script munging etc too.
** Paul: A the driver messages very specific to hyperv?
** Konrad: Yes but could replace with a more generic interface
** Ian: virtio and qemu guest agent? Might be a better fit?
** ACTION: Konrad to investigate qemu agent.
** James: qemu guest agent uses virtio serial.
** Paul: Related thing is that Windows guests could use the MS KVP even running on Xen
** Ian: Concerned about MS control of protocol.
** Konrad: Nice thing is that it is in many distros, from Fedora 18, RHEL7, Debian Wheezy, SuSE 13.3SP2.
** Ian: Seems like people want the functionality somehow.
** Konrad: But don't want to roll our own.
** Konrad: ACTION: Investigate KVP spec WRT compatibility etc.
= Community news, activities. =
* Hackathon at end of May in London, wiki page and mails to xen-devel.
** http://wiki.xenproject.org/wiki/Hackathon/May2014
Category:Technical Coordination Team
TCT Meeting/February 2014 Minutes

== Attendees ==
* Kelly Zytaruk (AMD)
* Jason Douglas (SuSE)
* Daniel Kiper (Oracle)
* Suravee Suthikulpanit (AMD)
* Jan Beulich (Novell)
* Boris Ostrovsky (Oracle)
* Daniel De Graaf (NSA)
* Olaf Hering (Novell)
* Anthony Liguori (Amazon)
* Jun Nakajima (Intel)
* Matt Wilson (Amazon)
* Sherry Hurwitz (AMD)
* Konrad Rzeszutek Wilk (Oracle)
== Review ACTION items ==
 
* PCI passthrough of Intel NIC borked: Patch has been committed.
* Kelly to mail Konrad and/or xen-devel with the current set of issues with GFX passthrough: Still corresponding and will address issues.
== Current technical challenges. ==
None raised on the call.
== Coordination on current and future work ==
Xen 4.4-rc4 on Friday.
== Community news, activities. ==
 
* GSoC, deadline on Friday:
: Matt (Amazon) adding in project for AER handling such that the guest can gracefully handle it instead of killing the guest.
Category:Technical Coordination Team
TCT Meeting/July 2013 Minutes

= Attendees =
* Andres Lagar-Cavilla
* Boris Ostrovsky
* Daniel De Graf
* Don Dugger
* George Dunlap
* James Bulpin
* Konrad Rzeszutek Wilk
* Lars Kurth
* Matt Wilson
* Sherry Hurwitz
* Ian Campbell
= Review ACTIONS =
* Nested HVM:
** Don:
 thread didn't happen but work is on going.
** Sherry: 
 AMD is actively testing
 Christoph Egger has helped out a bit
 ACTION: Carried over, was started in May, but not much activity due to vacations
* Konrad: to approach Coverity about free service and ask about security
 Lars offered to sync up with Coverity at CLS ... no Coverty rep attended
= Ongoing work =
Boris: How do we handle incomplete features in Xen?
George: depends on size and risk of feature. We can mark it as experimental. Note that we don't have a separate staging tree, so we tend to not compile incomplete features by default. Example boot options (not enabled by default).
Konrad: asked whether we had a general rule/guidance about this
George: We tend to #ifdef incomplete code out. For example PVH code can be checked in with #ifdef's to reduce the need for catch-ups. There is also the option to host personal public branches on a xenbits git tree
= Coordination on current & future work =
== Xen 4.4 Planning ==
Goals
* Shorter release cycle (from 9 to 6 months) - see George's 1st 4.4 Development Update on xen-devel. Advantages: shorter RCs, less impact if changes are missed 
Proposal:
* Plan for Jan 21st release of 4.4
* Feature freeze mid-October
 provide feedback, raise hands if this is an issue
George has an internal backlog. Big items:
* Event Channel Scalability
* PVH Mode
* Credit2 scheduler as default
* I/O improvements - see Hackathon minutes at http://wiki.xenproject.org/wiki/Hackathon#May_2013_.5BHackathon_Minutes.5D
* Elena's virtual NUMA topology work
* Nested Virt: would like to move to production in 4.4
 Kick of 4.4 planning discussion on xen-devel 
= Community news, activities =
Lars: explained that the Xen 4.3 press release gave us the best coverage since Lars took over
 send press report to list - attached 
Lars: reminded everyone of Xen User Summit and Xen Developer Summit CfPs
Question: will sessions be recorded? 
Lars: Yes, we will record screens and voice (aka voiced over presentations) and post on xenproject.org (as well as vimeo and slideshare)
= AOB =
None
Category:Technical Coordination Team
TCT Meeting/June 2014 Minutes

= Attendees =
* Don Dugger
* Jun Nakajima
* Ian Campbell
* Daniel De Graaf
* Olaf Herring
* Jim Fehlig
* Konrad Rzeszutek Wilk
* Sherry Hurwitz
* Aravind Gopalakrishnan
* Daniel Kiper
* James Bulpin
= Review ACTION items. =
* Konrad to investigate qemu agent. (Was: DEFER)
** DEFER AGAIN
* Konrad to investigate KVP spec WRT compatibility etc. (Was: DEFER)
** DEFER AGAIN
* Jun to get status on sharing EPT and VTd page tables question
** Jun: Right now we don't have issues from sharing. Jan had some concerns but not ???(I missed what was said here). Jun thinks we are OK today. At the same time might need asa feature, e.g. large pages for VT-d. Low priority.
** Konrad: Discussion at hackathon, issues when doing GFX passthrough and trying to do DMA to the cards framebuffer. Print a warning and provide a workaround? Will mail people regarding hackathon discussion
= Current technical challenges. =
* Jun: What is the status of PVH for dom0?
** Konrad: Mukesh is working on it on the Xen side. Linux 3.16 has all the patches for the dom0 parts. Would appreciate more help from others.
* Don: How to deal with conflict between maintainers. In particular co-maintainers of the same subsystem who disagree on a patch.
** Konrad: Governance model provide backstop for when consensus has failed.
** Don: Prefer consensus but try and resolve on a case by basis
** Ian: Need to highlight to the co-maintainers that the disagreement is blocking something and they need to decide.
= Coordination on current and future work. =
(e.g. planned development activities for next release(s), roadmap)
* Jim: Bamvor is looking into working on snapshotting via libxl and posting proposals but things have gone quiet.
** Ian: hasn't been following very closely but isn't really sure what is going on.
** Jim will advise him to gain consensus before working on the code much more.
** Ian: Would be useful to get a highlevel overview without getting into specifics of implementation details (e.g qdisk mechanisms)
Category:Technical Coordination Team
TCT Meeting/May 2014 Minutes

= Attendees =
* Konrad Rzeszutek Wilk
* Kelly Zytaruk
* Kelly AMD
* Sherry Hurwitz
* Jun Nakajima
* James Bulpin
* Daniel de Graaf
* Boris Ostrovsky
* Aravind Gopalakrishnan
* Ian Campbell
* Olaf Herring
* Jan Beulich
= Call membership =
= Review ACTION items =
* Boris' patches for perf have not been acked by VMX maintainers for 3 weeks now. (DONE)
* Konrad to investigate qemu agent. (DEFER)
* Konrad to investigate KVP spec WRT compatibility etc. (DEFER)
= Current technical challenges. =
* Jan: Before 4.4 we wanted to turn off sharing of EPT and VTd page tables. But performance impact due to VTd not having super pages prevented this. Intel were going to work on this, what is the status.
 ACTION: Jun to get status on that.
* Jun: Nested virtualisation, seeing regressions due to patches. Should we upstream functionality testing?
** Ian: Yes please, to osstest framework, patches on xen-devel to both Ians.
= Coordination on current and future work =
* Xen 4.5 Release manager update (Konrad)
** Posted a tentative list of 4.5 work items, no complaints, will post on xen-devel.
** Plans to follow the same freeze policies as George did.
** Goal is to release by early December, so freeze right after developer summit, end of August.
** Would be useful to have a list of things to do which aren't being done, in order that people can balance resources etc,
* Briefly discussed the form of the call and decided to keep it as is.
= Community news, activities. =
Category:Technical Coordination Team
TCT Meeting/October 2013 Minutes

= Attendees =
* Ian Campbell
* Matt Wilson
* Jan Beulich
* Boris Ostrovsky
* Ravi Suravee
* Daniel De Graaf
* Anthony Liguori
= Review ACTION items. =
* Recurring need for pings on VMX/SVM/IOMMU patches
** to figure out the focal point. Will Auld
* xend
** to reply to the 4.4 planning thread with their BLOCKERS. (Konrad: absent)
*** For Matt's, list discussion about SXP -- better to change the higher level stack. Matt will post this to xen-devel
** to write patch to warn when xm is used 
= Current technical challenges. =
* PVH next steps
** Right people not on this call
** Ian suggested to George to have a separate call
** Jan would like to be invited
= Coordination on current and future work =
* Konrad absent. All delayed to next time.
** Proposals for interships program for summer or winter in Xen ecosystem. (Konrad) see AB_Votes/Outreach_Program_For_Women_Round_7
** SR-IOV, PCI passthrough and all that fun. (Konrad)
** SR-IOV, PCI passthrough gaps. (Konrad)
* Boris. How much testing did we have for NMI injection into PV domains.
** Jan, only recently implemented in pvops, but has worked for a long time in classis/SuSE kernel
** Works for internal self NMI
** Only dom0 might receive a real hardware NMI forwarded
** Jan: Not a lot of testing of a high rate NMI (e.g. performance monitoring). Currently NMI is a rare event like a machine check.
Category:Technical Coordination Team