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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list