1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
|
<html>
<head>
<meta http-equiv="Content-Type" content="">
<title>Libvirt the virtualization API</title>
</head>
<body bgcolor="#ffffff">
<h1 align="center">Libvirt the virtualization API</h1>
<h1>Note: this is the flat content of the <a href="index.html">web
site</a></h1>
<h1 style="text-align: center">libvirt</h1>
<h3>what is <span class="style1">libvirt?</span></h3>
<p>Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software available
under the <a href="http://www.opensource.org/licenses/lgpl-license.html">GNU
Lesser General Public License</a>. Virtualization of the Linux Operating
System means the ability to run multiple instances of Operating Systems
concurently on a single hardware system where the basic resources are driven
by a Linux instance. The library aim at providing long term stable C API
initially for the <a
href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html">Xen
paravirtualization</a> but should be able to integrate other
virtualization mechanisms, it currently also support <a
href="http://fabrice.bellard.free.fr/qemu/">QEmu</a> and <a
href="http://kvm.qumranet.com/">KVM</a>.</p>
<h2><a name="News">Releases</a></h2>
<p>Here is the list of official releases, however since it is early on in the
development of libvirt, it is preferable when possible to just use the <a
href="downloads.html">CVS version or snapshot</a>, contact the mailing list
and check the <a href="ChangeLog.html">ChangeLog</a> to gauge progresses.</p>
<h3>0.2.2: Apr 17 2007</h3>
<ul>
<li>Documentation: fix errors due to Amaya (with Simon Hernandez),
virsh uses kB not bytes (Atsushi SAKAI), add command line help to
qemud (Richard Jones), xenUnifiedRegister docs (Atsushi SAKAI),
strings typos (Nikolay Sivov), ilocalization probalem raised by
Thomas Canniot</li>
<li>Bug fixes: virsh memory values test (Masayuki Sunou), operations without
libvirt_qemud (Atsushi SAKAI), fix spec file (Florian La Roche, Jeremy
Katz, Michael Schwendt),
direct hypervisor call (Atsushi SAKAI), buffer overflow on qemu
networking command (Daniel Berrange), buffer overflow in quemud (Daniel
Berrange), virsh vcpupin bug (Masayuki Sunou), host PAE detections
and strcuctures size (Richard Jones), Xen PAE flag handling (Daniel
Berrange), bridged config configuration (Daniel Berrange), erroneous
XEN_V2_OP_SETMAXMEM value (Masayuki Sunou), memory free error (Mark
McLoughlin), set VIR_CONNECT_RO on read-only connections (S.Sakamoto),
avoid memory explosion bug (Daniel Berrange), integer overflow
for qemu CPU time (Daniel Berrange), QEMU binary path check (Daniel
Berrange)</li>
<li>Cleanups: remove some global variables (Jim Meyering), printf-style
functions checks (Jim Meyering), better virsh error messages, increase
compiler checkings and security (Daniel Berrange), virBufferGrow usage
and docs, use calloc instead of malloc/memset, replace all sprintf by
snprintf, avoid configure clobbering user's CTAGS (Jim Meyering),
signal handler error cleanup (Richard Jones), iptables internal code
claenup (Mark McLoughlin), unified Xen driver (Richard Jones),
cleanup XPath libxml2 calls, IPTables rules tightening (Daniel
Berrange), </li>
<li>Improvements: more regression tests on XML (Daniel Berrange), Python
bindings now generate exception in error cases (Richard Jones),
Python bindings for vir*GetAutoStart (Daniel Berrange),
handling of CD-Rom device without device name (Nobuhiro Itou),
fix hypervisor call to work with Xen 3.0.5 (Daniel Berrange),
DomainGetOSType for inactive domains (Daniel Berrange), multiple boot
devices for HVM (Daniel Berrange),
</li>
</ul>
<h3>0.2.1: Mar 16 2007</h3>
<ul>
<li>Various internal cleanups (Richard Jones,Daniel Berrange,Mark McLoughlin)</li>
<li>Bug fixes: libvirt_qemud daemon path (Daniel Berrange), libvirt
config directory (Daniel Berrange and Mark McLoughlin), memory leak
in qemud (Mark), various fixes on network support (Mark), avoid Xen
domain zombies on device hotplug errors (Daniel Berrange), various
fixes on qemud (Mark), args parsing (Richard Jones), virsh -t argument
(Saori Fukuta), avoid virsh crash on TAB key (Daniel Berrange), detect
xend operation failures (Kazuki Mizushima), don't listen on null socket
(Rich Jones), read-only socket cleanup (Rich Jones), use of vnc port 5900
(Nobuhiro Itou), assorted networking fixes (Daniel Berrange), shutoff and
shutdown mismatches (Kazuki Mizushima), unlimited memory handling
(Atsushi SAKAI), python binding fixes (Tatsuro Enokura)</li>
<li>Build and portability fixes: IA64 fixes (Atsushi SAKAI), dependancies
and build (Daniel Berrange), fix xend port detection (Daniel
Berrange), icompile time warnings (Mark), avoid const related
compiler warnings (Daniel Berrange), automated builds (Daniel
Berrange), pointer/int mismatch (Richard Jones), configure time
selection of drivers, libvirt spec hacking (Daniel Berrange)</li>
<li>Add support for network autostart and init scripts (Mark McLoughlin)</li>
<li>New API virConnectGetCapabilities() to detect the virtualization
capabilities of a host (Richard Jones)</li>
<li>Minor improvements: qemud signal handling (Mark), don't shutdown or reboot
domain0 (Kazuki Mizushima), QEmu version autodetection (Daniel Berrange),
network UUIDs (Mark), speed up UUID domain lookups (Tatsuro Enokura and
Daniel Berrange), support for paused QEmu CPU (Daniel Berrange), keymap
VNC attribute support (Takahashi Tomohiro and Daniel Berrange), maximum
number of virtual CPU (Masayuki Sunou), virtsh --readonly option (Rich
Jones), python bindings for new functions (Daniel Berrange)</li>
<li>Documentation updates especially on the XML formats</li>
</ul>
<h3>0.2.0: Feb 14 2007</h3>
<ul>
<li>Various internal cleanups (Mark McLoughlin, Richard Jones,
Daniel Berrange, Karel Zak)</li>
<li>Bug fixes: avoid a crash in connect (Daniel Berrange), virsh args
parsing (Richard Jones)</li>
<li>Add support for QEmu and KVM virtualization (Daniel Berrange)</li>
<li>Add support for network configuration (Mark McLoughlin)</li>
<li>Minor improvements: regression testing (Daniel Berrange),
localization string updates</li>
</ul>
<h3>0.1.11: Jan 22 2007</h3>
<ul>
<li>Finish XML <-> XM config files support</li>
<li>Remove memory leak when freeing virConf objects</li>
<li>Finishing inactive domain support (Daniel Berrange)</li>
<li>Added a Relax-NG schemas to check XML instances</li>
</ul>
<h3>0.1.10: Dec 20 2006</h3>
<ul>
<li>more localizations</li>
<li>bug fixes: VCPU info breakages on xen 3.0.3, xenDaemonListDomains buffer overflow (Daniel Berrange), reference count bug when creating Xen domains (Daniel Berrange).</li>
<li>improvements: support graphic framebuffer for Xen paravirt (Daniel Berrange), VNC listen IP range support (Daniel Berrange), support for default Xen config files and inactive domains of 3.0.4 (Daniel Berrange).</li>
</ul>
<h3>0.1.9: Nov 29 2006</h3>
<ul>
<li>python bindings: release interpeter lock when calling C (Daniel Berrange)</li>
<li>don't raise HTTP error when looking informations for a domain</li>
<li>some refactoring to use the driver for all entry points</li>
<li>better error reporting (Daniel Berrange)</li>
<li>fix OS reporting when running as non-root</li>
<li>provide XML parsing errors</li>
<li>extension of the test framework (Daniel Berrange)</li>
<li>fix the reconnect regression test</li>
<li>python bindings: Domain instances now link to the Connect to avoid garbage collection and disconnect</li>
<li>separate the notion of maximum memory and current use at the XML level</li>
<li>Fix a memory leak (Daniel Berrange)</li>
<li>add support for shareable drives</li>
<li>add support for non-bridge style networking configs for guests(Daniel Berrange)</li>
<li>python bindings: fix unsigned long marshalling (Daniel Berrange)</li>
<li>new config APIs virConfNew() and virConfSetValue() to build configs from scratch</li>
<li>hot plug device support based on Michel Ponceau patch</li>
<li>added support for inactive domains, new APIs, various associated cleanup (Daniel Berrange)</li>
<li>special device model for HVM guests (Daniel Berrange)</li>
<li>add API to dump core of domains (but requires a patched xend)</li>
<li>pygrub bootloader informations take over <os> informations</li>
<li>updated the localization strings</li>
</ul>
<h3>0.1.8: Oct 16 2006</h3>
<ul>
<li> Bug for system with page size != 4k</li>
<li> vcpu number initialization (Philippe Berthault)</li>
<li> don't label crashed domains as shut off (Peter Vetere)</li>
<li> fix virsh man page (Noriko Mizumoto)</li>
<li> blktapdd support for alternate drivers like blktap (Daniel Berrange)</li>
<li> memory leak fixes (xend interface and XML parsing) (Daniel Berrange)</li>
<li> compile fix</li>
<li> mlock/munlock size fixes (Daniel Berrange)</li>
<li> improve error reporting</li>
</ul>
<h3>0.1.7: Sep 29 2006</h3>
<ul>
<li> fix a memory bug on getting vcpu informations from xend (Daniel Berrange)</li>
<li> fix another problem in the hypercalls change in Xen changeset
86d26e6ec89b when getting domain informations (Daniel Berrange)</li>
</ul>
<h3>0.1.6: Sep 22 2006</h3>
<ul>
<li>Support for localization of strings using gettext (Daniel Berrange)</li>
<li>Support for new Xen-3.0.3 cdrom and disk configuration (Daniel Berrange)</li>
<li>Support for setting VNC port when creating domains with new
xend config files (Daniel Berrange) </li>
<li>Fix bug when running against xen-3.0.2 hypercalls (Jim Fehlig)</li>
<li>Fix reconnection problem when talking directly to http xend</li>
</ul>
<h3>0.1.5: Sep 5 2006</h3>
<ul>
<li>Support for new hypercalls change in Xen changeset 86d26e6ec89b</li>
<li>bug fixes: virParseUUID() was wrong, netwoking for paravirt guestsi
(Daniel Berrange), virsh on non-existent domains (Daniel Berrange),
string cast bug when handling error in python (Pete Vetere), HTTP
500 xend error code handling (Pete Vetere and Daniel Berrange)</li>
<li>improvements: test suite for SEXPR <-> XML format conversions (Daniel
Berrange), virsh output regression suite (Daniel Berrange), new environ
variable VIRSH_DEFAULT_CONNECT_URI for the default URI when connecting
(Daniel Berrange), graphical console support for paravirt guests
(Jeremy Katz), parsing of simple Xen config files (with Daniel Berrange),
early work on defined (not running) domains (Daniel Berrange),
virsh output improvement (Daniel Berrange</li>
</ul>
<h3>0.1.4: Aug 16 2006</h3>
<ul>
<li>bug fixes: spec file fix (Mark McLoughlin), error report problem (with
Hugh Brock), long integer in Python bindings (with Daniel Berrange), XML
generation bug for CDRom (Daniel Berrange), bug whem using number() XPath
function (Mark McLoughlin), fix python detection code, remove duplicate
initialization errors (Daniel Berrange)</li>
<li>improvements: UUID in XML description (Peter Vetere), proxy code
cleanup, virtual CPU and affinity support + virsh support (Michel
Ponceau, Philippe Berthault, Daniel Berrange), port and tty informations
for console in XML (Daniel Berrange), added XML dump to driver and proxy
support (Daniel Berrange), extention of boot options with support for
floppy and cdrom (Daniel Berrange), features block in XML to report/ask
PAE, ACPI, APIC for HVM domains (Daniel Berrange), fail saide-effect
operations when using read-only connection, large improvements to test
driver (Daniel Berrange) </li>
<li>documentation: spelling (Daniel Berrange), test driver examples.</li>
</ul>
<h3>0.1.3: Jul 11 2006</h3>
<ul>
<li>bugfixes: build as non-root, fix xend access when root, handling of
empty XML elements (Mark McLoughlin), XML serialization and parsing fixes
(Mark McLoughlin), allow to create domains without disk (Mark
McLoughlin),</li>
<li>improvement: xenDaemonLookupByID from O(n^2) to O(n) (Daniel Berrange),
support for fully virtualized guest (Jim Fehlig, DV, Mark McLoughlin)</li>
<li>documentation: augmented to cover hvm domains</li>
</ul>
<h3>0.1.2: Jul 3 2006</h3>
<ul>
<li>headers include paths fixup</li>
<li>proxy mechanism for unpriviledged read-only access by httpu</li>
</ul>
<h3>0.1.1: Jun 21 2006</h3>
<ul>
<li>building fixes: ncurses fallback (Jim Fehlig), VPATH builds (Daniel P.
Berrange)</li>
<li>driver cleanups: new entry points, cleanup of libvirt.c (with Daniel P.
Berrange)</li>
<li>Cope with API change introduced in Xen changeset 10277</li>
<li>new test driver for regression checks (Daniel P. Berrange)</li>
<li>improvements: added UUID to XML serialization, buffer usage (Karel
Zak), --connect argument to virsh (Daniel P. Berrange),</li>
<li>bug fixes: uninitialized memory access in error reporting, S-Expr
parsing (Jim Fehlig, Jeremy Katz), virConnectOpen bug, remove a TODO in
xs_internal.c</li>
<li>documentation: Python examples (David Lutterkort), new Perl binding
URL, man page update (Karel Zak)</li>
</ul>
<h3>0.1.0: Apr 10 2006</h3>
<ul>
<li>building fixes: --with-xen-distdir option (Ronald Aigner), out of tree
build and pkginfo cflag fix (Daniel Berrange)</li>
<li>enhancement and fixes of the XML description format (David Lutterkort
and Jim Fehlig)</li>
<li>new APIs: for Node information and Reboot</li>
<li>internal code cleanup: refactoring internals into a driver model, more
error handling, structure sharing, thread safety and ref counting</li>
<li>bug fixes: error message (Jim Meyering), error allocation in virsh (Jim
Meyering), virDomainLookupByID (Jim Fehlig),</li>
<li>documentation: updates on architecture, and format, typo fix (Jim
Meyering)</li>
<li>bindings: exception handling in examples (Jim Meyering), perl ones out
of tree (Daniel Berrange)</li>
<li>virsh: more options, create, nodeinfo (Karel Zak), renaming of some
options (Karel Zak), use stderr only for errors (Karel Zak), man page
(Andrew Puch)</li>
</ul>
<h3>0.0.6: Feb 28 2006</h3>
<ul>
<li>add UUID lookup and extract API</li>
<li>add error handling APIs both synchronous and asynchronous</li>
<li>added minimal hook for error handling at the python level, improved the
python bindings</li>
<li>augment the documentation and tests to cover error handling</li>
</ul>
<h3>0.0.5: Feb 23 2006</h3>
<ul>
<li>Added XML description parsing, dependance to libxml2, implemented the
creation API virDomainCreateLinux()</li>
<li>new APIs to lookup and name domain by UUID</li>
<li>fixed the XML dump when using the Xend access</li>
<li>Fixed a few more problem related to the name change</li>
<li>Adding regression tests in python and examples in C</li>
<li>web site improvement, extended the documentation to cover the XML
format and Python API</li>
<li>Added devhelp help for Gnome/Gtk programmers</li>
</ul>
<h3>0.0.4: Feb 10 2006</h3>
<ul>
<li>Fix various bugs introduced in the name change</li>
</ul>
<h3>0.0.3: Feb 9 2006</h3>
<ul>
<li>Switch name from from 'libvir' to libvirt</li>
<li>Starting infrastructure to add code examples</li>
<li>Update of python bindings for completeness</li>
</ul>
<h3>0.0.2: Jan 29 2006</h3>
<ul>
<li>Update of the documentation, web site redesign (Diana Fong)</li>
<li>integration of HTTP xend RPC based on libxend by Anthony Liquori for
most operations</li>
<li>Adding Save and Restore APIs</li>
<li>extended the virsh command line tool (Karel Zak)</li>
<li>remove xenstore transactions (Anthony Liguori)</li>
<li>fix the Python bindings bug when domain and connections where freed</li>
</ul>
<h3>0.0.1: Dec 19 2005</h3>
<ul>
<li>First release</li>
<li>Basic management of existing Xen domains</li>
<li>Minimal autogenerated Python bindings</li>
</ul>
<h2><a name="Introducti">Introduction</a></h2>
<p>Libvirt is a C toolkit to interact with the virtualization capabilities of
recent versions of Linux (and other OSes), but libvirt won't try to provide
all possible interfaces for interacting with the virtualization features.</p>
<p>To avoid ambiguity about the terms used here here are the definitions for
some of the specific concepts used in libvirt documentation:</p>
<ul>
<li>a <strong>node</strong> is a single physical machine</li>
<li>an <strong>hypervisor</strong> is a layer of software allowing to
virtualize a node in a set of virtual machines with possibly different
configurations than the node itself</li>
<li>a <strong>domain</strong> is an instance of an operating system running
on a virtualized machine provided by the hypervisor</li>
</ul>
<p style="text-align: center"><img
alt="Hypervisor and domains running on a node" src="node.gif"></p>
<p>Now we can define the goal of libvirt: to provide the lowest possible
generic and stable layer to manage domains on a node.</p>
<p>This implies the following:</p>
<ul>
<li>the API should not be targetted to a single virtualization environment
though Xen is the current default, which also means that some very
specific capabilities which are not generic enough may not be provided as
libvirt APIs</li>
<li>the API should allow to do efficiently and cleanly all the operations
needed to manage domains on a node</li>
<li>the API will not try to provide hight level multi-nodes management
features like load balancing, though they could be implemented on top of
libvirt</li>
<li>stability of the API is a big concern, libvirt should isolate
applications from the frequent changes expected at the lower level of the
virtualization framework</li>
</ul>
<p>So libvirt should be a building block for higher level management tools
and for applications focusing on virtualization of a single node (the only
exception being domain migration between node capabilities which may need to
be added at the libvirt level). Where possible libvirt should be extendable
to be able to provide the same API for remote nodes, however this is not the
case at the moment, the code currently handle only local node accesses
(extension for remote access support is being worked on, see <a
href="bugs.html">the mailing list</a> discussions about it).</p>
<h2><a name="architecture">libvirt architecture</a></h2>
<p>Currently libvirt supports 2 kind of virtualization, and its
internal structure is based on a driver model which simplifies adding new
engines:</p>
<ul>
<li><a href="#Xen">Xen hypervisor</a></li>
<li><a href="#QEmu">QEmu and KVM based virtualization</a></li>
<li><a href="#drivers">the driver architecture</a></li>
</ul>
<h3><a name="Xen">Libvirt Xen support</a></h3>
<p>When running in a Xen environment, programs using libvirt have to execute
in "Domain 0", which is the primary Linux OS loaded on the machine. That OS
kernel provides most if not all of the actual drivers used by the set of
domains. It also runs the Xen Store, a database of informations shared by the
hypervisor, the kernels, the drivers and the xen daemon. Xend. The xen daemon
supervise the control and execution of the sets of domains. The hypervisor,
drivers, kernels and daemons communicate though a shared system bus
implemented in the hypervisor. The figure below tries to provide a view of
this environment:</p>
<img src="architecture.gif" alt="The Xen architecture">
<p>The library can be initialized in 2 ways depending on the level of
priviledge of the embedding program. If it runs with root access,
virConnectOpen() can be used, it will use three different ways to connect to
the Xen infrastructure:</p>
<ul>
<li>a connection to the Xen Daemon though an HTTP RPC layer</li>
<li>a read/write connection to the Xen Store</li>
<li>use Xen Hypervisor calls</li>
<li>when used as non-root libvirt connect to a proxy daemon running
as root and providing read-only support</li>
</ul>
<p>The library will usually interact with the Xen daemon for any operation
changing the state of the system, but for performance and accuracy reasons
may talk directly to the hypervisor when gathering state informations at
least when possible (i.e. when the running program using libvirt has root
priviledge access).</p>
<p>If it runs without root access virConnectOpenReadOnly() should be used to
connect to initialize the library. It will then fork a libvirt_proxy
program running as root and providing read_only access to the API, this is
then only useful for reporting and monitoring.</p>
<h3><a name="QEmu">Libvirt QEmu and KVM support</a></h3>
<p>The model for QEmu and KVM is completely similar, basically KVM is based
on QEmu for the process controlling a new domain, only small details differs
between the two. In both case the libvirt API is provided by a controlling
process forked by libvirt in the background and which launch and control the
QEmu or KVM process. That program called libvirt_qemud talks though a specific
protocol to the library, and connects to the console of the QEmu process in
order to control and report on its status. Libvirt tries to expose all the
emulations models of QEmu, the selection is done when creating the new
domain, by specifying the architecture and machine type targetted.</p>
<p>The code controlling the QEmu process is available in the
<code>qemud/</code> directory.</p>
<h3><a name="drivers">the driver based architecture</a></h3>
<p>As the previous section explains, libvirt can communicate using different
channels with the current hypervisor, and should also be able to use
different kind of hypervisor. To simplify the internal design, code, ease
maintainance and simplify the support of other virtualization engine the
internals have been structured as one core component, the libvirt.c module
acting as a front-end for the library API and a set of hypvisor drivers
defining a common set of routines. That way the Xen Daemon accces, the Xen
Store one, the Hypervisor hypercall are all isolated in separate C modules
implementing at least a subset of the common operations defined by the
drivers present in driver.h:</p>
<ul>
<li>xend_internal: implements the driver functions though the Xen
Daemon</li>
<li>xs_internal: implements the subset of the driver availble though the
Xen Store</li>
<li>xen_internal: provide the implementation of the functions possible via
direct hypervisor access</li>
<li>proxy_internal: provide read-only Xen access via a proxy, the proxy code
is in the <code>proxy/</code>directory.</li>
<li>xm_internal: provide support for Xen defined but not running
domains.</li>
<li>qemu_internal: implement the driver functions for QEmu and
KVM virtualization engines. It also uses a qemud/ specific daemon
which interracts with the QEmu process to implement libvirt API.</li>
<li>test: this is a test driver useful for regression tests of the
front-end part of libvirt.</li>
</ul>
<p>Note that a given driver may only implement a subset of those functions,
(for example saving a Xen domain state to disk and restoring it is only
possible though the Xen Daemon), in that case the driver entry points for
unsupported functions are initialized to NULL.</p>
<p></p>
<h2><a name="Downloads">Downloads</a></h2>
<p>The latest versions of libvirt can be found on the <a
href="ftp://libvirt.org/libvirt/">libvirt.org</a> server ( <a
href="http://libvirt.org/sources/">HTTP</a>, <a
href="ftp://libvirt.org/libvirt/">FTP</a>). You will find there the released
versions as well as <a
href="http://libvirt.org/sources/libvirt-cvs-snapshot.tar.gz">snapshot
tarballs</a> updated from CVS head every hour</p>
<p>Anonymous <a href="http://ximbiot.com/cvs/cvshome/docs/">CVS</a> is also
available, first register onto the server:</p>
<p><code>cvs -d :pserver:anoncvs@libvirt.org:2401/data/cvs login</code></p>
<p>it will request a password, enter <strong>anoncvs</strong>. Then you can
checkout the development tree with:</p>
<p><code>cvs -d :pserver:anoncvs@libvirt.org:2401/data/cvs co
libvirt</code></p>
<p>Use ./autogen.sh to configure the local checkout, then <code>make</code>
and <code>make install</code>, as usual. All normal cvs commands are now
available except commiting to the base.</p>
<h2><a name="Format">XML Format</a></h2>
<p>This section describes the XML format used to represent domains, there are
variations on the format based on the kind of domains run and the options
used to launch them:</p>
<ul>
<li><a href="#Normal1">Normal paravirtualized Xen domains</a></li>
<li><a href="#Fully1">Fully virtualized Xen domains</a></li>
<li><a href="#KVM1">KVM domains</a></li>
<li><a href="#Net1">Networking options for QEmu and KVM</a></li>
<li><a href="#QEmu1">QEmu domains</a></li>
<li><a href="#Capa1">Discovering virtualization capabilities</a></li>
</ul>
<p>The formats try as much as possible to follow the same structure and reuse
elements and attributes where it makes sense.</p>
<h3 id="Normal"><a name="Normal1" id="Normal1">Normal paravirtualized Xen
guests</a>:</h3>
<p>The library use an XML format to describe domains, as input to <a
href="html/libvirt-libvirt.html#virDomainCreateLinux">virDomainCreateLinux()</a>
and as the output of <a
href="html/libvirt-libvirt.html#virDomainGetXMLDesc">virDomainGetXMLDesc()</a>,
the following is an example of the format as returned by the shell command
<code>virsh xmldump fc4</code> , where fc4 was one of the running domains:</p>
<pre><domain type='xen' <span style="color: #0071FF; background-color: #FFFFFF">id='18'</span>>
<name>fc4</name>
<span style="color: #00B200; background-color: #FFFFFF"><os>
<type>linux</type>
<kernel>/boot/vmlinuz-2.6.15-1.43_FC5guest</kernel>
<initrd>/boot/initrd-2.6.15-1.43_FC5guest.img</initrd>
<root>/dev/sda1</root>
<cmdline> ro selinux=0 3</cmdline>
</os></span>
<memory>131072</memory>
<vcpu>1</vcpu>
<devices>
<span style="color: #FF0080; background-color: #FFFFFF"><disk type='file'>
<source file='/u/fc4.img'/>
<target dev='sda1'/>
</disk></span>
<span style="color: #0000FF; background-color: #FFFFFF"><interface type='bridge'>
<source bridge='xenbr0'/>
<mac address='</span><span style="color: #0000FF; background-color: #FFFFFF"></span><span style="color: #0000FF; background-color: #FFFFFF">aa:00:00:00:00:11'/>
<script path='/etc/xen/scripts/vif-bridge'/>
</interface></span>
<span style="color: #FF8000; background-color: #FFFFFF"><console tty='/dev/pts/5'/></span>
</devices>
</domain></pre>
<p>The root element must be called <code>domain</code> with no namespace, the
<code>type</code> attribute indicates the kind of hypervisor used, 'xen' is
the default value. The <code>id</code> attribute gives the domain id at
runtime (not however that this may change, for example if the domain is saved
to disk and restored). The domain has a few children whose order is not
significant:</p>
<ul>
<li>name: the domain name, preferably ASCII based</li>
<li>memory: the maximum memory allocated to the domain in kilobytes</li>
<li>vcpu: the number of virtual cpu configured for the domain</li>
<li>os: a block describing the Operating System, its content will be
dependant on the OS type
<ul>
<li>type: indicate the OS type, always linux at this point</li>
<li>kernel: path to the kernel on the Domain 0 filesystem</li>
<li>initrd: an optional path for the init ramdisk on the Domain 0
filesystem</li>
<li>cmdline: optional command line to the kernel</li>
<li>root: the root filesystem from the guest viewpoint, it may be
passed as part of the cmdline content too</li>
</ul>
</li>
<li>devices: a list of <code>disk</code>, <code>interface</code> and
<code>console</code> descriptions in no special order</li>
</ul>
<p>The format of the devices and their type may grow over time, but the
following should be sufficient for basic use:</p>
<p>A <code>disk</code> device indicates a block device, it can have two
values for the type attribute either 'file' or 'block' corresponding to the 2
options availble at the Xen layer. It has two mandatory children, and one
optional one in no specific order:</p>
<ul>
<li>source with a file attribute containing the path in Domain 0 to the
file or a dev attribute if using a block device, containing the device
name ('hda5' or '/dev/hda5')</li>
<li>target indicates in a dev attribute the device where it is mapped in
the guest</li>
<li>readonly an optional empty element indicating the device is
read-only</li>
</ul>
<p>An <code>interface</code> element describes a network device mapped on the
guest, it also has a type whose value is currently 'bridge', it also have a
number of children in no specific order:</p>
<ul>
<li>source: indicating the bridge name</li>
<li>mac: the optional mac address provided in the address attribute</li>
<li>ip: the optional IP address provided in the address attribute</li>
<li>script: the script used to bridge the interfcae in the Domain 0</li>
<li>target: and optional target indicating the device name.</li>
</ul>
<p>A <code>console</code> element describes a serial console connection to
the guest. It has no children, and a single attribute <code>tty</code> which
provides the path to the Pseudo TTY on which the guest console can be
accessed</p>
<p>Life cycle actions for the domain can also be expressed in the XML format,
they drive what should be happening if the domain crashes, is rebooted or is
poweroff. There is various actions possible when this happen:</p>
<ul>
<li>destroy: The domain is cleaned up (that's the default normal processing
in Xen)</li>
<li>restart: A new domain is started in place of the old one with the same
configuration parameters</li>
<li>preserve: The domain will remain in memory until it is destroyed
manually, it won't be running but allows for post-mortem debugging</li>
<li>rename-restart: a variant of the previous one but where the old domain
is renamed before being saved to allow a restart</li>
</ul>
<p>The following could be used for a Xen production system:</p>
<pre><domain>
...
<on_reboot>restart</on_reboot>
<on_poweroff>destroy</on_poweroff>
<on_crash>rename-restart</on_crash>
...
</domain></pre>
<p>While the format may be extended in various ways as support for more
hypervisor types and features are added, it is expected that this core subset
will remain functional in spite of the evolution of the library.</p>
<h3 id="Fully"><a name="Fully1" id="Fully1">Fully virtualized guests</a>
(added in 0.1.3):</h3>
<p>Here is an example of a domain description used to start a fully
virtualized (a.k.a. HVM) Xen domain. This requires hardware virtualization
support at the processor level but allows to run unmodified operating
systems:</p>
<pre><domain type='xen' id='3'>
<name>fv0</name>
<uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid>
<os>
<span style="color: #0000E5; background-color: #FFFFFF"><type>hvm</type></span>
<span style="color: #0000E5; background-color: #FFFFFF"><loader>/usr/lib/xen/boot/hvmloader</loader></span>
<span style="color: #0000E5; background-color: #FFFFFF"><boot dev='hd'/></span>
</os>
<memory>524288</memory>
<vcpu>1</vcpu>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<features>
<span style="color: #E50000; background-color: #FFFFFF"><pae/>
<acpi/>
<apic/></span>
</features>
<devices>
<span style="color: #0000E5; background-color: #FFFFFF"><emulator>/usr/lib/xen/bin/qemu-dm</emulator></span>
<interface type='bridge'>
<source bridge='xenbr0'/>
<mac address='00:16:3e:5d:c7:9e'/>
<script path='vif-bridge'/>
</interface>
<disk type='file'>
<source file='/root/fv0'/>
<target <span style="color: #0000E5; background-color: #FFFFFF">dev='hda'</span>/>
</disk>
<disk type='file' <span style="color: #0000E5; background-color: #FFFFFF">device='cdrom'</span>>
<source file='/root/fc5-x86_64-boot.iso'/>
<target <span style="color: #0000E5; background-color: #FFFFFF">dev='hdc'</span>/>
<readonly/>
</disk>
<disk type='file' <span style="color: #0000E5; background-color: #FFFFFF">device='floppy'</span>>
<source file='/root/fd.img'/>
<target <span style="color: #0000E5; background-color: #FFFFFF">dev='fda'</span>/>
</disk>
<span style="color: #0000E5; background-color: #FFFFFF"><graphics type='vnc' port='5904'/></span>
</devices>
</domain></pre>
<p>There is a few things to notice specifically for HVM domains:</p>
<ul>
<li>the optional <code><features></code> block is used to enable
certain guest CPU / system features. For HVM guests the following
features are defined:
<ul>
<li><code>pae</code> - enable PAE memory addressing</li>
<li><code>apic</code> - enable IO APIC</li>
<li><code>acpi</code> - enable ACPI bios</li>
</ul>
</li>
<li>the <code><os></code> block description is very different, first
it indicates that the type is 'hvm' for hardware virtualization, then
instead of a kernel, boot and command line arguments, it points to an os
boot loader which will extract the boot informations from the boot device
specified in a separate boot element. The <code>dev</code> attribute on
the <code>boot</code> tag can be one of:
<ul>
<li><code>fd</code> - boot from first floppy device</li>
<li><code>hd</code> - boot from first harddisk device</li>
<li><code>cdrom</code> - boot from first cdrom device</li>
</ul>
</li>
<li>the <code><devices></code> section includes an emulator entry
pointing to an additional program in charge of emulating the devices</li>
<li>the disk entry indicates in the dev target section that the emulation
for the drive is the first IDE disk device hda. The list of device names
supported is dependant on the Hypervisor, but for Xen it can be any IDE
device <code>hda</code>-<code>hdd</code>, or a floppy device
<code>fda</code>, <code>fdb</code>. The <code><disk></code> element
also supports a 'device' attribute to indicate what kinda of hardware to
emulate. The following values are supported:
<ul>
<li><code>floppy</code> - a floppy disk controller</li>
<li><code>disk</code> - a generic hard drive (the default it
omitted)</li>
<li><code>cdrom</code> - a CDROM device</li>
</ul>
For Xen 3.0.2 and earlier a CDROM device can only be emulated on the
<code>hdc</code> channel, while for 3.0.3 and later, it can be emulated
on any IDE channel.</li>
<li>the <code><devices></code> section also include at least one
entry for the graphic device used to render the os. Currently there is
just 2 types possible 'vnc' or 'sdl'. If the type is 'vnc', then an
additional <code>port</code> attribute will be present indicating the TCP
port on which the VNC server is accepting client connections.</li>
</ul>
<p>It is likely that the HVM description gets additional optional elements
and attributes as the support for fully virtualized domain expands,
especially for the variety of devices emulated and the graphic support
options offered.</p>
<h3><a name="KVM1">KVM domain (added in 0.2.0)</a></h3>
<p>Support for the <a href="http://kvm.qumranet.com/">KVM virtualization</a>
is provided in recent Linux kernels (2.6.20 and onward). This requires
specific hardware with acceleration support and the availability of the
special version of the <a
href="http://fabrice.bellard.free.fr/qemu/">QEmu</a> binary. Since this
relies on QEmu for the machine emulation like fully virtualized guests the
XML description is quite similar, here is a simple example:</p>
<pre><domain <span style="color: #FF0000; background-color: #FFFFFF">type='kvm'</span>>
<name>demo2</name>
<uuid>4dea24b3-1d52-d8f3-2516-782e98a23fa0</uuid>
<memory>131072</memory>
<vcpu>1</vcpu>
<os>
<type>hvm</type>
</os>
<devices>
<span style="color: #FF0000; background-color: #FFFFFF"><emulator>/home/user/usr/kvm-devel/bin/qemu-system-x86_64</emulator></span>
<disk type='file' device='disk'>
<source file='/home/user/fedora/diskboot.img'/>
<target dev='hda'/>
</disk>
<interface <span style="color: #FF0000; background-color: #FFFFFF">type='user'</span>>
<mac address='24:42:53:21:52:45'/>
</interface>
<graphics type='vnc' port='-1'/>
</devices>
</domain></pre>
<p>The specific points to note if using KVM are:</p>
<ul>
<li>the top level domain element carries a type of 'kvm'</li>
<li>the <devices> emulator points to the special qemu binary required
for KVM</li>
<li>networking interface definitions definitions are somewhat different due
to a different model from Xen see below</li>
</ul>
<p>except those points the options should be quite similar to Xen HVM
ones.</p>
<h3><a name="Net1">Networking options for QEmu and KVM (added in 0.2.0)</a></h3>
<p>The networking support in the QEmu and KVM case is more flexible, and
support a variety of options:</p>
<ol>
<li>Userspace SLIRP stack
<p>Provides a virtual LAN with NAT to the outside world. The virtual
network has DHCP & DNS services and will give the guest VM addresses
starting from <code>10.0.2.15</code>. The default router will be
<code>10.0.2.2</code> and the DNS server will be <code>10.0.2.3</code>.
This networking is the only option for unprivileged users who need their
VMs to have outgoing access. Example configs are:</p>
<pre><interface type='user'/></pre>
<pre>
<interface type='user'>
<mac address="11:22:33:44:55:66:/>
</interface>
</pre>
</li>
<li>Virtual network
<p>Provides a virtual network using a bridge device in the host.
Depending on the virtual network configuration, the network may be
totally isolated,NAT'ing to aan explicit network device, or NAT'ing to
the default route. DHCP and DNS are provided on the virtual network in
all cases and the IP range can be determined by examining the virtual
network config with '<code>virsh net-dumpxml <network
name></code>'. There is one virtual network called'default' setup out
of the box which does NAT'ing to the default route and has an IP range of
<code>192.168.22.0/255.255.255.0</code>. Each guest will have an
associated tun device created with a name of vnetN, which can also be
overriden with the <target> element. Example configs are:</p>
<pre><interface type='network'>
<source network='default'/>
</interface>
<interface type='network'>
<source network='default'/>
<target dev='vnet7'/>
<mac address="11:22:33:44:55:66:/>
</interface>
</pre>
</li>
<li>Bridge to to LAN
<p>Provides a bridge from the VM directly onto the LAN. This assumes
there is a bridge device on the host which has one or more of the hosts
physical NICs enslaved. The guest VM will have an associated tun device
created with a name of vnetN, which can also be overriden with the
<target> element. The tun device will be enslaved to the bridge.
The IP range / network configuration is whatever is used on the LAN. This
provides the guest VM full incoming & outgoing net access just like a
physical machine. Examples include:</p>
<pre><interface type='bridge'>
<source dev='br0'/>
</interface>
<interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
<mac address="11:22:33:44:55:66:/>
</interface> <interface type='bridge'>
<source dev='br0'/>
<target dev='vnet7'/>
<mac address="11:22:33:44:55:66:/>
</interface></pre>
</li>
<li>Generic connection to LAN
<p>Provides a means for the administrator to execute an arbitrary script
to connect the guest's network to the LAN. The guest will have a tun
device created with a name of vnetN, which can also be overriden with the
<target> element. After creating the tun device a shell script will
be run which is expected to do whatever host network integration is
required. By default this script is called /etc/qemu-ifup but can be
overriden.</p>
<pre><interface type='ethernet'/>
<interface type='ethernet'>
<target dev='vnet7'/>
<script path='/etc/qemu-ifup-mynet'/>
</interface></pre>
</li>
<li>Multicast tunnel
<p>A multicast group is setup to represent a virtual network. Any VMs
whose network devices are in the same multicast group can talk to each
other even across hosts. This mode is also available to unprivileged
users. There is no default DNS or DHCP support and no outgoing network
access. To provide outgoing network access, one of the VMs should have a
2nd NIC which is connected to one of the first 4 network types and do the
appropriate routing. The multicast protocol is compatible with that used
by user mode linux guests too. The source address used must be from the
multicast address block.</p>
<pre><interface type='mcast'>
<source address='230.0.0.1' port='5558'/>
</interface></pre>
</li>
<li>TCP tunnel
<p>A TCP client/server architecture provides a virtual network. One VM
provides the server end of the netowrk, all other VMS are configured as
clients. All network traffic is routed between the VMs via the server.
This mode is also available to unprivileged users. There is no default
DNS or DHCP support and no outgoing network access. To provide outgoing
network access, one of the VMs should have a 2nd NIC which is connected
to one of the first 4 network types and do the appropriate routing.</p>
<p>Example server config:</p>
<pre><interface type='server'>
<source address='192.168.0.1' port='5558'/>
</interface></pre>
<p>Example client config:</p>
<pre><interface type='client'>
<source address='192.168.0.1' port='5558'/>
</interface></pre>
</li>
</ol>
<p>To be noted, options 2, 3, 4 are also supported by Xen VMs, so it is
possible to use these configs to have networking with both Xen &
QEMU/KVMs connected to each other.</p>
<h3>Q<a name="QEmu1">Emu domain (added in 0.2.0)</a></h3>
<p>Libvirt support for KVM and QEmu is the same code base with only minor
changes. The configuration is as a result nearly identical, the only changes
are related to QEmu ability to emulate <a
href="http://www.qemu.org/status.html">various CPU type and hardware
platforms</a>, and kqemu support (QEmu own kernel accelerator when the
emulated CPU is i686 as well as the target machine):</p>
<pre><domain <span style="color: #FF0000; background-color: #FFFFFF">type='qemu'</span>>
<name>QEmu-fedora-i686</name>
<uuid>c7a5fdbd-cdaf-9455-926a-d65c16db1809</uuid>
<memory>219200</memory>
<currentMemory>219200</currentMemory>
<vcpu>2</vcpu>
<os>
<span style="color: #FF0000; background-color: #FFFFFF"><type arch='i686' machine='pc'>hvm</type></span>
<boot dev='cdrom'/>
</os>
<devices>
<span style="color: #FF0000; background-color: #FFFFFF"><emulator>/usr/bin/qemu</emulator></span>
<disk type='file' device='cdrom'>
<source file='/home/user/boot.iso'/>
<target dev='hdc'/>
<readonly/>
</disk>
<disk type='file' device='disk'>
<source file='/home/user/fedora.img'/>
<target dev='hda'/>
</disk>
<interface type='network'>
<source name='default'/>
</interface>
<graphics type='vnc' port='-1'/>
</devices>
</domain></pre>
<p>The difference here are:</p>
<ul>
<li>the value of type on top-level domain, it's 'qemu' or kqemu if asking
for <a href="http://www.qemu.org/kqemu-tech.html">kernel assisted
acceleration</a></li>
<li>the os type block defines the architecture to be emulated, and
optionally the machine type, see the discovery API below</li>
<li>the emulator string must point to the right emulator for that
architecture</li>
</ul>
<h3><a name="Capa1">Discovering virtualization capabilities (Added in 0.2.1)</a></h3>
<p>As new virtualization engine support gets added to libvirt, and to handle
cases like QEmu supporting a variety of emulations, a query interface has
been added in 0.2.1 allowing to list the set of supported virtualization
capabilities on the host:</p>
<pre> char * virConnectGetCapabilities (virConnectPtr conn);</pre>
<p>The value returned is an XML document listing the virtualization
capabilities of the host and virtualization engine to which
<code>@conn</code> is connected. One can test it using <code>virsh</code>
command line tool command '<code>capabilities</code>', it dumps the XML
associated to the current connection. For example in the case of a 64 bits
machine with hardware virtualization capabilities enabled in the chip and
BIOS you will see</p>
<pre><capabilities>
<span style="color: #E50000; background-color: #FFFFFF"><host>
<cpu>
<arch>x86_64</arch>
<features>
<vmx/>
</features>
</cpu>
</host></span>
<!-- xen-3.0-x86_64 -->
<span style="color: #0000E5; background-color: #FFFFFF"><guest>
<os_type>xen</os_type>
<arch name="x86_64">
<wordsize>64</wordsize>
<domain type="xen"></domain>
<emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
</arch>
<features>
</features>
</guest></span>
<!-- hvm-3.0-x86_32 -->
<span style="color: #00B200; background-color: #FFFFFF"><guest>
<os_type>hvm</os_type>
<arch name="i686">
<wordsize>32</wordsize>
<domain type="xen"></domain>
<emulator>/usr/lib/xen/bin/qemu-dm</emulator>
<machine>pc</machine>
<machine>isapc</machine>
<loader>/usr/lib/xen/boot/hvmloader</loader>
</arch>
<features>
</features>
</guest></span>
...
</capabilities></pre>
<p>The fist block (in red) indicates the host hardware capbilities, currently
it is limited to the CPU properties but other information may be available,
it shows the CPU architecture, and the features of the chip (the feature
block is similar to what you will find in a Xen fully virtualized domain
description).</p>
<p>The second block (in blue) indicates the paravirtualization support of the
Xen support, you will see the os_type of xen to indicate a paravirtual
kernel, then architecture informations and potential features.</p>
<p>The third block (in green) gives similar informations but when running a
32 bit OS fully virtualized with Xen using the hvm support.</p>
<p>This section is likely to be updated and augmented in the future, see <a
href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the
discussion</a> which led to the capabilities format in the mailing-list
archives.</p>
<h2><a name="Python" id="Python">Binding for Python</a></h2>
<p>Libvirt comes with direct support for the Python language (just make sure
you installed the libvirt-python package if not compiling from sources). Also
note that Daniel Berrange provides <a
href="http://search.cpan.org/~danberr/Sys-Virt-0.1.0/">bindings for Perl</a>
too.</p>
<p>The Python binding should be complete and are mostly automatically
generated from the formal description of the API in xml. The bindings are
articulated around 2 classes <code>virConnect</code> and virDomain mapping to
the C types. Functions in the C API taking either type as argument then
becomes methods for the classes, their name is just stripped from the
virConnect or virDomain(Get) prefix and the first letter gets converted to
lower case, for example the C functions:</p>
<p><code>int <a
href="html/libvirt-libvirt.html#virConnectNumOfDomains">virConnectNumOfDomains</a>
(virConnectPtr conn);</code></p>
<p><code>int <a
href="html/libvirt-libvirt.html#virDomainSetMaxMemory">virDomainSetMaxMemory</a>
(virDomainPtr domain, unsigned long memory);</code></p>
<p>become</p>
<p><code>virConn::numOfDomains(self)</code></p>
<p><code>virDomain::setMaxMemory(self, memory)</code></p>
<p>This process is fully automated, you can get a summary of the conversion
in the file libvirtclass.txt present in the python dir or in the docs.There
is a couple of function who don't map directly to their C counterparts due to
specificities in their argument conversions:</p>
<ul>
<li><code><a
href="html/libvirt-libvirt.html#virConnectListDomains">virConnectListDomains</a></code>
is replaced by <code>virDomain::listDomainsID(self)</code> which returns
a list of the integer ID for the currently running domains</li>
<li><code><a
href="html/libvirt-libvirt.html#virDomainGetInfo">virDomainGetInfo</a></code>
is replaced by <code>virDomain::info()</code> which returns a list of
<ol>
<li>state: one of the state values (virDomainState)</li>
<li>maxMemory: the maximum memory used by the domain</li>
<li>memory: the current amount of memory used by the domain</li>
<li>nbVirtCPU: the number of virtual CPU</li>
<li>cpuTime: the time used by the domain in nanoseconds</li>
</ol>
</li>
</ul>
<p>So let's look at a simple example inspired from the <code>basic.py</code>
test found in <code>python/tests/</code> in the source tree:</p>
<pre>import <span style="color: #0071FF; background-color: #FFFFFF">libvirt</span>
import sys
conn = <span style="color: #0071FF; background-color: #FFFFFF">libvirt</span>.openReadOnly(None)
if conn == None:
print 'Failed to open connection to the hypervisor'
sys.exit(1)
try:
dom0 = conn.<span style="color: #007F00; background-color: #FFFFFF">lookupByName</span>("Domain-0")
except:
print 'Failed to find the main domain'
sys.exit(1)
print "Domain 0: id %d running %s" % (dom0.<span style="color: #FF0080; background-color: #FFFFFF">ID</span>(), dom0.<span style="color: #FF0080; background-color: #FFFFFF">OSType</span>())
print dom0.<span style="color: #FF0080; background-color: #FFFFFF">info</span>()</pre>
<p>There is not much to comment about it, it really is a straight mapping
from the C API, the only points to notice are:</p>
<ul>
<li>the import of the module called <code><span
style="color: #0071FF; background-color: #FFFFFF">libvirt</span></code></li>
<li>getting a connection to the hypervisor, in that case using the
openReadOnly function allows the code to execute as a normal user.</li>
<li>getting an object representing the Domain 0 using <span
style="color: #007F00; background-color: #FFFFFF">lookupByName</span></li>
<li>if the domain is not found a libvirtError exception will be raised</li>
<li>extracting and printing some informations about the domain using
various <span
style="color: #E50073; background-color: #FFFFFF">methods</span>
associated to the virDomain class.</li>
</ul>
<h2><a name="Errors" id="Errors">Handling of errors</a></h2>
<p>The main goals of libvirt when it comes to error handling are:</p>
<ul>
<li>provide as much detail as possible</li>
<li>provide the informations as soon as possible</li>
<li>dont force the library user into one style of error handling</li>
</ul>
<p>As result the library provide both synchronous, callback based and
asynchronous error reporting. When an error happens in the library code the
error is logged, allowing to retrieve it later and if the user registered an
error callback it will be called synchronously. Once the call to libvirt ends
the error can be detected by the return value and the full information for
the last logged error can be retrieved.</p>
<p>To avoid as much as prossible troubles with a global variable in a
multithreaded environment, libvirt will associate when possible the errors to
the current connection they are related to, that way the error is stored in a
dynamic structure which can be made thread specific. Error callback can be
set specifically to a connection with</p>
<p>So error handling in the code is the following:</p>
<ol>
<li>if the error can be associated to a connection for example when failing
to look up a domain
<ol>
<li>if there is a callback associated to the connection set with <a
href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
call it with the error informations</li>
<li>otherwise if there is a global callback set with <a
href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
call it with the error information</li>
<li>otherwise call <a
href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
which is the default error function of the library issuing the error
on stderr</li>
<li>save the error in the connection for later retrieval with <a
href="html/libvirt-virterror.html#virConnGetLastError">virConnGetLastError</a></li>
</ol>
</li>
<li>otherwise like when failing to create an hypervisor connection:
<ol>
<li>if there is a global callback set with <a
href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a>,
call it with the error information</li>
<li>otherwise call <a
href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>
which is the default error function of the library issuing the error
on stderr</li>
<li>save the error in the connection for later retrieval with <a
href="html/libvirt-virterror.html#virGetLastError">virGetLastError</a></li>
</ol>
</li>
</ol>
<p>In all cases the error informations are provided as a <a
href="html/libvirt-virterror.html#virErrorPtr">virErrorPtr</a> pointer to
read-only structure <a
href="html/libvirt-virterror.html#virError">virError</a> containing the
following fields:</p>
<ul>
<li>code: an error number from the <a
href="html/libvirt-virterror.html#virErrorNumber">virErrorNumber</a>
enum</li>
<li>domain: an enum indicating which part of libvirt raised the error see
<a
href="html/libvirt-virterror.html#virErrorDomain">virErrorDomain</a></li>
<li>level: the error level, usually VIR_ERR_ERROR, though there is room for
warnings like VIR_ERR_WARNING</li>
<li>message: the full human-readable formatted string of the error</li>
<li>conn: if available a pointer to the <a
href="html/libvirt-libvirt.html#virConnectPtr">virConnectPtr</a>
connection to the hypervisor where this happened</li>
<li>dom: if available a pointer to the <a
href="html/libvirt-libvirt.html#virDomainPtr">virDomainPtr</a> domain
targetted in the operation</li>
</ul>
<p>and then extra raw informations about the error which may be initialized
to 0 or NULL if unused</p>
<ul>
<li>str1, str2, str3: string informations, usually str1 is the error
message format</li>
<li>int1, int2: integer informations</li>
</ul>
<p>So usually, setting up specific error handling with libvirt consist of
registering an handler with with <a
href="html/libvirt-virterror.html#virSetErrorFunc">virSetErrorFunc</a> or
with <a
href="html/libvirt-virterror.html#virConnSetErrorFunc">virConnSetErrorFunc</a>,
chech the value of the code value, take appropriate action, if needed let
libvirt print the error on stderr by calling <a
href="html/libvirt-virterror.html#virDefaultErrorFunc">virDefaultErrorFunc</a>.
For asynchronous error handing, set such a function doing nothing to avoid
the error being reported on stderr, and call virConnGetLastError or
virGetLastError when an API call returned an error value. It can be a good
idea to use <a
href="html/libvirt-virterror.html#virResetLastError">virResetError</a> or <a
href="html/libvirt-virterror.html#virConnResetLastError">virConnResetLastError</a>
once an error has been processed fully.</p>
<p>At the python level, there only a global reporting callback function at
this point, see the error.py example about it:</p>
<pre>def handler(ctxt, err):
global errno
#print "handler(%s, %s)" % (ctxt, err)
errno = err
libvirt.registerErrorHandler(handler, 'context') </pre>
<p>the second argument to the registerErrorHandler function is passed as the
fist argument of the callback like in the C version. The error is a tuple
containing the same field as a virError in C, but cast to Python.</p>
<h2><a name="FAQ" id="FAQ">FAQ</a></h2>
<p>Table of Contents:</p>
<ul>
<li><a href="FAQ.html#License">License(s)</a></li>
<li><a href="FAQ.html#Installati">Installation</a></li>
<li><a href="FAQ.html#Compilatio">Compilation</a></li>
<li><a href="FAQ.html#Developer">Developer corner</a></li>
</ul>
<h3><a name="License">License</a>(s)</h3>
<ol>
<li><em>Licensing Terms for libvirt</em>
<p>libvirt is released under the <a
href="http://www.opensource.org/licenses/lgpl-license.html">GNU Lesser
General Public License</a>, see the file COPYING.LIB in the distribution
for the precise wording. The only library that libvirt depends upon is
the Xen store access library which is also licenced under the LGPL.</p>
</li>
<li><em>Can I embed libvirt in a proprietary application ?</em>
<p>Yes. The LGPL allows you to embed libvirt into a proprietary
application. It would be graceful to send-back bug fixes and improvements
as patches for possible incorporation in the main development tree. It
will decrease your maintainance costs anyway if you do so.</p>
</li>
</ol>
<h3><a name="Installati">Installation</a></h3>
<ol>
<li><em>Where can I get libvirt</em> ?
<p>The original distribution comes from <a
href="ftp://libvirt.org/libvirt/">ftp://libvirt.org/libvirt/</a>.</p>
</li>
<li><em>I can't install the libvirt/libvirt-devel RPM packages due to
failed dependencies</em>
<p>The most generic solution is to re-fetch the latest src.rpm , and
rebuild it locally with</p>
<p><code>rpm --rebuild libvirt-xxx.src.rpm</code>.</p>
<p>If everything goes well it will generate two binary rpm packages (one
providing the shared libs and virsh, and the other one, the -devel
package, providing includes, static libraries and scripts needed to build
applications with libvirt that you can install locally.</p>
<p>One can also rebuild the RPMs from a tarball:</p>
<p><code>rpmbuild -ta libdir-xxx.tar.gz</code></p>
<p>Or from a configured tree with:</p>
<p><code>make rpm</code></p>
</li>
<li><em>Failure to use the API for non-root users</em>
<p>Large parts of the API may only be accessible with root priviledges,
however the read only access to the xenstore data doesnot have to be
forbidden to user, at least for monitoring purposes. If "virsh dominfo"
fails to run as an user, change the mode of the xenstore read-only socket
with:</p>
<p><code>chmod 666 /var/run/xenstored/socket_ro</code></p>
<p>and also make sure that the Xen Daemon is running correctly with local
HTTP server enabled, this is defined in
<code>/etc/xen/xend-config.sxp</code> which need the following line to be
enabled:</p>
<p><code>(xend-http-server yes)</code></p>
<p>If needed restart the xend daemon after making the change with the
following command run as root:</p>
<p><code>service xend restart</code></p>
</li>
</ol>
<h3><a name="Compilatio">Compilation</a></h3>
<ol>
<li><em>What is the process to compile libvirt ?</em>
<p>As most UNIX libraries libvirt follows the "standard":</p>
<p><code>gunzip -c libvirt-xxx.tar.gz | tar xvf -</code></p>
<p><code>cd libvirt-xxxx</code></p>
<p><code>./configure --help</code></p>
<p>to see the options, then the compilation/installation proper</p>
<p><code>./configure [possible options]</code></p>
<p><code>make</code></p>
<p><code>make install</code></p>
<p>At that point you may have to rerun ldconfig or a similar utility to
update your list of installed shared libs.</p>
</li>
<li><em>What other libraries are needed to compile/install libvirt ?</em>
<p>Libvirt requires libxenstore, which is usually provided by the xen
packages as well as the public headers to compile against libxenstore.</p>
</li>
<li><em>I use the CVS version and there is no configure script</em>
<p>The configure script (and other Makefiles) are generated. Use the
autogen.sh script to regenerate the configure script and Makefiles,
like:</p>
<p><code>./autogen.sh --prefix=/usr --disable-shared</code></p>
</li>
</ol>
<h3><a name="Developer">Developer</a> corner</h3>
<ol>
<li><em>Troubles compiling or linking programs using libvirt</em>
<p>To simplify the process of reusing the library, libvirt comes with
pkgconfig support, which can be used directly from autoconf support or
via the pkg-config command line tool, like:</p>
<p><code>pkg-config libvirt --libs</code></p>
</li>
</ol>
<h2><a name="Reporting">Reporting bugs and getting help</a></h2>
<p>There is a mailing-list <a
href="mailto:libvir-list@redhat.com">libvir-list@redhat.com</a> for libvirt,
with an <a href="https://www.redhat.com/archives/libvir-list/">on-line
archive</a>. Please subscribe to this list before posting by visiting the <a
href="https://www.redhat.com/mailman/listinfo/libvir-list">associated Web</a>
page and follow the instructions. Patches with explanations and provided as
attachments are really appreciated and will be discussed on the mailing list.
If possible generate the patches by using cvs diff -u in a CVS checkout.</p>
<p>We use Red Hat Bugzilla to track bugs to libvirt. If you want to report a
bug, please check <a href="http://bugzilla.redhat.com/bugzilla/buglist.cgi?component=libvirt&component=libvirt-devel&component=libvirt-python&bug_status=ASSIGNED&bug_status=INVESTIGATE&bug_status=NEW&bug_status=REOPENED&bug_status=VERIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&Search=Search">the existing open bugs</a>, then if yours isn't a duplicate of
an existing bug, <a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&component=libvirt">log a new bug</a>. It may be good
to post to the <a href="mailto:libvir-list@redhat.com">mailing-list</a>
too if the issue looks serious, thanks !</p>
<h2><a name="Remote">Remote support</a></h2>
<p>
<b>NB. Remote support is available only as a <a
href="https://www.redhat.com/archives/libvir-list/">series of
patches posted on libvir-list</a> against <a
href="http://libvirt.org/downloads.html">libvirt CVS</a>. It is only
for experimental use at the moment.</b>
— Richard Jones, 2007-04-18.
</p>
<p>
Libvirt allows you to access hypervisors running on remote
machines through authenticated and encrypted connections.
</p>
<h3><a name="Remote_basic_usage">Basic usage</a></h3>
<p>
On the remote machine, <code>libvirtd</code> should be running.
See <a href="#Remote_libvirtd_configuration">the section
on configuring libvirtd</a> for more information.
</p>
<p>
To tell libvirt that you want to access a remote resource,
you should supply a hostname in the normal URI that is passed
to <code>virConnectOpen</code> (or <code>virsh -c ...</code>).
For example, if you normally use <code>qemu:///system</code>
to access the system-wide QEMU daemon, then to access
the system-wide QEMU daemon on a remote machine called
<code>oirase</code> you would use <code>qemu://oirase/system</code>.
</p>
<p>
The <a href="#Remote_URI_reference">section on remote URIs</a>
describes in more detail these remote URIs.
</p>
<p>
From an API point of view, apart from the change in URI, the
API should behave the same. For example, ordinary calls
are routed over the remote connection transparently, and
values or errors from the remote side are returned to you
as if they happened locally. Some differences you may notice:
</p>
<ul>
<li> Additional errors can be generated, specifically ones
relating to failures in the remote transport itself. </li>
<li> Remote calls are handled synchronously, so they will be
much slower than, say, direct hypervisor calls. </li>
</ul>
<h3><a name="Remote_transports">Transports</a></h3>
<p>
Remote libvirt supports a range of transports:
</p>
<dl>
<dt> tls </dt>
<dd> <a href="http://en.wikipedia.org/wiki/Transport_Layer_Security"
title="Transport Layer Security">TLS</a>
1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket, usually
listening on a public port number. To use this you will need to
<a href="#Remote_certificates"
title="Generating TLS certificates">generate client and
server certificates</a>.
The standard port is 16514.
</dd>
<dt> unix </dt>
<dd> Unix domain socket. Since this is only accessible on the
local machine, it is not encrypted, and uses Unix permissions or
SELinux for authentication.
The standard socket names are
<code>/var/run/libvirt/libvirt-sock</code> and
<code>/var/run/libvirt/libvirt-sock-ro</code> (the latter
for read-only connections).
</dd>
<dt> ssh </dt>
<dd> Transported over an ordinary
<a href="http://www.openssh.com/" title="OpenSSH homepage">ssh
(secure shell)</a> connection.
Requires <a href="http://netcat.sourceforge.net/">Netcat (nc)</a>
installed on the remote machine, and the remote libvirtd should
be listening on the unix transport. You should use some sort of
ssh key management (eg.
<a href="http://mah.everybody.org/docs/ssh"
title="Using ssh-agent with ssh">ssh-agent</a>)
otherwise programs which use
this transport will stop to ask for a password. </dd>
<dt> ext </dt>
<dd> Any external program which can make a connection to the
remote machine by means outside the scope of libvirt. </dd>
<dt> tcp </dt>
<dd> Unencrypted TCP/IP socket. Not recommended for production
use, this is normally disabled, but an administrator can enable
it for testing or use over a trusted network.
The standard port is 16509.
</dd>
</dl>
<p>
The default transport, if no other is specified, is <code>tls</code>.
</p>
<h3><a name="Remote_URI_reference">Remote URIs</a></h3>
<p>
Remote URIs have the general form ("[...]" meaning an optional part):
</p>
<p>
<code>driver</code>[<code>+transport</code>]<code>://</code>[<code>username@</code>][<code>hostname</code>][<code>:port</code>]<code>/</code>[<code>path</code>][<code>?extraparameters</code>]
</p>
<p>
Either the transport or the hostname must be given in order
to distinguish this from a local URI.
</p>
<p>
Some examples:
</p>
<ul>
<li> <code>xen+ssh://rjones@towada/</code> <br/> — Connect to a
remote Xen hypervisor on host <code>towada</code> using ssh transport and ssh
username <code>rjones</code>.
</li>
<li> <code>xen://towada/</code> <br/> — Connect to a
remote Xen hypervisor on host <code>towada</code> using TLS.
</li>
<li> <code>xen://towada/?no_verify=1</code> <br/> — Connect to a
remote Xen hypervisor on host <code>towada</code> using TLS. Do not verify
the server's certificate.
</li>
<li> <code>qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock</code> <br/> —
Connect to the local qemu instances over a non-standard
Unix socket (the full path to the Unix socket is
supplied explicitly in this case).
</li>
<li> <code>test+tcp://localhost:5000/default</code> <br/> —
Connect to a libvirtd daemon offering unencrypted TCP/IP connections
on localhost port 5000 and use the test driver with default
settings.
</li>
</ul>
<h4><a name="Remote_URI_parameters">Extra parameters</a></h4>
<p>
Extra parameters can be added to remote URIs as part
of the query string (the part following <q><code>?</code></q>).
Remote URIs understand the extra parameters shown below.
Any others are passed unmodified through to the back end.
Note that parameter values must be
<a href="http://xmlsoft.org/html/libxml-uri.html#xmlURIEscapeStr">URI-escaped</a>.
</p>
<table class="top_table">
<tr>
<th> Name </th>
<th> Transports </th>
<th> Meaning </th>
</tr>
<tr>
<td> <code>name</code> </td>
<td> <i>any transport</i> </td>
<td>
The name passed to the remote virConnectOpen function. The
name is normally formed by removing transport, hostname, port
number, username and extra parameters from the remote URI, but in certain
very complex cases it may be better to supply the name explicitly.
</td>
</tr>
<tr> <td colspan="2"></td>
<td> Example: <code>name=qemu:///system</code> </td>
</tr>
<tr>
<td> <code>command</code> </td>
<td> ssh, ext </td>
<td>
The external command. For ext transport this is required.
For ssh the default is <code>ssh</code>.
The PATH is searched for the command.
</td>
</tr>
<tr> <td colspan="2"></td>
<td> Example: <code>command=/opt/openssh/bin/ssh</code> </td>
</tr>
<tr>
<td> <code>socket</code> </td>
<td> unix, ssh </td>
<td>
The path to the Unix domain socket, which overrides the
compiled-in default. For ssh transport, this is passed to
the remote netcat command (see next).
</td>
</tr>
<tr> <td colspan="2"></td>
<td> Example: <code>socket=/opt/libvirt/run/libvirt/libvirt-sock</code> </td>
</tr>
<tr>
<td> <code>netcat</code> </td>
<td> ssh </td>
<td>
The name of the netcat command on the remote machine.
The default is <code>nc</code>. For ssh transport, libvirt
constructs an ssh command which looks like:
<pre>
<i>command</i> -p <i>port</i> [-l <i>username</i>] <i>hostname</i> <i>netcat</i> -U <i>socket</i>
</pre>
where <i>port</i>, <i>username</i>, <i>hostname</i> can be
specified as part of the remote URI, and <i>command</i>, <i>netcat</i>
and <i>socket</i> come from extra parameters (or
sensible defaults).
</td>
</tr>
<tr> <td colspan="2"></td>
<td> Example: <code>netcat=/opt/netcat/bin/nc</code> </td>
</tr>
<tr>
<td> <code>no_verify</code> </td>
<td> tls </td>
<td>
If set to a non-zero value, this disables client checks of the
server's certificate. Note that to disable server checks of
the client's certificate or IP address you must
<a href="#Remote_libvirtd_configuration">change the libvirtd
configuration</a>.
</td>
</tr>
<tr> <td colspan="2"></td>
<td> Example: <code>no_verify=1</code> </td>
</tr>
</table>
<h3><a name="Remote_certificates">Generating TLS certificates</a></h3>
<h4>Public Key Infrastructure set up</h4>
<p>
If you are unsure how to create TLS certificates, skip to the
next section.
</p>
<table class="top_table">
<tr>
<th> Location </th>
<th> Machine </th>
<th> Description </th>
<th> Required fields </th>
</tr>
<tr>
<td> <code>/etc/pki/CA/cacert.pem</code> </td>
<td> Installed on all clients and servers </td>
<td> CA's certificate (<a href="#Remote_TLS_CA">more info</a>)</td>
<td> n/a </td>
</tr>
<tr>
<td> <code>/etc/pki/libvirt/ private/serverkey.pem</code> </td>
<td> Installed on the server </td>
<td> Server's private key (<a href="#Remote_TLS_server_certificates">more info</a>)</td>
<td> n/a </td>
</tr>
<tr>
<td> <code>/etc/pki/libvirt/ servercert.pem</code> </td>
<td> Installed on the server </td>
<td> Server's certificate signed by the CA.
(<a href="#Remote_TLS_server_certificates">more info</a>) </td>
<td> CommonName (CN) must be the hostname of the server as it
is seen by clients. </td>
</tr>
<tr>
<td> <code>/etc/pki/libvirt/ private/clientkey.pem</code> </td>
<td> Installed on the client </td>
<td> Client's private key. (<a href="#Remote_TLS_client_certificates">more info</a>) </td>
<td> n/a </td>
</tr>
<tr>
<td> <code>/etc/pki/libvirt/ clientcert.pem</code> </td>
<td> Installed on the client </td>
<td> Client's certificate signed by the CA
(<a href="#Remote_TLS_client_certificates">more info</a>) </td>
<td> CommonName (CN) must be the client IP address as seen
by the server. Take particular care with IPv4 and IPv6
addresses, and note that on some operating systems IPv4 addresses
may need to be encapsulated as <code>::ffff:<i>a.b.c.d</i></code>
</td>
</tr>
</table>
<h4><a name="Remote_TLS_background">Background to TLS certificates</a></h4>
<p>
Libvirt supports TLS certificates for verifying the identity
of the server and clients. There are two distinct checks involved:
</p>
<ul>
<li> The client should know that it is connecting to the right
server. Checking done by client by matching the certificate that
the server sends to the server's hostname. May be disabled by adding
<code>?no_verify=1</code> to the
<a href="#Remote_URI_parameters">remote URI</a>.
</li>
<li> The server should know that only permitted clients are
connecting. This can be done based on client's IP address, or on
client's IP address and client's certificate. Checking done by the
server. May be enabled and disabled in the <a
href="#Remote_libvirtd_configuration">libvirtd.conf file</a>.
</li>
</ul>
<p>
For full certificate checking you will need to have certificates
issued by a recognised <a
href="http://en.wikipedia.org/wiki/Certificate_authority">Certificate
Authority (CA)</a> for your server(s) and all clients. To avoid the
expense of getting certificates from a commercial CA, you can set up
your own CA and tell your server(s) and clients to trust certificates
issues by your own CA. Follow the instructions in the next section.
</p>
<p>
Be aware that the <a href="#Remote_libvirtd_configuration">default
configuration for libvirtd</a> allows any client to connect provided
they have a valid certificate issued by the CA for their own IP
address. You may want to change this to make it less (or more)
permissive, depending on your needs.
</p>
<h4><a name="Remote_TLS_CA">Setting up a Certificate Authority (CA)</a></h4>
<p>
You will need the <a
href="http://www.openssl.org/docs/apps/CA.pl.html">OpenSSL CA.pl Perl
script documented here</a>. In Fedora, it is in the
<code>openssl-perl</code> package. In Debian and derivatives, it is
in the base <code>openssl</code> package.
</p>
<p>Notes:</p>
<ul>
<li>
You may find it
better to start with the basic <code>CA.pl</code> script from OpenSSL
itself, as Linux distributors seem to supply a hacked/broken one.
</li>
<li>
A second confounding factor may be the default
<code>openssl.cnf</code> file supplied with your
Linux distribution. You can switch to a custom
file by doing:
<pre>
export SSLEAY_CONFIG="-config your_config_file"
</pre>
</li>
</ul>
<p>
These instructions assume that <code>CA.pl</code> is in an empty
directory (because you will probably need to edit this script).
Please read the <a
href="http://www.openssl.org/docs/apps/CA.pl.html">CA.pl manpage</a>
carefully before starting.
</p>
<p>
Copy CA.pl into an empty directory and edit it. Near the top you will
find various variables:
</p>
<p>
<code>$DAYS</code> defaults to <code>"-days 365"</code>. You may wish
to increase this, otherwise your CA and certificates will expire after
a year, suddenly leaving your systems unmanageable.
</p>
<p>
<code>$CATOP</code> may be set to <code>"./demoCA"</code> or some
other directory. If you want you can change the name to a suitable
directory name for your organisation.
</p>
<p>
Now run:
</p>
<pre>
<b>./CA.pl -newca</b>
CA certificate filename (or enter to create)
<b>[press enter key]</b>
Making CA certificate ...
Generating a 1024 bit RSA private key
...++++++
.......................++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase: <b>[type a passphrase]</b>
Verifying - Enter PEM pass phrase: <b>[type a passphrase]</b>
</pre>
<p>
It will ask some further questions about your organisation and then
create a CA directory structure (usually called <code>demoCA</code>
unless you changed it above). Some highlights of this directory:
</p>
<pre>
demoCA/newcerts Certificates issued by the CA
demoCA/crl Certificates revoked by the CA
demoCA/cacert.pem The CA's own certificate (this is public)
demoCA/private/cakey.pem The CA's private key (keep this secret)
</pre>
<p>
The important file is <code>cacert.pem</code> which is your new CA's
X.509 certificate. This file has to be installed on clients and
server(s) to let them know that they can trust certificates issued by
your CA.
</p>
<p>
The normal installation directory for <code>cacert.pem</code>
is <code>/etc/pki/CA/cacert.pem</code> on all clients and servers.
</p>
<p>
To see the contents of this file, do:
</p>
<pre>
<b>openssl x509 -in demoCA/cacert.pem -text</b>
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
dd:b4:0f:d0:58:0e:08:fa
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
Validity
Not Before: May 10 10:26:47 2007 GMT
Not After : May 7 10:26:47 2017 GMT
Subject: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
<i>[etc]</i>
</pre>
<p>
This is all that is required to set up your CA. Keep this directory
structure and the passphrase safe as you will require them later when
issuing certificates.
</p>
<h4><a name="Remote_TLS_server_certificates">Issuing server certificates</a></h4>
<p>
For each server (libvirtd) you need to issue a certificate
with the X.509 CommonName (CN) field set to the hostname
of the server. The CN must match the hostname which
clients will be using to connect to the server.
</p>
<p>
In the example below, clients will be connecting to the
server using a <a href="#Remote_URI_reference">URI</a> of
<code>xen://oirase/</code>, so the CN must be "<code>oirase</code>".
</p>
<p>
First move to the directory above the CA directory (from the example
in the last section, <code>demoCA</code> would be a subdirectory).
</p>
<p>
Make a private key and a request for a new certificate:
</p>
<pre>
<b>./CA.pl -newreq</b>
Generating a 1024 bit RSA private key
...++++++
....................++++++
writing new private key to 'newreq.pem'
Enter PEM pass phrase: <b>[enter a passphrase]</b>
Verifying - Enter PEM pass phrase: <b>[enter a passphrase]</b>
</pre>
<p>
You will be asked additional details about the certificate.
The single important field is "Common Name" which as explained
above <b>must</b> contain the server's hostname as clients
see it.
</p>
<p>
The operation creates a request file called <code>newreq.pem</code>
which has both the private key and the unsigned certificate.
In the situation of a "real" CA, you would send the certificate
part off to be signed (along with lots of $$$). Instead we are
going to act as CA and sign it ourselves:
</p>
<pre>
<b>./CA.pl -signreq</b>
Enter pass phrase for demoCA/private/cakey.pem: <b>[enter CA passphrase]</b>
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
dd:b4:0f:d0:58:0e:08:fb
Validity
Not Before: May 10 11:10:40 2007 GMT
Not After : May 9 11:10:40 2008 GMT
Subject:
countryName = GB
stateOrProvinceName = London
localityName = London
organizationName = Red Hat UK Ltd
organizationalUnitName = Emerging Technologies
commonName = oirase
emailAddress = rjones@redhat.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
DE:08:0D:12:73:76:06:97:EC:57:EF:8D:1B:48:ED:53:9A:1A:FE:7F
X509v3 Authority Key Identifier:
keyid:F6:84:4C:1B:2B:59:10:89:3F:0B:AB:05:7F:57:85:A6:33:C7:7A:60
Certificate is to be certified until May 9 11:10:40 2008 GMT (365 days)
Sign the certificate? [y/n]:<b>y</b>
1 out of 1 certificate requests certified, commit? [y/n]<b>y</b>
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem
</pre>
<p>
This step generates a server certificate signed by the CA
for the server <code>oirase</code> (NB. the commonName field
above). We can examine this certificate and its signature:
</p>
<pre>
<b>openssl x509 -in newcert.pem -text</b>
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
dd:b4:0f:d0:58:0e:08:fb
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=Red Hat/emailAddress=rjones@redhat.com
Validity
Not Before: May 10 11:10:40 2007 GMT
Not After : May 9 11:10:40 2008 GMT
Subject: C=GB, ST=London, L=London, O=Red Hat UK Ltd, OU=Emerging Technologies, CN=oirase/emailAddress=rjones@redhat.com
</pre>
<p>
Note the "Issuer" CN is "Red Hat" (the CA) and the "Subject" CN is
"oirase" (the server).
</p>
<p>
At this point we have <code>newreq.pem</code> which contains the
private key and unsigned certificate and <code>newcert.pem</code>
which contains the signed certificate. For the server we need just
the private key and signed certificate. For the clients we need just
the signed certificate. So there is one final step which is to
extract the private key from <code>newreq.pem</code>:
</p>
<pre>
<b>openssl rsa -in newreq.pem -out serverkey.pem</b>
Enter pass phrase for newreq.pem:
writing RSA key
<b>mv newcert.pem servercert.pem</b>
</pre>
<p>
Finally we have two files to install:
</p>
<ul>
<li>
<code>serverkey.pem</code> is
the server's private key which should be copied to the
server <i>only</i> as
<code>/etc/pki/libvirt/private/serverkey.pem</code>.
</li>
<li>
<code>servercert.pem</code> is the server's certificate
which can be installed on the server as
<code>/etc/pki/libvirt/servercert.pem</code>.
</li>
</ul>
<h4><a name="Remote_TLS_client_certificates">Issuing client certificates</a></h4>
<p>
For each client (ie. any program linked with libvirt, such as
<a href="http://virt-manager.et.redhat.com/">virt-manager</a>)
you need to issue a certificate with the X.509 CommonName (CN)
field set to the IP address of the client as seen from the
server.
</p>
<p>
Normally then the CN will just be a string such as
"<code>192.168.2.5</code>". On machines with IPv6 enabled,
IPv4 addresses may appear embedded, for example:
"<code>::ffff:<i>a.b.c.d</i></code>".
</p>
<p>
The process is the same as for
<a href="#Remote_TLS_server_certificates">setting up the
server certificate</a> so here we just briefly cover the
steps.
</p>
<ol>
<li>
Make a private key and a request for a new certificate:
<pre>
./CA.pl -newreq
</pre>
You <b>must</b> set the CommonName (CN) field to be the
client's IP address as seen by the server. See notes above.
</li>
<li>
Act as CA and sign the certificate:
<pre>
./CA.pl -signreq
</pre>
</li>
<li>
Extract the private key for the client and rename the
signed certificate:
<pre>
openssl rsa -in newreq.pem -out clientkey.pem
mv newcert.pem clientcert.pem
</pre>
</li>
<li>
Install the certificates on the client machine:
<pre>
cp clientkey.pem /etc/pki/libvirt/private/clientkey.pem
cp clientcert.pem /etc/pki/libvirt/clientcert.pem
</pre>
</li>
</ol>
<h4><a name="Remote_TLS_troubleshooting">Troubleshooting TLS certificate problems</a></h4>
<dl>
<dt> failed to verify client's certificate </dt>
<dd>
<p>
On the server side, run the libvirtd server with
the '--remote' and '--verbose' options while the
client is connecting. The verbose messages will tell
you the client's actual IP address versus what is
in the client's certificate. Also you will find out
common problems such as expired certificates.
</p>
</dd>
</dl>
<h3><a name="Remote_libvirtd_configuration">libvirtd configuration</a></h3>
<p>
Libvirtd (the remote daemon) is configured from a file called
<code>/etc/libvirt/libvirtd.conf</code>, or specified on
the command line using <code>-f filename</code> or
<code>--config filename</code>.
</p>
<p>
This file should contain lines of the form below.
Blank lines and comments beginning with <code>#</code> are ignored.
</p>
<table class="top_table">
<tr>
<th> Line </th>
<th> Default </th>
<th> Meaning </th>
</tr>
<tr>
<td> listen_tls <i>[0|1]</i> </td>
<td> 1 (on) </td>
<td>
Listen for secure TLS connections on the public TCP/IP port.
</td>
</tr>
<tr>
<td> listen_tcp <i>[0|1]</i> </td>
<td> 0 (off) </td>
<td>
Listen for unencrypted TCP connections on the public TCP/IP port.
</td>
</tr>
<tr>
<td> tls_port <i>"service"</i> </td>
<td> "16514" </td>
<td>
The port number or service name to listen on for secure TLS connections.
</td>
</tr>
<tr>
<td> tcp_port <i>"service"</i> </td>
<td> "16509" </td>
<td>
The port number or service name to listen on for unencrypted TCP connections.
</td>
</tr>
<tr>
<td> tls_no_verify_certificate <i>[0|1]</i> </td>
<td> 0 (certificates are verified) </td>
<td>
If set to 1 then if a client certificate check fails, it is not an error.
</td>
</tr>
<tr>
<td> tls_no_verify_address <i>[0|1]</i> </td>
<td> 0 (addresses are verified) </td>
<td>
If set to 1 then if a client IP address check fails, it is not an error.
</td>
</tr>
<tr>
<td> key_file <i>"filename"</i> </td>
<td> "/etc/pki/libvirt/ private/serverkey.pem" </td>
<td>
Change the path used to find the server's private key.
If you set this to an empty string, then no private key is loaded.
</td>
</tr>
<tr>
<td> cert_file <i>"filename"</i> </td>
<td> "/etc/pki/libvirt/ servercert.pem" </td>
<td>
Change the path used to find the server's certificate.
If you set this to an empty string, then no certificate is loaded.
</td>
</tr>
<tr>
<td> ca_file <i>"filename"</i> </td>
<td> "/etc/pki/CA/cacert.pem" </td>
<td>
Change the path used to find the trusted CA certificate.
If you set this to an empty string, then no trusted CA certificate is loaded.
</td>
</tr>
<tr>
<td> crl_file <i>"filename"</i> </td>
<td> (no CRL file is used) </td>
<td>
Change the path used to find the CA certificate revocation list (CRL) file.
If you set this to an empty string, then no CRL is loaded.
</td>
</tr>
<tr>
<td> tls_allowed_clients ["ip1", "ip2", "ip3"] </td>
<td> (none - any client can connect) </td>
<td>
<p>
Enable an access control list of the IP addresses of clients
who can connect to the TLS or TCP ports on this server.
</p>
<p>
The default is that any client can connect, but their
certificate must match their IP address and must be
issued by the trusted CA. If you use this option, then
in addition only the IP addresses listed may connect.
</p>
<p>
This list may contain wildcards such as <code>192.168.*</code>
See the POSIX <code>fnmatch</code> function for the format
of the wildcards.
</p>
<p>
Note that if this is an empty list, <i>no client can connect</i>.
</p>
</td>
</tr>
</table>
<h3><a name="Remote_IPv6">IPv6 support</a></h3>
<p>
IPv6 has received some limited testing and should work. Problems with
libvirt and IPv6 should be reported as <a href="bugs.html">bugs</a>.
</p>
<h3><a name="Remote_limitations">Limitations</a></h3>
<ul>
<li> Remote storage: To be fully useful, particularly for
creating new domains, it should be possible to enumerate
and provision storage on the remote machine. This is currently
in the design phase. </li>
<li> Migration: We expect libvirt will support migration,
and obviously remote support is what makes migration worthwhile.
This is also in the design phase. Issues <a
href="https://www.redhat.com/mailman/listinfo/libvir-list"
title="libvir-list mailing list">to discuss</a> include
which path the migration data should follow (eg. client to
client direct, or client to server to client) and security.
</li>
<li> Fine-grained authentication: libvirt in general,
but in particular the remote case should support more
fine-grained authentication for operations, rather than
just read-write/read-only as at present.
</li>
</ul>
<p>
Please come and discuss these issues and more on <a
href="https://www.redhat.com/mailman/listinfo/libvir-list"
title="libvir-list mailing list">the mailing list</a>.
</p>
<h3><a name="Remote_implementation_notes">Implementation notes</a></h3>
<p>
The current implementation uses <a
href="http://en.wikipedia.org/wiki/External_Data_Representation"
title="External Data Representation">XDR</a>-encoded packets with a
simple remote procedure call implementation which also supports
asynchronous messaging and asynchronous and out-of-order replies,
although these latter features are not used at the moment.
</p>
<p>
The implementation should be considered <b>strictly internal</b> to
libvirt and <b>subject to change at any time without notice</b>. If
you wish to talk to libvirtd, link to libvirt. If there is a problem
that means you think you need to use the protocol directly, please
first discuss this on <a
href="https://www.redhat.com/mailman/listinfo/libvir-list"
title="libvir-list mailing list">the mailing list</a>.
</p>
<p>
The messaging protocol is described in
<code>qemud/remote_protocol.x</code>.
</p>
<p>
Authentication and encryption (for TLS) is done using <a
href="http://www.gnu.org/software/gnutls/" title="GnuTLS project
page">GnuTLS</a> and the RPC protocol is unaware of this layer.
</p>
<p>
Protocol messages are sent using a simple 32 bit length word (encoded
XDR int) followed by the message header (XDR
<code>remote_message_header</code>) followed by the message body. The
length count includes the length word itself, and is measured in
bytes. Maximum message size is <code>REMOTE_MESSAGE_MAX</code> and to
avoid denial of services attacks on the XDR decoders strings are
individually limited to <code>REMOTE_STRING_MAX</code> bytes. In the
TLS case, messages may be split over TLS records, but a TLS record
cannot contain parts of more than one message. In the common RPC case
a single <code>REMOTE_CALL</code> message is sent from client to
server, and the server then replies synchronously with a single
<code>REMOTE_REPLY</code> message, but other forms of messaging are
also possible.
</p>
<p>
The protocol contains support for multiple program types and protocol
versioning, modelled after SunRPC.
</p>
</body>
</html>
|
GitWeb