Wiki code for Using virt-install to Install a Domain

Hide Line numbers
1: = Using virt-install to Install a Guest
2: 
3: **Note**: this page describes the latest OpenSolaris xVM bits. Older versions may work differently.
4: 
5: The command-line utility virt-install is used for installing new guest domains. In general, you specify an installation source, some disk storage and networking, and some other parameters. You will then go through the guest OS installation process. After virt-install is done, the OS will be installed, and its configuration available via virsh. virt-manager is an alternative if you want a graphical guest installation tool. virt-install must be run as the root user.
6: 
7: Below we’ll show some typical invocations you might do. For more detailed information see [[the man page>>http://docs.sun.com/app/docs/doc/819-2240/virt-install-1m?l=en&a=view]] and the [[System Administration Guide: Virtualization Using the Solaris Operating System>>http://docs.sun.com/app/docs/doc/819-2450/gfqsj?l=en&a=view]].
8: 
9: == Configuring disk storage
10: 
11: The ~--disk option allows you to specify storage for a guest. xVM supports a number of different storage types, with various trade-offs. Some common choices are given below.
12: 
13: === Configuring a ZFS volume
14: 
15: {{{
16: --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol
17: }}}
18: 
19: This example creates a 10Gb [[ZFS volume>>http://docs.sun.com/app/docs/doc/819-5461/gaypf?l=en&a=view]]. A ZFS volume enables all the features of ZFS (checksumming, snapshots, [[cloning>>Community Group xen.cloning-domains]], etc.) to be used for guest storage. However, it means that a guest cannot be easily migrated onto a different system without transferring the storage separately (via zfs send or whatever), so this is not a good choice for guests you want to live migrate.
20: 
21: Note that tank is a ZFS filesystem mounted on the dom0 at /tank, and we’re specifying the dataset path. Unlike the zfs utilities, though, we currently have to prefix the path with a leading slash. Any intermediate datasets (here, guests/dom1) will be created as needed.
22: 
23: === Configuring a vdisk on a local filesystem
24: 
25: {{{
26: --disk path=/guests/dom1/disk0,size=10,driver=tap,subdriver=vdisk,format=vmdk
27: }}}
28: 
29: A VMDK format [[vdisk>>http://docs.sun.com/app/docs/doc/819-2240/vdiskadm-1m?a=view]] is virt-install’s default if a directory path is given, or the path doesn’t exist. This creates (or uses) a directory containing configuration information along with the files containing the image. Snapshotting and other features are provided by vdiskadm.
30: 
31: As well as VMWare’s VMDK format, vdisks also support VHD (Microsoft’s format) and VDI (VirtualBox’s format). In general, VMDK is best-performing and most widely supported. Use format=vhd or format=vdi to choose these disk formats.
32: 
33: === Configuring a vdisk over NFS
34: 
35: {{{
36: --disk path=/net/nfshost/guests/dom1/disk0,size=10,driver=tap,subdriver=vdisk,format=vmdk
37: }}}
38: 
39: As vdisks can be stored on an NFS server, they are a good choice if you want to live migrate the guest, although remember the path to the vdisk must be exactly the same on each dom0 host.
40: 
41: For successful creation and use of a vdisk hosted on NFS, the user xvm on the dom0 host must have write permission for the given path. This may involve setting ACLs on the NFS host, or simply a chown of the containing directory to the xvm user or user ID 60.
42: 
43: === Configuring an iSCSI volume
44: 
45: {{{
46: --disk path=/alias/0/iscsi/dom1/disk0,driver=phy,subdriver=iscsi
47: }}}
48: 
49: iSCSI is a networked block device. The example above uses a pre-existing iSCSI target with the alias iscsi/dom1/disk0, and LUN 0. This is useful if you have already configured iSCSI on your dom0 and have volumes available in iscsiadm list target.
50: 
51: In addition to an alias, a volume can be specified by its LUN and target ID: path=/discover/0/iqn.1986-03.com.sun:02:d5ab1c26-0a7a-c6b4-98f8-d6d267eb2561. In general, it’s simpler to use the Alias given for the target.
52: 
53: Finally, you can create a static config, in which case the volume is discovered, configured, and de-configured for you automatically. For example, given an iSCSI target at 192.168.0.70, LUN 0, and a target ID, you might specify path=/static/192.168.0.70/0/iqn.1986-03.com.sun:02:d5ab1c26-0a7a-c6b4-98f8-d6d267eb2561.
54: 
55: === Configuring a raw physical disk
56: 
57: {{{
58: --disk path=/dev/dsk/c0t1d0s4,driver=phy
59: }}}
60: 
61: You can use a block device accessible to dom0 for guest storage. This can be the best-performing method, but doesn’t allow any kind of higher-level facilities such as snapshotting. It is also difficult to live-migrate if the device refers to a local disk drive.
62: 
63: === Configuring a raw file
64: 
65: {{{
66: --disk path=/guests/dom1/disk0.img,size=10,driver=file
67: }}}
68: 
69: Raw files are not recommended: it’s almost always better to use one of the above methods instead. In particular, attempting to use raw files on a ZFS filesystem will be woefully slow.
70: 
71: == Configuring networking
72: 
73: You can specify networking for the guest via the ~--network option. Almost always, you will want to share a bridge amongst guest domains, but you can also dedicate an unused NIC, or perform host-only networking via an etherstub.
74: 
75: Most likely, you will want your guest OS to use DHCP to configure its networking setup. For this to work, a DHCP server must be available on the virtual network. By default, virt-install will automatically create a random MAC address for the guest with the Xen [[OUI>>http://standards.ieee.org/regauth/oui/index.shtml]]. If, however, your DHCP server doesn’t hand out addresses to unknown clients, you will need to specific a MAC address configured as a client on the DHCP server. In addition, most PXE and JumpStart setups require a specified MAC address.
76: 
77: The mac= setting for the ~--network option can be used to do this: be careful to specify a valid MAC address - not much validation is done. In the examples, we presume that you don’t need this option.
78: 
79: If you are running Xen on a laptop with a wireless connection as your primary NIC, you cannot use bridged mode, as the wireless chipsets typically reject any unknown MAC addresses. In this case, you can use an etherstub.
80: 
81: === Configuring a bridge
82: 
83: {{{
84: --network bridge=e1000g0
85: }}}
86: 
87: Bridged networking is used for ethernet-based sharing of a physical network resource. In the example above, a VNIC is created on top of the dom0 interface e1000g0. Alternatively, you can just specify ~--network bridge, in which case a host NIC will be automatically chosen (typically, the first UP interface on which a VNIC can be created). In fact, this is preferred, as it allows a guest domain’s config to be migrated to host machines using a different NIC as the bridge.
88: 
89: Any traffic for the guest’s MAC address is sent to the guest via the VNIC. VNICs configured on the system can be shown via dladm show-vnic. This VNIC is automatically removed once the domain is no longer running.
90: 
91: === Configuring a dedicated NIC
92: 
93: Specifying a network-setup script of vif-dedicated allows a guest to directly use a NIC on the host, without going through a VNIC. The NIC should not be configured on the host dom0. As of June 2009, it’s not possible to configure this via virt-install. To add such a NIC after installation:
94: 
95: {{{
96: virsh attach-interface dom1 bridge e1000g0 --script vif-dedicated
97: }}}
98: 
99: === Configuring an etherstub
100: 
101: {{{
102: dladm create-etherstub stub0
103: dladm set-linkprop -p mtu=1500 stub0
104: ...
105: ... --network bridge=stub0
106: }}}
107: 
108: If you specify an etherstub as your bridge NIC, then you have a form of host-only networking: no packets can leave the virtual network created on top of stub0, as it is not connected to any physical interface. An MTU of 1500 (not the default 9000) is required.
109: 
110: You would typically then install from an ISO. For a network installation to work, you’ll have to provide network services on top of the etherstub (for example, another guest might be connected to the etherstub to provide an NFS server).
111: 
112: === Configuring a VLAN
113: 
114: {{{
115: --network bridge,vlanid=2
116: }}}
117: 
118:  To configure a guest to use a particular VLAN ID, use the vlanid setting. For more information, see [[here>>Community Group xen.Bandwidth_VLAN_ID]].
119: 
120: === Configuring bandwidth control
121: 
122: {{{
123: --network bridge,capped-bandwidth=200M
124: }}}
125: 
126: The capped-bandwidth setting configures Crossbow bandwidth control. For more information, see [[here>>Community Group xen.Bandwidth_VLAN_ID]].
127: 
128: === Configuring a network mask
129: 
130: {{{
131: --extra-args "-B subnet-mask=255.255.254.0"
132: }}}
133: 
134: If you have a non-standard network mask, the guest OS’s default may not be sufficient. This example tells a Solaris guest to use a mask of 255.255.254.0. Any such options are guest-specific. Note that the ~--extra-args option only apples to -paravirt installations.
135: 
136: == Accessing the guest console
137: 
138: By default, virt-install will attempt to connect to the guest’s console when it starts, to allow an interactive installation. If you want to use a text-console install, the ~--nographics option can be used. In that case, the guests’ console is routed to the terminal from which you invoke virt-install.
139: 
140: Alternatively, specifying ~--vnc will configure a virtual frame-buffer. In general, this works for both HVM and para-virtual guests, but there are some variations, as shown below.
141: 
142: If you’re running virt-install in a graphical environment (that is, $DISPLAY is set, then it will start a VNC viewer connected to the guest console for you. Otherwise, you will see a message like this:
143: 
144: {{{
145: Unable to connect to graphical console; DISPLAY is not set.  Please connect to localhost:5900
146: Domain installation still in progress. Waiting for domain to complete installation.
147: }}}
148: 
149: Keep the virt-install process running, and connect to the VNC viewer given. Note that if you are connecting from a remote host (not dom0), you will have to configure [[dom0 VNC access>>Community Group xen.configuring-dom0]] before starting virt-install.
150: 
151: == Full examples
152: 
153: === Installing an OpenSolaris guest from an ISO
154: 
155: {{{
156: virt-install --paravirt --name dom1 --ram 1024 --nographics \
157:  --os-type=solaris --os-variant=opensolaris \
158:  --network bridge \
159:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
160:  --location /isos/osol-200906.iso
161: }}}
162: 
163: Installs OpenSolaris onto a ZFS volume from the ISO /isos/osol-200906.iso. 1024 megabytes is the recommended minimum for Solaris. As Solaris [[doesn’t yet support>>http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6634617]] a para-virtualized frame buffer, we start up a text install. After the guest starts, follow [[these instructions>>Community Group xen.opensolaris_domu]] to access the graphical installer.
164: 
165: Note that OpenSolaris currently requires networking configuration to happen via DHCP.
166: 
167: === Installing an OpenSolaris automated-install guest
168: 
169: {{{
170: virt-install --paravirt --name dom1 --ram 1024 --nographics \
171:  --os-type=solaris --os-variant=opensolaris \
172:  --network bridge \
173:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
174:  --location http://10.0.0.1:5555/space/images/osol_111b \
175:  --autocf install_service=myservice
176: }}}
177: 
178: Installs an OpenSolaris guest using the ’myservice’ AI install service from a given install media. Note that you /must/ use the IP address of the install server, not its hostname.
179: 
180: {{{
181: virt-install --paravirt --name dom1 --ram 1024 --nographics \
182:  --os-type=solaris --os-variant=opensolaris \
183:  --network bridge \
184:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
185:  --location http://10.0.0.1:5555/space/images/osol_111b \
186:  --autocf ""
187: }}}
188: 
189: Installs an OpenSolaris guest, where the guest should self-discover its install service (note: in 2009.06, AI does not yet have this capacity, but it is one of the features being investigated by the development team).
190: 
191: === Installing a Windows guest
192: 
193: {{{
194: virt-install --hvm --name dom1 --ram 512 --vnc \
195:  --os-type=windows --os-variant=win2k \
196:  --network bridge \
197:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
198:  --cdrom /isos/osol-200906.iso
199: }}}
200: 
201: Since Windows doesn’t have a full-PV mode, we specify --hvm for the virtualization type, and point to the installation ISO with --cdrom.
202: 
203: With Windows installs, the guest will reboot during the installation. virt-install will keep running during this guest reboot and ensure the installation media is presented to the guest as needed.
204: 
205: === Installing a Linux guest over HTTP
206: 
207: {{{
208: virt-install --paravirt --name dom1 --ram 1024 --vnc \
209:  --os-type=linux --os-variant=fedora8 \
210:  --network bridge \
211:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
212:  --location http://fedora.mirror.facebook.net/linux/releases/10/Fedora/x86_64/os/
213: }}}
214: 
215: Some versions of Linux, such as CentOS, Fedora, and others, can install directly from HTTP. Choose a suitable mirror nearest your host dom0.
216: 
217: Note that some Linux versions such as Fedora 10 will [[not successfully install with --nographics>>https://bugzilla.redhat.com/show_bug.cgi?id=504033]], and also have problems starting X: a text install via VNC works, however.
218: 
219: Some distributions allow you to change the RTC setting (for example, Fedora has a "System clock uses UTC" checkbox). If there is such an option, leave it as UTC: even though Solaris dom0 uses a localtime RTC, the system ensures the RTC is virtualized correctly for Linux, as long as you specify the ~--os-type flag.
220: 
221: === Installing a Linux guest from an ISO image
222: 
223: {{{
224: mount -F hsfs /isos/opensuse11.iso /mnt
225: share -o ro /mnt
226: 
227: virt-install --paravirt --name dom1 --ram 1024 --vnc \
228:  --os-type=linux --os-variant=sles10 \
229:  --network bridge \
230:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
231:  --location nfs:nfshost.domain.com:/mnt
232: }}}
233: 
234: If you cannot do an HTTP install, your other option is to use NFS-over-ISO. Since Linux is unable to do ~--paravirt installs from an ISO image, you have to share the ISO image over NFS, and install that way.
235: 
236: Make sure to specify the FQDN of your NFS host. Typical Linux installations insist on using DNS to resolve the names, so won’t be able to find partial names like nfshost.domain.
237: 
238: === Installing a Solaris 10 guest from an ISO
239: 
240: {{{
241: virt-install --hvm --name dom1 --ram 1024 --vnc \
242:  --os-type=solaris --os-variant=solaris10 \
243:  --network bridge \
244:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
245:  --cdrom /isos/s10u7.iso
246: }}}
247: 
248: Solaris 10 only supports HVM mode. It’s recommended to use at least Solaris 10 Update 7, though earlier versions also work.
249: 
250: === Installing a Solaris guest with PXE
251: 
252: {{{
253: virt-install --hvm --name dom1 --ram 1024 --vnc \
254:  --os-type=solaris --os-variant=solaris10 \
255:  --network bridge,mac=00:16:3e:1b:e8:18 \
256:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
257:  --pxe
258: }}}
259: 
260: Presuming you have a PXE server set up waiting for the given MAC address, this example will start up an Solaris guest via PXE boot. Note that only HVM guests support PXE currently.
261: 
262: === Installing a Solaris Nevada guest over NFS
263: 
264: {{{
265: virt-install --paravirt --name dom1 --ram 1024 --nographics \
266:  --os-type=solaris --os-variant=opensolaris \
267:  --network bridge,mac=00:16:3e:1b:e8:18 \
268:  --disk path=/tank/guests/dom1/disk0,size=10,driver=phy,subdriver=zvol \
269:  --location nfs:netinstall.sfbay.sun.com:/export/nv/x/latest/ \
270:  --extra-args "-B subnet-mask=255.255.254.0"
271: }}}
272: 
273: This is similar to the OpenSolaris ISO install, except that we’re installing over NFS. In this case, we’ve chosen to specify a particular MAC address. We also have a non-standard subnet mask, so need to add that. Unlike OpenSolaris, Nevada has a text installer, so you can install directly from the console (this is recommended).
OpenSolaris

Top Menu

Wiki code for Using virt-install to Install a Domain

Search

Collectives

Community Group

Project

User Group

Subsites

Community Group xen Pages
