January 2011 - Devel - libvirt List Archives

[libvirt] [PATCH] vmx: Add support for video device VRAM size
by Matthias Bolte 07 Jan '11

07 Jan '11

Update test suite accordingly. --- src/vmx/vmx.c | 110 ++++++++++++++++++++ src/vmx/vmx.h | 4 + tests/vmx2xmldata/vmx2xml-annotation.xml | 3 + tests/vmx2xmldata/vmx2xml-case-insensitive-1.xml | 3 + tests/vmx2xmldata/vmx2xml-case-insensitive-2.xml | 3 + tests/vmx2xmldata/vmx2xml-cdrom-ide-device.xml | 3 + tests/vmx2xmldata/vmx2xml-cdrom-ide-file.xml | 3 + tests/vmx2xmldata/vmx2xml-cdrom-scsi-device.xml | 3 + tests/vmx2xmldata/vmx2xml-cdrom-scsi-file.xml | 3 + tests/vmx2xmldata/vmx2xml-esx-in-the-wild-1.xml | 3 + tests/vmx2xmldata/vmx2xml-esx-in-the-wild-2.xml | 3 + tests/vmx2xmldata/vmx2xml-esx-in-the-wild-3.xml | 3 + tests/vmx2xmldata/vmx2xml-esx-in-the-wild-4.xml | 3 + tests/vmx2xmldata/vmx2xml-esx-in-the-wild-5.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-bridged.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-custom.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-e1000.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-generated.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-other.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-static.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-vmxnet2.xml | 3 + tests/vmx2xmldata/vmx2xml-ethernet-vpx.xml | 3 + tests/vmx2xmldata/vmx2xml-floppy-device.xml | 3 + tests/vmx2xmldata/vmx2xml-floppy-file.xml | 3 + tests/vmx2xmldata/vmx2xml-graphics-vnc.xml | 3 + tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-1.xml | 3 + tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-2.xml | 3 + tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-3.xml | 3 + tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-4.xml | 3 + tests/vmx2xmldata/vmx2xml-harddisk-ide-file.xml | 3 + tests/vmx2xmldata/vmx2xml-harddisk-scsi-file.xml | 3 + tests/vmx2xmldata/vmx2xml-minimal-64bit.xml | 3 + tests/vmx2xmldata/vmx2xml-minimal.xml | 3 + tests/vmx2xmldata/vmx2xml-parallel-device.xml | 3 + tests/vmx2xmldata/vmx2xml-parallel-file.xml | 3 + tests/vmx2xmldata/vmx2xml-scsi-driver.xml | 3 + tests/vmx2xmldata/vmx2xml-scsi-writethrough.xml | 3 + tests/vmx2xmldata/vmx2xml-serial-device.xml | 3 + tests/vmx2xmldata/vmx2xml-serial-file.xml | 3 + .../vmx2xmldata/vmx2xml-serial-network-client.xml | 3 + .../vmx2xmldata/vmx2xml-serial-network-server.xml | 3 + tests/vmx2xmldata/vmx2xml-serial-pipe.xml | 3 + tests/vmx2xmldata/vmx2xml-smbios.xml | 3 + tests/vmx2xmldata/vmx2xml-svga.vmx | 3 + tests/vmx2xmldata/vmx2xml-svga.xml | 18 +++ tests/vmx2xmltest.c | 2 + tests/xml2vmxdata/xml2vmx-graphics-vnc.vmx | 1 + tests/xml2vmxdata/xml2vmx-svga.vmx | 11 ++ tests/xml2vmxdata/xml2vmx-svga.xml | 13 +++ tests/xml2vmxtest.c | 2 + 50 files changed, 287 insertions(+), 0 deletions(-) create mode 100644 tests/vmx2xmldata/vmx2xml-svga.vmx create mode 100644 tests/vmx2xmldata/vmx2xml-svga.xml create mode 100644 tests/xml2vmxdata/xml2vmx-svga.vmx create mode 100644 tests/xml2vmxdata/xml2vmx-svga.xml diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 6e3e9af..76cc16a 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -326,6 +326,16 @@ def->nets[0]... ################################################################################ +## video ####################################################################### + +def->videos[0]... +->type = _VIDEO_TYPE_VMVGA +->vram = <value kilobyte> <=> svga.vramSize = "<value byte>" +->heads = 1 + + + +################################################################################ ## serials ##################################################################### serial[0..3] -> <port> @@ -1636,6 +1646,20 @@ virVMXParseConfig(virVMXContext *ctx, virCapsPtr caps, const char *vmx) /* def:inputs */ /* FIXME */ + /* def:videos */ + if (VIR_ALLOC_N(def->videos, 1) < 0) { + virReportOOMError(); + goto cleanup; + } + + def->nvideos = 0; + + if (virVMXParseSVGA(conf, &def->videos[def->nvideos]) < 0) { + goto cleanup; + } + + def->nvideos = 1; + /* def:sounds */ /* FIXME */ @@ -2765,6 +2789,45 @@ virVMXParseParallel(virVMXContext *ctx, virConfPtr conf, int port, +int +virVMXParseSVGA(virConfPtr conf, virDomainVideoDefPtr *def) +{ + int result = -1; + long long svga_vramSize = 0; + + if (def == NULL || *def != NULL) { + VMX_ERROR(VIR_ERR_INTERNAL_ERROR, "%s", _("Invalid argument")); + return -1; + } + + if (VIR_ALLOC(*def) < 0) { + virReportOOMError(); + return -1; + } + + (*def)->type = VIR_DOMAIN_VIDEO_TYPE_VMVGA; + + /* vmx:vramSize */ + if (virVMXGetConfigLong(conf, "svga.vramSize", &svga_vramSize, + 4 * 1024 * 1024, true) < 0) { + goto cleanup; + } + + (*def)->vram = svga_vramSize / 1024; /* Scale from bytes to kilobytes */ + + result = 0; + + cleanup: + if (result < 0) { + virDomainVideoDefFree(*def); + *def = NULL; + } + + return result; +} + + + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Domain XML -> VMX */ @@ -3064,6 +3127,19 @@ virVMXFormatConfig(virVMXContext *ctx, virCapsPtr caps, virDomainDefPtr def, /* def:sounds */ /* FIXME */ + /* def:videos */ + if (def->nvideos > 0) { + if (def->nvideos > 1) { + VMX_ERROR(VIR_ERR_INTERNAL_ERROR, "%s", + _("No support for multiple video devices")); + goto cleanup; + } + + if (virVMXFormatSVGA(def->videos[0], &buffer) < 0) { + goto cleanup; + } + } + /* def:hostdevs */ /* FIXME */ @@ -3645,3 +3721,37 @@ virVMXFormatParallel(virVMXContext *ctx, virDomainChrDefPtr def, return 0; } + + + +int +virVMXFormatSVGA(virDomainVideoDefPtr def, virBufferPtr buffer) +{ + if (def->type != VIR_DOMAIN_VIDEO_TYPE_VMVGA) { + VMX_ERROR(VIR_ERR_INTERNAL_ERROR, + _("Unsupported video device type '%s'"), + virDomainVideoTypeToString(def->type)); + return -1; + } + + /* + * For Windows guests the VRAM size should be a multiple of 64 kilobyte. + * See http://kb.vmware.com/kb/1003 and http://kb.vmware.com/kb/1001558 + */ + if (def->vram % 64 != 0) { + VMX_ERROR(VIR_ERR_INTERNAL_ERROR, "%s", + _("Video device VRAM size must be a multiple of 64 kilobyte")); + return -1; + } + + if (def->heads > 1) { + VMX_ERROR(VIR_ERR_INTERNAL_ERROR, "%s", + _("Multi-head video devices are unsupported")); + return -1; + } + + virBufferVSprintf(buffer, "svga.vramSize = \"%d\"\n", + def->vram * 1024); /* Scale from kilobytes to bytes */ + + return 0; +} diff --git a/src/vmx/vmx.h b/src/vmx/vmx.h index 1a4fd9c..c317108 100644 --- a/src/vmx/vmx.h +++ b/src/vmx/vmx.h @@ -100,6 +100,8 @@ int virVMXParseSerial(virVMXContext *ctx, virConfPtr conf, int port, int virVMXParseParallel(virVMXContext *ctx, virConfPtr conf, int port, virDomainChrDefPtr *def); +int virVMXParseSVGA(virConfPtr conf, virDomainVideoDefPtr *def); + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * @@ -129,4 +131,6 @@ int virVMXFormatSerial(virVMXContext *ctx, virDomainChrDefPtr def, int virVMXFormatParallel(virVMXContext *ctx, virDomainChrDefPtr def, virBufferPtr buffer); +int virVMXFormatSVGA(virDomainVideoDefPtr def, virBufferPtr buffer); + #endif /* __VIR_VMX_H__ */ diff --git a/tests/vmx2xmldata/vmx2xml-annotation.xml b/tests/vmx2xmldata/vmx2xml-annotation.xml index 1af45aa..f42f77b 100644 --- a/tests/vmx2xmldata/vmx2xml-annotation.xml +++ b/tests/vmx2xmldata/vmx2xml-annotation.xml @@ -12,5 +12,8 @@ <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-case-insensitive-1.xml b/tests/vmx2xmldata/vmx2xml-case-insensitive-1.xml index b47e128..7a5ff5b 100644 --- a/tests/vmx2xmldata/vmx2xml-case-insensitive-1.xml +++ b/tests/vmx2xmldata/vmx2xml-case-insensitive-1.xml @@ -22,5 +22,8 @@ <mac address='00:50:56:91:48:c7'/> <source bridge='VM NETWORK'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-case-insensitive-2.xml b/tests/vmx2xmldata/vmx2xml-case-insensitive-2.xml index 4974f4e..18d6461 100644 --- a/tests/vmx2xmldata/vmx2xml-case-insensitive-2.xml +++ b/tests/vmx2xmldata/vmx2xml-case-insensitive-2.xml @@ -22,5 +22,8 @@ <mac address='00:50:56:91:48:c7'/> <source bridge='vm network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-cdrom-ide-device.xml b/tests/vmx2xmldata/vmx2xml-cdrom-ide-device.xml index 1905f9b..e11d2f9 100644 --- a/tests/vmx2xmldata/vmx2xml-cdrom-ide-device.xml +++ b/tests/vmx2xmldata/vmx2xml-cdrom-ide-device.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-cdrom-ide-file.xml b/tests/vmx2xmldata/vmx2xml-cdrom-ide-file.xml index b9cf1f9..d1fb690 100644 --- a/tests/vmx2xmldata/vmx2xml-cdrom-ide-file.xml +++ b/tests/vmx2xmldata/vmx2xml-cdrom-ide-file.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-cdrom-scsi-device.xml b/tests/vmx2xmldata/vmx2xml-cdrom-scsi-device.xml index 1bb42be..7eb3676 100644 --- a/tests/vmx2xmldata/vmx2xml-cdrom-scsi-device.xml +++ b/tests/vmx2xmldata/vmx2xml-cdrom-scsi-device.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='scsi' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-cdrom-scsi-file.xml b/tests/vmx2xmldata/vmx2xml-cdrom-scsi-file.xml index bdcb0b0..df1e7c4 100644 --- a/tests/vmx2xmldata/vmx2xml-cdrom-scsi-file.xml +++ b/tests/vmx2xmldata/vmx2xml-cdrom-scsi-file.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='scsi' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-1.xml b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-1.xml index fd50008..5e67e74 100644 --- a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-1.xml +++ b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-1.xml @@ -22,5 +22,8 @@ <mac address='00:50:56:91:48:c7'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-2.xml b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-2.xml index e98b679..23fc1f6 100644 --- a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-2.xml +++ b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-2.xml @@ -52,5 +52,8 @@ <source bridge='VM Network'/> <model type='vlance'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-3.xml b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-3.xml index 6d18209..e193fdb 100644 --- a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-3.xml +++ b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-3.xml @@ -34,5 +34,8 @@ <mac address='00:0c:29:f5:c3:0c'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-4.xml b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-4.xml index 4238882..419df51 100644 --- a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-4.xml +++ b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-4.xml @@ -38,5 +38,8 @@ <source path='[498076b2-02796c1a-ef5b-000ae484a6a3] virtMonServ1/serial1.file'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-5.xml b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-5.xml index d55bf6b..0040163 100644 --- a/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-5.xml +++ b/tests/vmx2xmldata/vmx2xml-esx-in-the-wild-5.xml @@ -33,5 +33,8 @@ <source bridge='VM-LAN'/> <model type='e1000'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-bridged.xml b/tests/vmx2xmldata/vmx2xml-ethernet-bridged.xml index 7ef2d3d..cec329d 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-bridged.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-bridged.xml @@ -15,5 +15,8 @@ <mac address='00:50:56:11:22:33'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-custom.xml b/tests/vmx2xmldata/vmx2xml-ethernet-custom.xml index e08a450..8c7b833 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-custom.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-custom.xml @@ -16,5 +16,8 @@ <source bridge='VM Network'/> <target dev='vmnet7'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-e1000.xml b/tests/vmx2xmldata/vmx2xml-ethernet-e1000.xml index 1e64c52..9b356ea 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-e1000.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-e1000.xml @@ -16,5 +16,8 @@ <source bridge='VM Network'/> <model type='e1000'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-generated.xml b/tests/vmx2xmldata/vmx2xml-ethernet-generated.xml index ffb203b..aead831 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-generated.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-generated.xml @@ -15,5 +15,8 @@ <mac address='00:0c:29:11:22:33'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-other.xml b/tests/vmx2xmldata/vmx2xml-ethernet-other.xml index 4c44fbc..a746115 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-other.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-other.xml @@ -15,5 +15,8 @@ <mac address='00:12:34:56:78:90'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-static.xml b/tests/vmx2xmldata/vmx2xml-ethernet-static.xml index 7ef2d3d..cec329d 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-static.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-static.xml @@ -15,5 +15,8 @@ <mac address='00:50:56:11:22:33'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-vmxnet2.xml b/tests/vmx2xmldata/vmx2xml-ethernet-vmxnet2.xml index 090f7ce..b7773ad 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-vmxnet2.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-vmxnet2.xml @@ -16,5 +16,8 @@ <source bridge='VM Network'/> <model type='vmxnet2'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-ethernet-vpx.xml b/tests/vmx2xmldata/vmx2xml-ethernet-vpx.xml index 1d90f31..bdc8d8c 100644 --- a/tests/vmx2xmldata/vmx2xml-ethernet-vpx.xml +++ b/tests/vmx2xmldata/vmx2xml-ethernet-vpx.xml @@ -15,5 +15,8 @@ <mac address='00:50:56:87:65:43'/> <source bridge='VM Network'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-floppy-device.xml b/tests/vmx2xmldata/vmx2xml-floppy-device.xml index 4ae16d5..824849a 100644 --- a/tests/vmx2xmldata/vmx2xml-floppy-device.xml +++ b/tests/vmx2xmldata/vmx2xml-floppy-device.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='fdc' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-floppy-file.xml b/tests/vmx2xmldata/vmx2xml-floppy-file.xml index 5ab538e..75d0d62 100644 --- a/tests/vmx2xmldata/vmx2xml-floppy-file.xml +++ b/tests/vmx2xmldata/vmx2xml-floppy-file.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='fdc' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-graphics-vnc.xml b/tests/vmx2xmldata/vmx2xml-graphics-vnc.xml index 159324d..047e034 100644 --- a/tests/vmx2xmldata/vmx2xml-graphics-vnc.xml +++ b/tests/vmx2xmldata/vmx2xml-graphics-vnc.xml @@ -13,5 +13,8 @@ <devices> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5903' autoport='no' keymap='de' passwd='password'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-1.xml b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-1.xml index 0c308bc..b572ad1 100644 --- a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-1.xml +++ b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-1.xml @@ -23,5 +23,8 @@ <source bridge='net1'/> <target dev='/dev/vmnet1'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-2.xml b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-2.xml index 7b6158f..180cf68 100644 --- a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-2.xml +++ b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-2.xml @@ -23,5 +23,8 @@ <source bridge='net1'/> <target dev='/dev/vmnet1'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-3.xml b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-3.xml index b926db5..571c83a 100644 --- a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-3.xml +++ b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-3.xml @@ -28,5 +28,8 @@ <source bridge='net2'/> <target dev='/dev/vmnet2'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-4.xml b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-4.xml index 5803f4b..fc3b966 100644 --- a/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-4.xml +++ b/tests/vmx2xmldata/vmx2xml-gsx-in-the-wild-4.xml @@ -23,5 +23,8 @@ <source bridge='net2'/> <target dev='/dev/vmnet2'/> </interface> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-harddisk-ide-file.xml b/tests/vmx2xmldata/vmx2xml-harddisk-ide-file.xml index 7699fbb..72a5c1f 100644 --- a/tests/vmx2xmldata/vmx2xml-harddisk-ide-file.xml +++ b/tests/vmx2xmldata/vmx2xml-harddisk-ide-file.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='ide' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-harddisk-scsi-file.xml b/tests/vmx2xmldata/vmx2xml-harddisk-scsi-file.xml index b04597b..189e72d 100644 --- a/tests/vmx2xmldata/vmx2xml-harddisk-scsi-file.xml +++ b/tests/vmx2xmldata/vmx2xml-harddisk-scsi-file.xml @@ -17,5 +17,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='scsi' index='0'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-minimal-64bit.xml b/tests/vmx2xmldata/vmx2xml-minimal-64bit.xml index cec8ba0..188d31a 100644 --- a/tests/vmx2xmldata/vmx2xml-minimal-64bit.xml +++ b/tests/vmx2xmldata/vmx2xml-minimal-64bit.xml @@ -11,5 +11,8 @@ <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-minimal.xml b/tests/vmx2xmldata/vmx2xml-minimal.xml index acfd9bd..ce2cfd6 100644 --- a/tests/vmx2xmldata/vmx2xml-minimal.xml +++ b/tests/vmx2xmldata/vmx2xml-minimal.xml @@ -11,5 +11,8 @@ <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-parallel-device.xml b/tests/vmx2xmldata/vmx2xml-parallel-device.xml index 28c2302..bc288a6 100644 --- a/tests/vmx2xmldata/vmx2xml-parallel-device.xml +++ b/tests/vmx2xmldata/vmx2xml-parallel-device.xml @@ -15,5 +15,8 @@ <source path='/dev/parallel0'/> <target port='0'/> </parallel> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-parallel-file.xml b/tests/vmx2xmldata/vmx2xml-parallel-file.xml index 340cf4e..ad7a65f 100644 --- a/tests/vmx2xmldata/vmx2xml-parallel-file.xml +++ b/tests/vmx2xmldata/vmx2xml-parallel-file.xml @@ -15,5 +15,8 @@ <source path='[datastore] directory/parallel0.file'/> <target port='0'/> </parallel> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-scsi-driver.xml b/tests/vmx2xmldata/vmx2xml-scsi-driver.xml index 553783b..8fa907b 100644 --- a/tests/vmx2xmldata/vmx2xml-scsi-driver.xml +++ b/tests/vmx2xmldata/vmx2xml-scsi-driver.xml @@ -35,5 +35,8 @@ <controller type='scsi' index='1' model='lsilogic'/> <controller type='scsi' index='2' model='lsisas1068'/> <controller type='scsi' index='3' model='vmpvscsi'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-scsi-writethrough.xml b/tests/vmx2xmldata/vmx2xml-scsi-writethrough.xml index 66e22ae..e5b8934 100644 --- a/tests/vmx2xmldata/vmx2xml-scsi-writethrough.xml +++ b/tests/vmx2xmldata/vmx2xml-scsi-writethrough.xml @@ -18,5 +18,8 @@ <address type='drive' controller='0' bus='0' unit='0'/> </disk> <controller type='scsi' index='0' model='buslogic'/> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-serial-device.xml b/tests/vmx2xmldata/vmx2xml-serial-device.xml index c9f00eb..51fd06f 100644 --- a/tests/vmx2xmldata/vmx2xml-serial-device.xml +++ b/tests/vmx2xmldata/vmx2xml-serial-device.xml @@ -19,5 +19,8 @@ <source path='/dev/ttyS0'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-serial-file.xml b/tests/vmx2xmldata/vmx2xml-serial-file.xml index 21b6263..25ade07 100644 --- a/tests/vmx2xmldata/vmx2xml-serial-file.xml +++ b/tests/vmx2xmldata/vmx2xml-serial-file.xml @@ -19,5 +19,8 @@ <source path='[datastore] directory/serial0.file'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-serial-network-client.xml b/tests/vmx2xmldata/vmx2xml-serial-network-client.xml index b0c0715..7573a11 100644 --- a/tests/vmx2xmldata/vmx2xml-serial-network-client.xml +++ b/tests/vmx2xmldata/vmx2xml-serial-network-client.xml @@ -21,5 +21,8 @@ <protocol type='raw'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-serial-network-server.xml b/tests/vmx2xmldata/vmx2xml-serial-network-server.xml index e151017..ed38495 100644 --- a/tests/vmx2xmldata/vmx2xml-serial-network-server.xml +++ b/tests/vmx2xmldata/vmx2xml-serial-network-server.xml @@ -21,5 +21,8 @@ <protocol type='telnets'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-serial-pipe.xml b/tests/vmx2xmldata/vmx2xml-serial-pipe.xml index cf8a797..ca5196c 100644 --- a/tests/vmx2xmldata/vmx2xml-serial-pipe.xml +++ b/tests/vmx2xmldata/vmx2xml-serial-pipe.xml @@ -19,5 +19,8 @@ <source path='serial0.pipe'/> <target type='serial' port='0'/> </console> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-smbios.xml b/tests/vmx2xmldata/vmx2xml-smbios.xml index db13001..d78ac6c 100644 --- a/tests/vmx2xmldata/vmx2xml-smbios.xml +++ b/tests/vmx2xmldata/vmx2xml-smbios.xml @@ -12,5 +12,8 @@ <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> + <video> + <model type='vmvga' vram='4096'/> + </video> </devices> </domain> diff --git a/tests/vmx2xmldata/vmx2xml-svga.vmx b/tests/vmx2xmldata/vmx2xml-svga.vmx new file mode 100644 index 0000000..081d6ce --- /dev/null +++ b/tests/vmx2xmldata/vmx2xml-svga.vmx @@ -0,0 +1,3 @@ +config.version = "8" +virtualHW.version = "4" +svga.vramSize = "8388608" diff --git a/tests/vmx2xmldata/vmx2xml-svga.xml b/tests/vmx2xmldata/vmx2xml-svga.xml new file mode 100644 index 0000000..664eba4 --- /dev/null +++ b/tests/vmx2xmldata/vmx2xml-svga.xml @@ -0,0 +1,18 @@ +<domain type='vmware'> + <uuid>00000000-0000-0000-0000-000000000000</uuid> + <memory>32768</memory> + <currentMemory>32768</currentMemory> + <vcpu>1</vcpu> + <os> + <type arch='i686'>hvm</type> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <video> + <model type='vmvga' vram='8192'/> + </video> + </devices> +</domain> diff --git a/tests/vmx2xmltest.c b/tests/vmx2xmltest.c index 9378db3..5fed1c4 100644 --- a/tests/vmx2xmltest.c +++ b/tests/vmx2xmltest.c @@ -285,6 +285,8 @@ mymain(int argc, char **argv) DO_TEST("smbios", "smbios"); + DO_TEST("svga", "svga"); + virCapabilitiesFree(caps); return result == 0 ? EXIT_SUCCESS : EXIT_FAILURE; diff --git a/tests/xml2vmxdata/xml2vmx-graphics-vnc.vmx b/tests/xml2vmxdata/xml2vmx-graphics-vnc.vmx index caab06a..493e0cc 100644 --- a/tests/xml2vmxdata/xml2vmx-graphics-vnc.vmx +++ b/tests/xml2vmxdata/xml2vmx-graphics-vnc.vmx @@ -12,3 +12,4 @@ RemoteDisplay.vnc.keymap = "de" RemoteDisplay.vnc.password = "password" floppy0.present = "false" floppy1.present = "false" +svga.vramSize = "4194304" diff --git a/tests/xml2vmxdata/xml2vmx-svga.vmx b/tests/xml2vmxdata/xml2vmx-svga.vmx new file mode 100644 index 0000000..4bd4870 --- /dev/null +++ b/tests/xml2vmxdata/xml2vmx-svga.vmx @@ -0,0 +1,11 @@ +.encoding = "UTF-8" +config.version = "8" +virtualHW.version = "4" +guestOS = "other" +uuid.bios = "56 4d 9b ef ac d9 b4 e0-c8 f0 ae a8 b9 10 35 15" +displayName = "minimal" +memsize = "4" +numvcpus = "1" +floppy0.present = "false" +floppy1.present = "false" +svga.vramSize = "8388608" diff --git a/tests/xml2vmxdata/xml2vmx-svga.xml b/tests/xml2vmxdata/xml2vmx-svga.xml new file mode 100644 index 0000000..b7db4c8 --- /dev/null +++ b/tests/xml2vmxdata/xml2vmx-svga.xml @@ -0,0 +1,13 @@ +<domain type='vmware'> + <name>minimal</name> + <uuid>564d9bef-acd9-b4e0-c8f0-aea8b9103515</uuid> + <memory>4096</memory> + <os> + <type>hvm</type> + </os> + <devices> + <video> + <model type='vmvga' vram='8192'/> + </video> + </devices> +</domain> diff --git a/tests/xml2vmxtest.c b/tests/xml2vmxtest.c index 6a39582..a5fb4f7 100644 --- a/tests/xml2vmxtest.c +++ b/tests/xml2vmxtest.c @@ -296,6 +296,8 @@ mymain(int argc, char **argv) DO_TEST("smbios", "smbios", 4); + DO_TEST("svga", "svga", 4); + virCapabilitiesFree(caps); return result == 0 ? EXIT_SUCCESS : EXIT_FAILURE; -- 1.7.0.4

2 2

[libvirt] [PATCH] Don't chown qemu saved image back to root after save if dynamic_ownership=0
by Laine Stump 07 Jan '11

07 Jan '11

When dynamic_ownership=0, saved images must be owned by the same uid as is used to run the qemu process, otherwise restore won't work. To accomplish this, qemuSecurityDACRestoreSavedStateLabel() needs to simply return when it's called. This fix is in response to: https://bugzilla.redhat.com/show_bug.cgi?id=661720 --- Note that this still leaves open the issue discovered in this bug - if the saved image file already exists when it is "created" for the new save, whatever mode it has will be maintained, rather than forcing 0600. It would be simple to force the mode to 0600 (just add a flag to virFileOperation(), but I'm not sure if it would be safe to do so right now without a *lot* of testing (I'm concerned about possible scenarios where the chmod() that's done when the FORCE_PERMISSIONS flag is set might fail, making a previously working case fail). Any opinions on that? (At any rate, it should be done in a separate patch if we decide to do it). src/qemu/qemu_security_dac.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_security_dac.c b/src/qemu/qemu_security_dac.c index b5c52d1..6b6170a 100644 --- a/src/qemu/qemu_security_dac.c +++ b/src/qemu/qemu_security_dac.c @@ -533,7 +533,7 @@ qemuSecurityDACRestoreSavedStateLabel(virSecurityDriverPtr drv ATTRIBUTE_UNUSED, virDomainObjPtr vm ATTRIBUTE_UNUSED, const char *savefile) { - if (!driver->privileged) + if (!driver->privileged || !driver->dynamicOwnership) return 0; return qemuSecurityDACRestoreSecurityFileLabel(savefile); -- 1.7.3.4

3 4

[libvirt] [PATCH] wrong if-condition in bridge_driver.c, networkBuildDnsmasqArgv, dhcp host definition
by Kay Schubert 07 Jan '11

07 Jan '11

I added a host definition to a network definition: <network> <name>Lokal</name> <uuid>2074f379-b82c-423f-9ada-305d8088daaa</uuid> <bridge name='virbr1' stp='on' delay='0' /> <ip address='192.168.180.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.180.128' end='192.168.180.254' /> <host mac='23:74:00:03:42:02' name='somevm' ip='192.168.180.10' /> </dhcp> </ip> </network> But due to the wrong if-statement the argument --dhcp-hostsfile doesn't get added to the dnsmasq command. The patch below fixes it for me. diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 7d43ef5..4c64a74 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -524,7 +524,7 @@ networkBuildDnsmasqArgv(virNetworkObjPtr network, goto cleanup; } - if (networkSaveDnsmasqHostsfile(ipdef, dctx, false) < 0) { + if (networkSaveDnsmasqHostsfile(ipdef, dctx, false) == 0) { virCommandAddArgPair(cmd, "--dhcp-hostsfile", dctx->hostsfile->path); }

3 2

[libvirt] [PATCH] Device reattach: Check if device is assigned to guest before reattaching
by Yufang Zhang 07 Jan '11

07 Jan '11

Reattaching pci device back to host without destroying guest or detaching device from guest would cause host to crash. This patch adds a check before doing device reattach. If the device is being assigned to guest, libvirt refuses to reattach device to host. Note that the patch only works for Xen, for it just checks xenstore to get pci device information. Signed-off-by: Yufang Zhang <yuzhang(a)redhat.com> --- src/xen/xen_driver.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 67 insertions(+), 0 deletions(-) diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c index 4c11b11..5773d3b 100644 --- a/src/xen/xen_driver.c +++ b/src/xen/xen_driver.c @@ -1891,11 +1891,70 @@ out: } static int +xenUnifiedNodeDeviceIsAssigned (virNodeDevicePtr dev) +{ + int numdomains; + int ret = -1, i; + int *ids = NULL; + char *bdf = NULL; + char *xref = NULL; + unsigned domain, bus, slot, function; + virConnectPtr conn = dev->conn; + xenUnifiedPrivatePtr priv = conn->privateData; + + /* Get active domains */ + numdomains = xenUnifiedNumOfDomains(conn); + if (numdomains < 0) { + return(ret); + } + if (numdomains > 0){ + if (VIR_ALLOC_N(ids, numdomains) < 0){ + virReportOOMError(); + goto out; + } + if ((numdomains = xenUnifiedListDomains(conn, &ids[0], numdomains)) < 0){ + goto out; + } + } + + /* Get pci bdf */ + if (xenUnifiedNodeDeviceGetPciInfo(dev, &domain, &bus, &slot, &function) < 0) + goto out; + + if (virAsprintf(&bdf, "%04x:%02x:%02x.%0x", + domain, bus, slot, function) < 0) { + virReportOOMError(); + goto out; + } + + /* Check if bdf is assigned to one of active domains */ + for (i = 0; i < numdomains; i++ ){ + xenUnifiedLock(priv); + xref = xenStoreDomainGetPCIID(conn, ids[i], bdf); + xenUnifiedUnlock(priv); + if (xref == NULL) + continue; + else { + ret = ids[i]; + break; + } + } + + VIR_FREE(xref); + VIR_FREE(bdf); +out: + VIR_FREE(ids); + + return(ret); +} + +static int xenUnifiedNodeDeviceReAttach (virNodeDevicePtr dev) { pciDevice *pci; unsigned domain, bus, slot, function; int ret = -1; + int dom; if (xenUnifiedNodeDeviceGetPciInfo(dev, &domain, &bus, &slot, &function) < 0) return -1; @@ -1904,6 +1963,14 @@ xenUnifiedNodeDeviceReAttach (virNodeDevicePtr dev) if (!pci) return -1; + /* Check if device is assigned to an active guest */ + if ((dom = xenUnifiedNodeDeviceIsAssigned(dev)) >= 0){ + xenUnifiedError(VIR_ERR_INTERNAL_ERROR, + _("Device %s has been assigned to guest %d"), + dev->name, dom); + goto out; + } + if (pciReAttachDevice(pci, NULL) < 0) goto out; -- 1.7.3.4

2 1

[libvirt] commandtest fails when executed with preloaded libraries
by Diego Elio Pettenò 07 Jan '11

07 Jan '11

In Gentoo we sandbox software installation with a software called sandbox, which basically is a preloaded library that wraps around a number of file access functions. This method seems to break commandtest because the environment now has a LD_PRELOAD variable in it, which is not accounted for in the pre-generated log files. Any idea how I should go about to solve this beside adding LD_PRELOAD to the log files themselves for Gentoo? -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/

3 2

[libvirt] [00/15] Re-factoring XDR RPC code v2
by Daniel P. Berrange 07 Jan '11

07 Jan '11

A followup to http://www.redhat.com/archives/libvir-list/2010-December/msg00051.html Since that time - The SASL/TLS I/O code has been integrated into the virNetSocket class directly to remove duplication between client&servers - libvirtd has been converted to use the new APIs - Error handling has been sanitized across libvirtd to use the normal virReportError APIs - A couple of test cases have been written - Many locking, ref counting & ramdom crash bugs fixed - Some basic interoperability testing against previous code This is still not quite functionally complete, so not ready to apply. The missing pieces are - Make the client side streams code work again - Re-integrate DTrace probes in libvirtd Daniel

3 29

[libvirt] [PATCH] schema: tighten <serial><protocol type=...> relaxNG
by Eric Blake 07 Jan '11

07 Jan '11

virDomainChrTcpProtocol only accepts particular <protocol type=...> values, but we weren't enforcing that in the RelaxNG. The valid types are also already documented in docs/formatdomain.html.in. * docs/schemas/domain.rng (qemucdevSrcDef): Restrict list of supported <protocol type=> values. --- Noticed this while working on <smartcard>, but it is an independent issue worth fixing whenever it gets an ack. docs/schemas/domain.rng | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index eee9864..a524e4b 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -1448,7 +1448,14 @@ <optional> <element name="protocol"> <optional> - <attribute name="type"/> + <attribute name="type"> + <choice> + <value>raw</value> + <value>telnet</value> + <value>telnets</value> + <value>tls</value> + </choice> + </attribute> </optional> </element> </optional> -- 1.7.3.4

2 2

Re: [libvirt] adding smartcard support to libvirt
by Eric Blake 07 Jan '11

07 Jan '11

[adding the public list for feedback on new XML. Background: Alon is working on adding some new command line arguments to qemu to make it possible to share smartcard access between a host and its virtual guests; while this is not upstream yet, libvirt should be prepared to handle the new command line options] [lengthy email; skip to the tail end for a high-level summary of proposed XML changes] On 12/22/2010 03:00 AM, Alon Levy wrote: > On Mon, Dec 20, 2010 at 12:19:42PM -0700, Eric Blake wrote: >> I also found the following which also served as a good overview for what >> you are proposing to add to qemu: >> >> http://cgit.freedesktop.org/~alon/qemu/commit/?h=usb_ccid.v9&id=d5484a05 > > Of course, sorry, should have pointed you to that initially. I wrote the > ccid.txt one, the other is Robert Relyea's (the author of the libcacard > library). > >> >> Right now, I'm thinking of adding a new <smartcard> element under >> <devices>. Let me know if this makes sense or needs tweaking; once the >> XML is in place, I can then figure out how to map to qemu command lines >> pretty easily. > > Ok, so to make a little order: There are three devices being added to qemu, > they are: > * usb-ccid - this is both a usb device and a ccid bus. The rest of the devices > attach to this bus (so they don't care that the bus is actually a usb device > itself, same as a PCI device exposing an IDE bus). > * ccid-card-emulated - this device uses NSS directly, so it can work in two modes: > * no arguments at all - in this case it will look for whatever hardware NSS can > access by default. This will depend on the specific host setup, and on the user > credentials qemu is running under. > * cert1, cert2, cert3 arguments - in this case NSS will look for three certs > with the names supplied, and use them instead of any physical hardware. In this case qemu > just needs to have those certificates available, and no physical hardware is required. > * ccid-card-passthru - this device doesn't rely on NSS at all. Instead it uses a chardevice, > and implements the VSCard protocol over it, which is just a simple protocol for remoting > the CCID requests (actually it works in the APDU level, so it doesn't care for CCID specifically, > but then again if you read the CCID you'll notice the main messages are XferBlock which just passes > an APDU along too). > Here there are also two basic options, depending on which char device we want to use. Of course you > are not limited to these two, you can use any chardevice, but I've been using only these two and > I can't think of a use for any other right now: > * tcp socket char device - in this case you can use the accompanying libcacard/vscclient program > running on another (or the same) machine, it uses NSS in exactly the same ways (certs/hw) as described > above for the emulated card (which is of course natural since it is using the same library to do > that, libcacard). > * spice chardevice - this is a chardevice that uses libspice, which is linked with qemu. spice in > turn will use a channel to the client which links with libcacard. This device is available here: > http://lists.gnu.org/archive/html/qemu-devel/2010-12/msg01442.html > as you can see from that thread, it isn't accepted yet, but anthony told me he wants to schedule > vdagent (and by extension, spice chardevice, i.e. spicevmc chardev) talk to qemu community meeting > after new years. > > > So I hope you understand that you do in fact need some device, in this case > the usb-ccid device, it's only the card emulated that uses the certificates, > not the bus device. The bus device remains the same for all of the various > configurations. > Just to restate (to make sure I'm understanding you correctly), smartcard support in qemu requires that you enable two things: the usb-ccid device, and your choice of the ccid-card-emulated device or the ccid-card-passthru device. The ccid-card-emulated device operates in two modes, and the ccid-card-passthru device uses a protocol to talk through a required associated chardev (where the other end of the chardev can operate in two modes, but that's outside of what the guest can see; and where two particular chardevs make the most sense). > So after this lengthy summary, you see that actually the mode tag is good, I guess also the names > you set are good. Picking the right mode names is probably the hardest part of writing new XML in a way that can be reused across other hypervisor technologies if similar approaches are adopted there, as well as allowing reasonable XML additions in the future, which is why I'm opening the feedback to make sure it all looks good. >>> * passthrough from a host attached smartcard reader. (despite passthrough in the use >>> case name, this is actually done using the ccid-card-emulated device) >> >> <domain...> >> <devices> >> <smartcard mode='host'> >> <source path='usb-ccid'/> >> </smartcard> >> </devices> >> </domain> >> >> maps to qemu -usb -device usb-ccid -device ccid-card-emulated > I don't really grok the "source path='usb-ccid'", unless you just want to ensure > that this can be replaced with other devices in the future, which in this case sounds good to me. > Then <source> isn't quite the right terminology for this. If we ever do come up with a future qemu device that can replace usb-ccid while still providing everything needed for the ccid-card-emulated device to work, then we can augment the XML at that point for choosing how to replace the usb-ccid device, but I don't think we need to tie it to <source> for the current proposal. So, this mode can be simplified. In other words, requesting mode='host' implies turning on anything in the hypervisor necessary to let the hypervisor use NSS access to the host's smartcard support (in qemu's case, turning on both the usb-ccid device and the ccid-card-emulated device with no arguments). Therefore, mode='host' wouldn't need any sub-elements for now. <domain...> <devices> <smartcard mode='host'/> </devices> </domain> >>> * passthrough from a client via vscclient program (this is done using ccid-card-passthrough >>> but with a standard tcp chardevice) >> >> <domain...> >> <devices> >> <smartcard mode='certificates'> >> <source path='usb-ccid'/> >> <certificate id='1' path='cert1'/> >> <certificate id='2' path='cert2'/> >> <certificate id='3' path='cert3'/> >> </smartcard> >> </devices> >> </domain> >> >> maps to qemu -usb -device usb-ccid -device >> ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3 >> >> Libvirt will have to ensure that the qemu user has access rights to read >> the three certificate files on the host. My idea here is that >> mode='certificates' requires an element for the host source, as well as >> paths to the three host certificates. > Also, maybe call certificates mode host-certificates, just to make it obvious? So, here's the updated proposal (again, dropping a <source> element, and picking a better mode name): <domain...> <devices> <smartcard mode='host-certificates'> <certificate id='1' path='cert1'/> <certificate id='2' path='cert2'/> <certificate id='3' path='cert3'/> </smartcard> </devices> </domain> >>> * passthrough with spice ('my' use case, -chardev spicevmc,id=smartcard,name=smartcard -device ccid-card-passthru,chardev=smartcard) >> >> <domain...> >> <devices> >> <smartcard mode='passthrough' name='smartcard'> >> <serial type='smartcard'> >> <source path='spicevmc'/> >> </serial> >> </smartcard> >> </devices> >> </domain >> >> maps to qemu -chardev spicevmc,id=smartcard,name=smartcard -device >> ccid-card-passthru,chardev=smartcard >> My idea here is that mode='passthrough' requires a name, which then gets >> used to create both the smartcard passthrough device and the backing >> chardev device. Then, as a child element, <smartcard> contains any >> other valid element that could serve as a top-level device, such as >> <serial type='tcp'>. >> > > Ok, so this is wrong - there are actually two source paths, if I understand > the idea - you would still want to explicitly specify usb-ccid (again, assuming this > is a future proofing for changing the underlying device), and the other would be > the spicevmc, and it would translate to the following command line: > > qemu -chardev spicevmc,id=smartcard,name=smartcard -usb -device usb-ccid > -device ccud-card-passthru,chardev=smartcard > > I guess something like: > > <smartcard mode='passthrough' name='smartcard'> > <source path='usb-ccid'/> > <serial type='smartcard'> > <source path='spicevmc'/> > </serial> > </smartcard> So the key point here is that use of the ccid-card-passthru device requires a chardev=xyz argument that maps to another existing -chardev device. And given that the chardev device in use is essential to the smartcard support, I'm proposing that the <smartcard> element require the paired chardev device as a sub-element, rather than as a sibling element. Right now, the XML for <devices> allows the following <serial> types: dev, file, pipe, unix, tcp, udp, null, stdio, vc, pty so there's no notion of a type='smartcard'. It looks more like the new serial type is 'spicevmc'. And back to my idea of omitting mention of usb-ccid in the XML, and refactoring things to avoid dupicate use of strings (to make it a bit more obvious which XML aspects impact which command-line aspects), that leaves us with: <domain...> <devices> <smartcard mode='passthrough' name='xyz'> <serial type='spicevmc'/> </smartcard> </devices> </domain> maps to qemu -chardev spicevmc,id=smartcard,name=xyz -usb -device usb-ccid -device ccid-card-passthru,chardev=xyz Am I correct that a spicevmc -chardev has to use a fixed id=smartcard but an arbitrary name, and that ccid-card-passthru has to have a chardev=name that maps to the same name= used for a -chardev? Or is it that ccid-card-passthru has to have a chardev=name that maps to the same name as a -chardev id=name? And, given the goal that <smartcard mode='passthrough'> then has a child element that describes the passthrough device, it also means that I would be adding support for a top-level spicevmc chardev device, unrelated to smartcards; would this need any additional XML parameters? <domain...> <devices> <serial type='spicevmc'>  </serial> </devices> </domain> > >> <domain...> >> <devices> >> <smartcard mode='passthrough' name='ccid'> >> <serial type='tcp'> >> <source host='0.0.0.0' port='2001'/> >> <protocol type='tcp'/> >> </serial> >> </smartcard> >> </devices> >> </domain> >> >> maps to qemu -chardev >> socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb -device >> usb-ccid -device ccid-card-passthru,chardev=ccid >> > > So actually here you got the command line correctly (again, no difference > between both ccid-card-passthru uses except for the -chardev created), and > I guess I would just add the same usb-ccid specification to your element: > > <smartcard mode='passthrough' name='ccid'> > <source path='usb-ccid'/> > <serial type='tcp'> > <source host='0.0.0.0' port='2001'/> > <protocol type='tcp'/> > </serial> > </smartcard> > > btw, I'm guessing the name attribute on the top level (smartcard) element is > just a descriptor, like id? or is it something else? does libvirt have > id and name, or just name? My thoughts were that the name attribute of the <smartcard> element becomes the string that get reused twice in the qemu command line (once in the -chardev name, once I figure out whether that is by the id= or the name= field, and once in the -ccid-card-passthru chardev= field). This one is a bit easier, since top-level <serial type='tcp'> already exists, so I think this one remains: <domain...> <devices> <smartcard mode='passthrough' name='ccid'> <serial type='tcp'> <source host='0.0.0.0' port='2001'/> <protocol type='tcp'/> </serial> </smartcard> </devices> </domain> >> > > Ok, so I don't understand exactly what you wanted the name to mean. Unless > you meant for it to do exactly what I thought adding a source element side by > side with the serial element would do, namely specifying the device (devices) > to use, what I called future proofing. > >>> * emulated with certificates (ccid-card-emulated with proper parameters to use user provided file certificates) >> >> Since the certificates live in the guest and do not pass through the >> qemu command line, my understanding is that libvirt does not see this as >> any different from mode='passthrough' above. > > Yes, I just specified this for completness sake. > In summary, this is my proposal for the new XML; feedback welcome to correct anything: <devices> modifies one existing sub-element (<serial> learns a new type='spicevmc' to match qemu's new spicevmc chardev), and adds a new sub-element <smartcard>. The new <smartcard> element has a required mode attribute, that takes on one of three strings: <smartcard mode='host'/> no other attributes, no sub-elements. Implies that the hypervisor exposes whatever devices necessary to the guest to see a smartcard, and feeds the smartcard implementation by communicating natively with the host smartcard for all needed information (maps to qemu -usb -device usb-ccid -device ccid-card-emulated) <smartcard mode='host-certificates'> <certificate id='1' path='cert1'/> <certificate id='2' path='cert2'/> <certificate id='3' path='cert3'/> </smartcard> no other attributes, but requires three <certificate> sub-elements. Implies that the hypervisor exposes whatever devices necessary to the guest to see a smartcard, and that it feeds the smartcard implementation with three certificate files living in the host rather than trying to talk to a host smartcard (maps to qemu -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3) <smartcard mode='passthrough' name='xyz'> <serial .../> </smartcard> name attribute is optional but recommended (assuming libvirt can create a unique name if none is provided). <serial> sub-element is required, with the same form as a normal <serial> sub-element of <devices>, but the common uses will be <serial type='tcp'> (existing) or <serial type='spicevmc'> (new). Implies that the hypervisor exposes whatever devices necessary to the guest to see a smartcard, and that it feeds the smartcard implementation via the associated char device (maps to qemu -chardev ...,name=xyz -usb -device usb-ccid -device ccid-card-passthru,chardev-xyz) -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

3 10

[libvirt] [PATCH] qemu-monitor-command: hide the low level protocol
by Lai Jiangshan 06 Jan '11

06 Jan '11

When qmp protocol is available, the libvirt will use this protocol to communicates with qemu. And when we use "virsh qemu-monitor-command", we need: virsh qemu-monitor-command dom '{ "execute": "eject", \ "arguments": { "device": "ide1-cd0" } }' But virsh is typical a human command line interface, it is not comfortable that a human user has to construct such commands. This patch makes human user can use virsh qemu-monitor-command dom 'eject ide1-cd0' in any time(qmp protocol is available or not). The result string is also converted to the same as non-qmp-protocol version. The user do not need to concern about the low level protocol now. Signed-off-by: Lai Jiangshan <laijs(a)cn.fujitsu.com> --- diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 7877731..0f11a78 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2381,9 +2381,12 @@ int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, { virJSONValuePtr cmd = NULL; virJSONValuePtr reply = NULL; + char *p, *q; int ret = -1; - cmd = virJSONValueFromString(cmd_str); + cmd = qemuMonitorJSONMakeCommand("human-monitor-command", + "s:command-line", cmd_str, + NULL); if (!cmd) return -1; @@ -2394,6 +2397,37 @@ int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, if (!(*reply_str)) goto cleanup; + q = *reply_str; + + /* strip the head and tail */ + p= q + strlen("{\"return\":\""); + *(q + strlen(q) - strlen("\"}")) = 0; + + /* inplace copy and convert escapes */ + while (*p) { + if (*p == '\\') { + char c = 0; + + switch (*(p + 1)) { + case 'r': c = '\r'; break; + case 'n': c = '\n'; break; + case 't': c = '\t'; break; + case '\'': c = '\''; break; + case '\\': c = '\\'; break; + case '\"': c = '\"'; break; + default: break; + } + + if (c) { + p += 2; + *(q++) = c; + continue; + } + } + *(q++) = *(p++); + } + *q = 0; + ret = 0; cleanup:

2 1

[libvirt] [PATCH] bridge_driver: use conffile for dnsmasq if it exists
by Paweł Krześniak 06 Jan '11

06 Jan '11

By default dnsmasq is spawned with option --conf-file="" which disables reading of global configuration file -- this is fine for most situations. This patch adds possibility to run customized DNS/DHCP environment, by spawning dnsmasq with alternative configuration file if such file exists. This allows you to set any parameter described in dnsmasq(8). Configuration file is expected to be located in file named "<network_name>-dnsmasq.conf" in DNSMASQ_STATE_DIR directory. If configuration file doesn't exists dnsmasq is spawned as before. Patch should be applied after my earlier one. --- src/network/bridge_driver.c | 26 +++++++++++++++++++------- 1 files changed, 19 insertions(+), 7 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index f2857b4..702ec95 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -391,6 +391,7 @@ networkSaveDnsmasqHostsfile(virNetworkObjPtr network, static int networkBuildDnsmasqArgv(virNetworkObjPtr network, const char *pidfile, + const char *conffile, virCommandPtr cmd) { int r, ret = -1; int nbleases = 0; @@ -428,8 +429,11 @@ networkBuildDnsmasqArgv(virNetworkObjPtr network, virCommandAddArgPair(cmd, "--pid-file", pidfile); - /* *no* conf file */ - virCommandAddArgList(cmd, "--conf-file=", "", NULL); + /* if conf file exists use it */ + if (virFileExists(conffile)) + virCommandAddArgPair(cmd, "--conf-file", conffile); + else + virCommandAddArgList(cmd, "--conf-file=", "", NULL); /* * XXX does not actually work, due to some kind of @@ -528,35 +532,41 @@ dhcpStartDhcpDaemon(virNetworkObjPtr network) virCommandPtr cmd = NULL; char *pidfile = NULL; int ret = -1, err; + char *conffile = NULL; network->dnsmasqPid = -1; if (!VIR_SOCKET_IS_FAMILY(&network->def->ipAddress, AF_INET)) { networkReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("cannot start dhcp daemon without IPv4 address for server")); - goto cleanup2; + goto cleanup3; } if ((err = virFileMakePath(NETWORK_PID_DIR)) != 0) { virReportSystemError(err, _("cannot create directory %s"), NETWORK_PID_DIR); - goto cleanup2; + goto cleanup3; } if ((err = virFileMakePath(NETWORK_STATE_DIR)) != 0) { virReportSystemError(err, _("cannot create directory %s"), NETWORK_STATE_DIR); - goto cleanup2; + goto cleanup3; } if (!(pidfile = virFilePid(NETWORK_PID_DIR, network->def->name))) { virReportOOMError(); + goto cleanup3; + } + + if (virAsprintf(&conffile, DNSMASQ_STATE_DIR "/%s-dnsmasq.conf", network->def->name) < 0) { + virReportOOMError(); goto cleanup2; } cmd = virCommandNew(DNSMASQ); - if (networkBuildDnsmasqArgv(network, pidfile, cmd) < 0) { + if (networkBuildDnsmasqArgv(network, pidfile, conffile, cmd) < 0) { goto cleanup1; } @@ -577,9 +587,11 @@ dhcpStartDhcpDaemon(virNetworkObjPtr network) ret = 0; cleanup1: - VIR_FREE(pidfile); virCommandFree(cmd); + VIR_FREE(conffile); cleanup2: + VIR_FREE(pidfile); +cleanup3: return ret; }

4 12