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

Reply via email to