On Mon, Feb 04, 2008 at 09:44:12AM -0500, Daniel Veillard wrote: > > So basically Xen PV, Xen FV and KVM <os> blocks should now share the > same set of functionalities, sharight the same syntax, right ? And the > refactoring comes from the 3 being able to share more code, if yes that > sounds excellent :-)
Almost the same. pv guests won't have use for a <boot dev="c"/> tag since they have no BIOS, nor do they have a <loader> tag, but other than that they're the same. > > <domain type='xen'> > > <name>kernel</name> > > <uuid>06ed00fe-1162-4fc4-b5d8-11993ee4a8b9</uuid> > > <os> > > <type>hvm</type> > > <loader>/usr/lib/xen/boot/hvmloader</loader> > > <kernel>/root/vmlinuz.f864</kernel> > > <initrd>/root/initrd.img.f864</initrd> > > <cmdline>console=ttyS0 console=tty0</cmdline> > > </os> > > <memory>540672</memory> > > <currentMemory>531456</currentMemory> > > <vcpu>1</vcpu> > > <on_poweroff>preserve</on_poweroff> > > <on_reboot>preserve</on_reboot> > > <on_crash>preserve</on_crash> > > <features> > > <acpi/> > > <apic/> > > <pae/> > > </features> > > <devices> > > <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> > > <interface type='bridge'> > > <source bridge='xenbr0'/> > > <mac address='00:16:3e:0e:e8:b7'/> > > <script path='vif-bridge'/> > > </interface> > > <disk type='file' device='disk'> > > <driver name='file'/> > > <source file='/root/kernel.img'/> > > <target dev='hda'/> > > </disk> > > <input type='mouse' bus='ps2'/> > > <graphics type='vnc' port='-1' listen='0.0.0.0'/> > > <console tty='pty'/> > > </devices> > > </domain> > > If we were to switch that domain to PV, the change would basically > to remove os/loader and devices/emulator, change os/type to be linux, > and then get kernel and initrd to point to the PV versions, right ? No need to get rid of devices/emulator - that's valid for paravirt guests too now - qemu-dm is used to provide the VNC / SDL framebuffer and text console in paravirt guests too now. So merely remove loader and the os/type to linux. > > + /* > > + * Originally XenD abused the 'kernel' parameter for the HVM > > + * firmware. New XenD allows HVM guests to boot from a kernel > > + * and if this is enabled, the HVM firmware must use the new > > + * 'loader' parameter > > + */ > > + if (hasKernel) { > > + virBufferVSprintf(buf, "(loader '%s')", (const char *) loader); > > } else { > > virBufferVSprintf(buf, "(kernel '%s')", (const char *) loader); > > } > > What happen if someone uses libvirt-0.4.1 with an old xend and an HVM > with kernel XML description is given ? I suppose (kernel) gets ignored > but it fails because the loader is not proper. Yep, user error. If they try to use a kernel+initrd on an old XenD there's nothing we can do to make it work. I don't want to do a Xen version check in libvirt though, because this kernel+initrd stuff is something I backport to the Xen currently in Fedora so any version check would be bogus. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list