On 7/4/2012 6:50 PM, Alex Jia wrote:
> On 07/04/2012 05:32 PM, Yu Mingfei wrote:
>> Hi Chris,Alex:
>>
>> Thanks for your comments.
>> I am sorry about making you mistake "virt-edit" with "virsh edit".
> NP.
>>
>> We need to test virt-edit here,
>> and virt-edit modifies a file in a domain's img directly.
> You mean to modify VM's disk path? or relevant XML configuration?
Yes, virt-edit modifies a file in VM's disk.
And there is no relevant with XML configuration.

>>
>> However, create_new_vm() just renames a vm.
>> Sometimes, we want to test a vm with different names, right or wrong.
>> For example: 12345678, -vm1, #, and so on. (Please refer to patch 3/3 v2)
> As I said, you may write 'virsh edit' or 'virsh define' case to test
> VM's XML configuration change
> such as changing VM's name, VM's disk bus, VM's network mode, etc. and
> virsh_define() has been
> encapsulated in libvirt_vm module, but if you just check different VM's
> name, it's incomplete
> for 'virsh edit' or 'virsh define'.
>>
>> To keep the vm1(main test vm) object safe, we decide to define a new
>> vm object with a new name.
>> All the new-name tests are based on the new vm object, and vm1 will be
>> shutdown before new vm is defined.
> In fact, if you don't change VM's disk path then the new VM will use
> previous VM's disk image, if you have other
> operation on the disk later such as writing data into the disk, it's not
> safe.
You are right.But we have kept previous VM shut down before new vm is started.
And we are sure our operation will not effect guest's normal running.
For example,we virt-edit "/etc/hosts" in a VM's disk,and we just add
a comment in it, like "#foo".

>> After the test, the new vm will be undefined.
>> This is why this function is created.
>>
>> This function is also used in many other tests of ours.
> Please show some examples if you don't mind, I'm interested in your test.
I'm working on these tests now, and I will send them soon.^^

>> And according to Cleber's suggestion, I put it into a seperate file
>> libvirt_xml_utils.py.
>>
> IMHO, you may write some small functions to construct different VM's XML
> in libvirt_xml_utils.py then
> the module should focus on XML generation and shouldn't mix other API
> functions such as
> libvirt_vm.virsh_define(), libvirt_vm.VM(), etc.
OK, I understand.

>>
>> Maybe the create_new_vm() or its name confused your guys. How about
>> the following idea ?
>>
>> Implement a vm.rename() function in libvirt_cm.py, doing the following
>> things:
>> 1. xml_bak = self.backup_xml()
>> 2. self.undefine()
>> 3. change the name in xml_bak into a new one
>> 4. self.define(xml_bak)
> s/xml_bak/new xml/.
>>
>> 5. self.name = new_name
>> 6. remove xml_bak
>>
> If you use 'virsh edit' to do this, you don't need 2, 4 steps, 'virsh
> edit' will automatically define a VM with new name,
> of course, you need to remove <uuid>..</uuid> line from VM's XML via
> 'virsh edit'.
I have tried "virsh edit", as you said, it can change VM's name easy.
But I forgot to remove "uuid", it made me fail to rename VM.
Now I will try it again,thanks.

>
> Anyway, if you want to implement a new vm.rename() in libvirt_vm.py,
> it's okay for me, in addition, you also
> need to write some cases to test it. thanks.
Yes, of course.

>
> Regards,
> Alex
>
>
>

-- 
Best Regards
Yu Mingfei

_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest

Reply via email to