[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/2] V2 Modify generic ethernet interface so it will work when sVirt is enabled with qemu

On Mon, Oct 31, 2011 at 11:37 AM, Eric Blake <eblake redhat com> wrote:
> On 10/28/2011 08:59 PM, Tyler Coumbes wrote:
>> On Thu, Oct 27, 2011 at 10:25 PM, Eric Blake<eblake redhat com>  wrote:
>>> On 10/24/2011 05:44 PM, Tyler Coumbes wrote:
>>>> This patch makes the changes to the generic ethernet interface for
>>>> QEMU. Allowing it to be used with sVirt enabled.
>>>>  src/qemu/qemu_command.c |   79
>>>> ++++++++++++++++++++++++++++++++++++++++++++--
>>>>  src/qemu/qemu_command.h |    4 ++
>>>>  src/qemu/qemu_hotplug.c |   15 +++++++++
>>>>  src/qemu/qemu_process.c |   13 ++++++++
>>>>  4 files changed, 107 insertions(+), 4 deletions(-)
>>> I haven't reviewed this one closely yet, but it would help if you added a
>>> test in tests/qemuxml2argvtest.c and a new pair of files in
>>> tests/qemuxml2argvdata/* that exercise the code to prove the new command
>>> line options look sane.
>> Two questions about creating a test for this code. How do I get the
>> actual args so I can compare them to my expected args to see what
>> isn't matching up? VIR_TEST_DEBUG=2 shows me what tests fail but not
>> any detail about why.
> VIR_TEST_DEBUG=1 shows a diff between expected and actual text; I'm not sure
> why VIR_TEST_DEBUG=2 wouldn't do the same, without diving into the test code
> more.
>> I think it is because one of the parameters to
>> qemu is a file descriptor which could change for each run. Is there
>> some type of wildcard I can use like fd=%. I don't see any other tests
>> using file descriptors to compare to and am not finding anything in
>> any documentation I can find.
> tests/qemuxml2argvdata/qemuxml2argv-restore-v2-fd.args is an example file
> that hard-codes a particular fd, and sets things up so that
> qemuxml2argvtest.c passes that hard-coded fd through DO_TEST_FULL, which in
> turn passes it through the migrateFd argument of qemuBuildCommandLine.
> This may mean that we need to refactor things slightly to make it easier for
> testing.  One idea is to have normal calls to qemuBuildCommandLine call
> through a function pointer that opens a TAP and returns that FD; whereas
> running it from the testsuite sets that function pointer to provide a
> replacement function that just returns a hard-coded number rather than
> opening an fd.

Still not having any luck. I have to be missing something simple.
Below are the test xml and args files I have added in
tests/qemuxml2argvdata/. They are based on the qemuxml2argv-net-eth


<domain type='qemu'>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='hd'/>
  <clock offset='utc'/>
    <disk type='block' device='disk'>
      <source dev='/dev/HostVG/QEMUGuest1'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    <controller type='ide' index='0'/>
    <interface type='ethernet'>
      <mac address='00:11:22:33:44:55'/>
    <memballoon model='virtio'/>


LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M \
pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait \
-no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net nic,\
macaddr=00:11:22:33:44:55,vlan=0 -net tap,fd=7,\
vlan=0 -serial none -parallel none -usb

At first I tried adding the following to qemuxml2argvtest.c
DO_TEST("net-eth-fd", false, NONE);

Then after your suggestion I tried
DO_TEST_FULL("net-eth-fd", "stdio", 7, false,  QEMU_CAPS_MIGRATE_QEMU_FD);

Both resulted in the same result. A failed test with no actual and
expected command line shown. Just FAILED like below.

VIR_TEST_DEBUG=1 ./qemuxml2argvtest


83) QEMU XML-2-ARGV net-eth                                           ... OK
84) QEMU XML-2-ARGV net-eth-fd                                        ... FAILED
85) QEMU XML-2-ARGV net-eth-ifname                                    ... OK


I get the same output with VIR_TEST_DEBUG=2 as well.

No actual and expected output on the FAILED. Maybe something is going
wrong before it even gets that far? Not sure what I am missing.

Below is the actual commandline generated from a test VM running on my
development server. You can see the -netdev tap,fd=27, in the command

/usr/bin/qemu-kvm -S -M pc-0.14 -cpu qemu32 -enable-kvm -m 1024 -smp
1,sockets=1,cores=1,threads=1 -name test -uuid
7fcf83f2-9c90-af39-e1f8-bdc7cadbf9c3 -nodefconfig -nodefaults -chardev
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -drive
-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1
-drive 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
-netdev tap,fd=27,id=hostnet0 -device
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -usb -vnc -vga
cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]