2:09 p.m.
Hi Daniel,
Daniel P. Berrange wrote: [Tue Jan 23 2007, 10:49:07AM EST]
For HVM installs, the different should only be the addition of the
CDROM device. If you take a look in /var/log/xen/xend.log it should
show you the final SEXPR that XenD is getting when creating the
guest. Comparing the SEXPR seen when booting the config file, vs
that generated by virt-intsall may shed some more light on the
problem.
Also, virt-install has a --debug flag which will make it show the libvirt
XML description it used to boot.
Thanks for these suggestions. Yongkang looked at xend.log and found
this:
You, Yongkang wrote: [Thu Jan 25 2007, 10:26:33AM EST]
Thanks for the information. I have check /var/log/xen/xend.log.
Found something interesting. When using virt-install to install VTI
domain, it seemed didn't parse the right vcpu number to qemu-dm.
Please look at the following log:
1. The spawning qemu log, when installation by virt-intall with vcpu=4:
---------------------
[2007-01-25 23:14:13 xend 2817] INFO (image:418) spawning device models:
/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '9',
'-m', '1024', '-boot', 'c', '-acpi',
'-domain-name', 'test', '-net',
'nic,vlan=1,macaddr=00:16:3e:0a:d2:86,model=rtl8139', '-net',
'tap,vlan=1,bridge=xenbr0', '-vncunused', '-vnclisten',
'127.0.0.1']
~~~~~~~~~~~~
2. The spawning qemu log, when use command "xm create":
------------------------
[2007-01-25 17:13:13 xend 2817] INFO (image:418) spawning device models:
/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '7',
'-m', '1024', '-boot', 'd', '-vcpus', '4',
'-acpi', '-domain-name', 'ExampleVTIDomain', '-net',
'nic,vlan=1,macaddr=00:16:3e:31:42:c4,model=rtl8139', '-net',
'tap,vlan=1,bridge=xenbr0', '-vncviewer']
~~~~~~~~~~~
There is "-vcpus 4" in the 2nd log. It means qemu would create up
a 4 vpucs VTI domain.
For the situation 1, although qemu doesn't get any information about
"vcpu=4". But xen has already prepared 2 vcpus to qemu. Will it be
the problem?
I'm looking through the code now to see if I can find where this is
going awry, but while I'm looking, does this ring a bell for you?
Thanks,
Aron
2:40 p.m.
New subject: [Libvir] what is virt-install doing differently?
On Wed, Jan 31, 2007 at 03:09:48PM -0500, Aron Griffis wrote:
You, Yongkang wrote: [Thu Jan 25 2007, 10:26:33AM EST]
> Thanks for the information. I have check /var/log/xen/xend.log.
> Found something interesting. When using virt-install to install VTI
> domain, it seemed didn't parse the right vcpu number to qemu-dm.
> Please look at the following log:
>
> 1. The spawning qemu log, when installation by virt-intall with vcpu=4:
> ---------------------
> [2007-01-25 23:14:13 xend 2817] INFO (image:418) spawning device models:
/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '9',
'-m', '1024', '-boot', 'c', '-acpi',
'-domain-name', 'test', '-net',
'nic,vlan=1,macaddr=00:16:3e:0a:d2:86,model=rtl8139', '-net',
'tap,vlan=1,bridge=xenbr0', '-vncunused', '-vnclisten',
'127.0.0.1']
> ~~~~~~~~~~~~
>
> 2. The spawning qemu log, when use command "xm create":
> ------------------------
> [2007-01-25 17:13:13 xend 2817] INFO (image:418) spawning device models:
/usr/lib/xen/bin/qemu-dm ['/usr/lib/xen/bin/qemu-dm', '-d', '7',
'-m', '1024', '-boot', 'd', '-vcpus', '4',
'-acpi', '-domain-name', 'ExampleVTIDomain', '-net',
'nic,vlan=1,macaddr=00:16:3e:31:42:c4,model=rtl8139', '-net',
'tap,vlan=1,bridge=xenbr0', '-vncviewer']
> ~~~~~~~~~~~
>
> There is "-vcpus 4" in the 2nd log. It means qemu would create up
> a 4 vpucs VTI domain.
>
> For the situation 1, although qemu doesn't get any information about
> "vcpu=4". But xen has already prepared 2 vcpus to qemu. Will it be
> the problem?
I'm looking through the code now to see if I can find where this is
going awry, but while I'm looking, does this ring a bell for you?
Ok, I can see what's happening here. The SEXPR that we feed to XenD
when creating a guest with libvirt looks like this:
(vm
(name XenGuest2)
(memory 394)
(maxmem 579)
(vcpus 3)
(uuid c7a5fdb2-cdaf-9455-926a-d65c16db1809)
(image
(hvm
(kernel /usr/lib/xen/boot/hvmloader)
(device_model /usr/lib/xen/bin/qemu-dm)
(pae 1)
(boot c)
(vnc 1)
(vncunused 1)
(display :0.0)
(xauthority /root/.xauthcmQHfd)
(acpi 1)
(apic 1)
(vncpasswd 123456)
)
)
(device (vbd (uname phy:/dev/HostVG/XenGuest2) (dev hda) (mode w)))
(device (vif (bridge xenbr1) (mac 00:16:3E:66:92:9C) (type ioemu)))
)
But when you use 'xm create' it is ever so slightly different:
(vm
(name XenGuest2)
(memory 394)
(maxmem 579)
(vcpus 3)
(uuid c7a5fdb2-cdaf-9455-926a-d65c16db1809)
(image
(hvm
(kernel /usr/lib/xen/boot/hvmloader)
(device_model /usr/lib/xen/bin/qemu-dm)
(pae 1)
(vcpus 3)
(boot c)
(vnc 1)
(vncunused 1)
(display :0.0)
(xauthority /root/.xauthcmQHfd)
(acpi 1)
(apic 1)
(vncpasswd 123456)
)
)
(device (vbd (uname phy:/dev/HostVG/XenGuest2) (dev hda) (mode w)))
(device (vif (bridge xenbr1) (mac 00:16:3E:66:92:9C) (type ioemu)))
)
Notice that the '(vcpus 3)' bit is duplicated twice in the SEXPR that
xm sends - once at top level and once within (image). It looks like
when creating HVM guests you need both set to get it to work correctly.
Frankly this is utterly insane - XenD should simply copy the top level
value for vcpus into the (image) block as needed.
Since we need compatability with all Xen 3.0.x series codebases, it looks
like we'll need to do a tiny bit of magic in libvirt to also send the
vcpus stuff twice for HVM. Urgh :-(
Regards,
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 -=|
3:12 p.m.
New subject: [Libvir] what is virt-install doing differently?
Daniel P. Berrange wrote: [Wed Jan 31 2007, 03:40:38PM EST]
Notice that the '(vcpus 3)' bit is duplicated twice in the
SEXPR that
xm sends - once at top level and once within (image). It looks like
when creating HVM guests you need both set to get it to work correctly.
Frankly this is utterly insane - XenD should simply copy the top level
value for vcpus into the (image) block as needed.
Since we need compatability with all Xen 3.0.x series codebases, it looks
like we'll need to do a tiny bit of magic in libvirt to also send the
vcpus stuff twice for HVM. Urgh :-(
Ugly, I agree, but I'm glad you found it...
Send me a version to test if you'd like. I'm updating the RHEL5 BZ to
reference this conversation, hopefully we can still get a fix in
there.
Regards,
Aron
6504
days inactive
6504
days old
2 comments
2 participants
participants (2)
-
Aron Griffis -
Daniel P. Berrange