I found 'virsh edit' is the recommended way to make changes to a VM 
configuration, the XML file is not referenced at boot, it is only saved to with 
'virsh dumpxml'.  'virsh edit' will update both areas - hypervisor and XML file.

Unfortunately the changes I make for smbios and sysinfo (as below) while 
editing don't appear to be accepted when saving with 'virsh edit'.  I wonder if 
they are perhaps not supported with virsh edit yet?

Does anyone have experience with this, or an idea on why I would receive 'bad 
file descriptor' errors using the kvm command manually.

Thanks in advance,
Derek

On 23/08/2011, at 11:55 AM, Derek wrote:

> Thanks everyone for the useful replies.
> 
> I am using libvirt, one thing i'm observing after adding the following 
> sysinfo to the VM.xml file is that in the qemu log file for the VM it is not 
> being passed to the command when booting.
> 
>  <os>
>    <type arch='x86_64' machine='pc-0.12'>hvm</type>
>    <boot dev='cdrom'/>
>    <smbios mode='sysinfo'/>
>  </os>
>  <sysinfo type='smbios'>
>    <bios>
>      <entry name='vendor'>xxx xxx</entry>
>    </bios>
>    <system>
>      <entry name='product'>xxx</entry>
>      <entry name='manufacturer'>xxx xxx</entry>
>      <entry name='vendor'>xxx</entry>
>      <entry name='model'>xxx</entry>
>    </system>
>  </sysinfo>
> 
> Is there a step i'm missing to have the xml file re-read after changes?
> 
> Editing the xml file on the command line, and using libvirt to boot.
> 
> FYI here is the command shown in the logs while booting..
> 
> LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
> HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M 
> pc-0.12 -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name Test 
> -uuid a8024009-d459-ad03-0fca-304746a93c8a -nodefaults -chardev 
> socket,id=monitor,path=/var/lib/libvirt/qemu/HMC.monitor,server,nowait -mon 
> chardev=monitor,mode=readline -rtc base=utc -boot d -drive 
> file=/install-images/install.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
>  -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device 
> rtl8139,vlan=0,id=net0,mac=52:54:00:4e:80:a4,bus=pci.0,addr=0x3 -net 
> tap,fd=49,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device 
> isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:4 -vga cirrus -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 
> char device redirected to /dev/pts/4
> 
> I tried running the above manually with -smbios type=1 etc added but I am 
> receiving bad file descriptor errors, perhaps my own error or inexperience 
> with KVM.
> 
> Thanks!
> Derek
> 
> On 23/08/2011, at 8:03 AM, Ryan Harper wrote:
> 
>> * Andrew Cathrow <acath...@redhat.com> [2011-08-22 06:55]:
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Derek" <li...@stuntkiwi.com>
>>>> To: kvm@vger.kernel.org
>>>> Sent: Sunday, August 21, 2011 11:52:19 PM
>>>> Subject: DMI BIOS String
>>>> Hi Folks,
>>>> 
>>>> I could not track down any solid info on modifying the DMI BIOS
>>>> string.
>>> 
>>> qemu-kvm -help | grep bios
>>> 
>>> -smbios file=binary
>> 
>> for binary mode, this commit message is most helpful
>> 
>> 
>> commit b6f6e3d3a71cee61320216a42940cfaa9b42a162
>> Author: aliguori <aliguori@c046a42c-6fe2-441c-8c8c-71466251a162>
>> Date:   Fri Apr 17 18:59:56 2009 +0000
>> 
>>   qemu: Add support for SMBIOS command line otions (Alex Williamson)
>> 
>>   Create a new -smbios option (x86-only) to allow binary SMBIOS entries
>>   to be passed through to the BIOS or modify the default values of
>>   individual fields of type 0 and 1 entries on the command line.
>> 
>>   Binary SMBIOS entries can be generated as follows:
>> 
>>   dmidecode -t 1 -u | grep $'^\t\t[^"]' | xargs -n1 | \
>>           perl -lne 'printf "%c", hex($_)' > smbios_type_1.bin
>> 
>>   These can then be passed to the BIOS using this switch:
>> 
>>    -smbios file=smbios_type_1.bin
>> 
>>   Command line generation supports the following syntax:
>> 
>>    -smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
>>    -smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
>>                 [,uuid=$(uuidgen)][,sku=str][,family=str]
>> 
>>   For instance, to add a serial number to the type 1 table:
>> 
>>    -smbios type=1,serial=0123456789
>> 
>>   Interface is extensible to support more fields/tables as needed.
>> 
>>   aliguori: remove texi formatting from help output
>> 
>>   Signed-off-by: Alex Williamson <alex.william...@hp.com>
>>   Signed-off-by: Anthony Liguori <aligu...@us.ibm.com>
>> 
>> 
>>> -smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d]
>>> -smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str]
>>> 
>>> or if you're using libvirt
>>> http://libvirt.org/formatdomain.html#elementsSysinfo
>>> 
>>> 
>>>> 
>>>> For example, in VirtualBox you can use 'vboxmanage setsextradata' to
>>>> set the BIOS product and vendor string per VM.
>>>> 
>>>> Any ideas if this is possible with KVM?
>>>> 
>>>> Thanks,
>>>> Derek--
>>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>>> the body of a message to majord...@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Ryan Harper
>> Software Engineer; Linux Technology Center
>> IBM Corp., Austin, Tx
>> ry...@us.ibm.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to