[one-users] 回复： 回复： 回复： 回复： Attachdisk image to VM failed
Ruben S. Montero
rsmontero at opennebula.org
Wed Oct 31 15:06:27 PDT 2012
Hi
Ok, I got it. The problem is that the delete script of the shred
driver do not delete files. Initially, the "epilog" phase deletes the
whole VM directory so there is no need to delete individual files.
However, this delete scripts is also in charge to delete the detached
disk, so it needs to remove the file... Could you try to simply remove
the directory test
if [ `is_disk $DST_PATH` -eq 1 ]; then
exit 0
fi
in var/remotes/tm/shared/delete. DO NOT FORGET TO onehost sync
Cheers
Ruben
On Wed, Oct 31, 2012 at 9:24 AM, David <david1228 at foxmail.com> wrote:
> Hi Ruben,
>
>
> According to remind you， I will dynamic_ownership set to 0 user set to root
> and group set to root in qemu.conf. then restart libvirtd. After re-create
> the virtual machine, the attach disk files(disk.2... ...) are owned by
> oneadmin.
>
> NOTE: Shared storage mode used NFS.
> $ onedatastore list
> ID NAME CLUSTER IMAGES TYPE TM
> 0 system - 0 - shared
> 1 default - 1 fs shared
> 100 fs_ds - 13 fs shared
>
> Attach disk.2 file( 101M ) was successfully for the first time, then Detach
> disk.2 file does not matter by viewing the vm.log. But the disk.2 file
> actually has not been deleted on the node.
>
> vm.log:
> Wed Oct 31 11:36:20 2012 [VMM][I]: Successfully execute network driver
> operation: post.
> Wed Oct 31 11:36:20 2012 [LCM][I]: New VM state is RUNNING
> Wed Oct 31 11:45:55 2012 [VMM][I]: clone: Cloning
> /opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7 in
> 192.168.32.94:/opt/nebula/ONE/var//datastores/0/30/disk.2
> Wed Oct 31 11:45:55 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:45:55 2012 [VMM][I]: Successfully execute transfer manager
> driver operation: tm_attach.
> Wed Oct 31 11:45:56 2012 [VMM][I]: attach_disk: Executed "virsh --connect
> qemu:///system attach-device one-30
> /opt/nebula/ONE/var//datastores/0/30/disk.2.attach".
> Wed Oct 31 11:45:56 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:45:56 2012 [VMM][I]: Successfully execute virtualization
> driver operation: attach_disk.
> Wed Oct 31 11:45:56 2012 [VMM][E]: VM Disk Successfully attached.
> Wed Oct 31 11:46:23 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:46:23 2012 [VMM][D]: Monitor Information:
> CPU : 8
> Memory: 288676
> Net_TX: 0
> Net_RX: 19992723
> Wed Oct 31 11:50:46 2012 [VMM][I]: detach_disk: Executed "virsh --connect
> qemu:///system detach-disk --domain one-30 --target vdaa".
> Wed Oct 31 11:50:46 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:50:46 2012 [VMM][I]: Successfully execute virtualization
> driver operation: detach_disk.
> Wed Oct 31 11:50:46 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:50:46 2012 [VMM][I]: Successfully execute transfer manager
> driver operation: tm_detach.
> Wed Oct 31 11:50:46 2012 [VMM][E]: VM Disk Successfully detached.
>
> The VM dir on the node :
> [root at compute-13-12 30]# ll -h
> total 31M
> -rw-rw-r-- 1 oneadmin oneadmin 880 Oct 31 11:36 deployment.0
> lrwxrwxrwx 1 oneadmin oneadmin 65 Oct 31 11:36 disk.0 ->
> /opt/nebula/ONE/var/datastores/1/6e3a86a6c257808c750837e50788f1a3
> -rw-rw-r-- 1 oneadmin oneadmin 201M Oct 31 11:36 disk.1
> -rw-rw---- 1 oneadmin oneadmin 101M Oct 31 12:01 disk.2
>
> Attach disk.2 file( 201M ) was also successfully for the second time, The
> disk.2 filewill be overwritten on the node. Because the file owner is
> oneadmin, oneadmin user is configured to SSH trust.
>
> vm.log:
> Wed Oct 31 11:55:46 2012 [VMM][I]: clone: Cloning
> /opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7 in
> 192.168.32.94:/opt/nebula/ONE/var//datastores/0/30/disk.2
> Wed Oct 31 11:55:46 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:55:46 2012 [VMM][I]: Successfully execute transfer manager
> driver operation: tm_attach.
> Wed Oct 31 11:55:46 2012 [VMM][I]: attach_disk: Executed "virsh --connect
> qemu:///system attach-device one-30
> /opt/nebula/ONE/var//datastores/0/30/disk.2.attach".
> Wed Oct 31 11:55:46 2012 [VMM][I]: ExitCode: 0
> Wed Oct 31 11:55:46 2012 [VMM][I]: Successfully execute virtualization
> driver operation: attach_disk.
> Wed Oct 31 11:55:46 2012 [VMM][E]: VM Disk Successfully attached.
> Wed Oct 31 11:56:23 2012 [VMM][I]: ExitCode: 0
>
> The VM dir on the node :
> [root at compute-13-12 30]# ll -h
> total 31M
> -rw-rw-r-- 1 oneadmin oneadmin 880 Oct 31 11:36 deployment.0
> lrwxrwxrwx 1 oneadmin oneadmin 65 Oct 31 11:36 disk.0 ->
> /opt/nebula/ONE/var/datastores/1/6e3a86a6c257808c750837e50788f1a3
> -rw-rw-r-- 1 oneadmin oneadmin 201M Oct 31 11:36 disk.1
> -rw-rw---- 1 oneadmin oneadmin 201M Oct 31 12:04 disk.2
>
> ----------------------------------------------------------
> At the same time, after detach disk file In the LVM storage, the disk.2 file
> corresponding LVM logical volumes have been removed through LVS command to
> check. but disk.2 ln still exists on the node.
>
> Looking forward to your replay! thank you!
>
> Regards
>
> David
>
> ------------------ 原始邮件 ------------------
> 发件人: "Ruben S. Montero"<rsmontero at opennebula.org>;
> 发送时间: 2012年10月30日(星期二) 晚上8:44
> 收件人: "David"<david1228 at foxmail.com>;
> 抄送: "Andr Monteiro"<andre.monteir at gmail.com>;
> "users"<users at lists.opennebula.org>;
> 主题: Re: 回复： 回复： [one-users] 回复： Attachdisk image to VM failed
>
> Hi David,
>
> Let me try to understand what is happening. OpenNebula is supposed to
> execute a delete operation on the node, after successfully detaching the
> disk. Can you send me the vm.log file for this VM?.
>
> disk.2 file is owned by qemu:qemu, so this seems to be a permissions
> problem. Do you have dynamic_ownership set to 0 in qemu.conf?
>
>
> Cheers
>
> Ruben
>
> On Mon, Oct 29, 2012 at 9:21 AM, David <david1228 at foxmail.com> wrote:
>>
>> Hi，
>> A message On's not done.
>> Attach disk to virtual machine also have a problem, as below:
>> onevm detachdisk one-27 2
>> Detach just attach the disk file from virtual machine，found on the node
>> where the VM to detach the actual files not be deleted。
>> -rw-rw-r-- 1 oneadmin oneadmin 1434 Oct 29 14:37 deployment.0
>> -rw-rw-r-- 1 qemu qemu 65 Oct 27 14:50 disk.0
>> -rw-rw-r-- 1 qemu qemu 209715201 Oct 27 14:50 disk.1
>> -rw-rw---- 1 qemu qemu 209715201 Oct 27 16:07 disk.2
>> And then, again attach the image disk to virtual machine, attach failed
>> logs as follows:
>> Sat Oct 27 16:05:09 2012 [VMM][I]: Command execution fail:
>> /opt/nebula/ONE/var/remotes/tm/shared/clone
>> compute-13-10.local:/opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7
>> 192.168.32.94:/opt/nebula/ONE/var//datastores/0/27/disk.2 27 100
>> Sat Oct 27 16:05:09 2012 [VMM][I]: clone: Cloning
>> /opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7 in
>> 192.168.32.94:/opt/nebula/ONE/var//datastores/0/27/disk.2
>> Sat Oct 27 16:05:09 2012 [VMM][E]: clone: Command "cd
>> /opt/nebula/ONE/var/datastores/0/27; cp -r
>> /opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7
>> /opt/nebula/ONE/var/datastores/0/27/disk.2" failed: cp: cannot create
>> regular file `/opt/nebula/ONE/var/datastores/0/27/disk.2': Permission denied
>> Sat Oct 27 16:05:09 2012 [VMM][E]: Error copying
>> compute-13-10.local:/opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7
>> to 192.168.32.94:/opt/nebula/ONE/var//datastores/0/27/disk.2
>> Sat Oct 27 16:05:09 2012 [VMM][I]: ExitCode: 1
>> Sat Oct 27 16:05:09 2012 [VMM][I]: Failed to execute transfer manager
>> driver operation: tm_attach.
>> Sat Oct 27 16:05:09 2012 [VMM][E]: Error attaching new VM Disk: Error
>> copying
>> compute-13-10.local:/opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7
>> to 192.168.32.94:/opt/nebula/ONE/var//datastores/0/27/disk.2
>> Sat Oct 27 16:06:13 2012 [VMM][I]: clone: Cloning
>> /opt/nebula/ONE/var/datastores/100/af3b1eaa21650d2cca395ca1988d36c7 in
>> 192.168.32.94:/opt/nebula/ONE/var//datastores/0/27/disk.2
>> Sat Oct 27 16:06:13 2012 [VMM][I]: ExitCode: 0
>>
>> Because the original disk file is not deleted before attaching， at the
>> same time，It had the same problem use LVM Storage for testing。
>> After detachdisk In the LVM storage, disk.2 file ln points to LVM volume
>> is real deleted。lvs command execution are able to see the volume。 but the
>> disk point link still exists。 so， Attach also have a problem again.
>>
>> Ask what is the reason， and the design is a problem ？
>> Thanks！
>>
>> Regards！
>>
>> david
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "David"<david1228 at foxmail.com>;
>> 发送时间: 2012年10月29日(星期一) 下午2:57
>> 收件人: "André Monteiro"<andre.monteir at gmail.com>; "Ruben S.
>> Montero"<rsmontero at opennebula.org>;
>> 抄送: "users"<users at lists.opennebula.org>;
>> 主题: 回复： 回复： [one-users] 回复： Attachdisk image to VM failed
>>
>>
>> Hi Ruben, André
>>
>> After my tests, It can be mounted successfully when use the following
>> command：
>> onevm attachdisk one-27 --image datablock_ext4 --target vdaa
>> specification：--target can't directly write "vd"， instead，such
>> specific device name vdd or vdaa.
>> vm.log：
>> Mon Oct 29 14:31:18 2012 [VMM][I]: Successfully execute virtualization
>> driver operation: attach_disk.
>> Mon Oct 29 14:31:18 2012 [VMM][E]: VM Disk Successfully attached.
>>
>>
>> ------------------ 原始邮件 ------------------
>> 发件人: "André Monteiro"<andre.monteir at gmail.com>;
>> 发送时间: 2012年10月26日(星期五) 下午5:52
>> 收件人: "Ruben S. Montero"<rsmontero at opennebula.org>;
>> 抄送: "David"<david1228 at foxmail.com>; "users"<users at lists.opennebula.org>;
>> 主题: Re: 回复： [one-users] 回复： Attachdisk image to VM failed
>>
>> Hi Ruben,,
>>
>> In fact, when I made the modification the TYPE expression was getting
>> void, but now I tested it and now it has values. Go figure :-).
>>
>>
>> --
>> André Monteiro
>>
>>
>>
>>
>> On Fri, Oct 26, 2012 at 10:48 AM, Ruben S. Montero
>> <rsmontero at opennebula.org> wrote:
>>>
>>> OK,
>>>
>>> So David, your attach file is right. So, as André pointed out it may be
>>> a problem of specifying the right DEV_PREFIX (vd, sd). Can you perform the
>>> attach operation when setting the right target?
>>>
>>> André, also I can't see the effect of your modifications for the attach
>>> script, after setting up TYPE there is a switch with a default, is that not
>>> being executed in your case?
>>>
>>> Cheers
>>>
>>> Ruben
>>>
>>>
>>> On Thu, Oct 25, 2012 at 12:06 PM, David <david1228 at foxmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> The contents of disk.2.attach File as follows :
>>>> <disk type='file' device='disk'>
>>>> <driver name='qemu' type='raw' />
>>>> <source file='/one_images/0/17/disk.2'/>
>>>> <target dev='vd'/>
>>>> </disk>
>>>>
>>>> $oneimage show 2
>>>> IMAGE 2 INFORMATION
>>>> ID : 2
>>>> NAME : rhel5.5_small
>>>> USER : oneadmin
>>>> GROUP : oneadmin
>>>> DATASTORE : fs_ds
>>>> TYPE : OS
>>>> REGISTER TIME : 10/23 13:51:52
>>>> PERSISTENT : No
>>>> SOURCE :
>>>> /opt/nebula/ONE/var/datastores/100/39b815b6cadf950be128b814bc9f8240
>>>> PATH : /opt/nebula/images/kvm-rhel.5.5.x86_64.small.img
>>>> SIZE : 2.5G
>>>> STATE : used
>>>> RUNNING_VMS : 2
>>>>
>>>> PERMISSIONS
>>>> OWNER : um-
>>>> GROUP : ---
>>>> OTHER : ---
>>>>
>>>> IMAGE TEMPLATE
>>>> DESCRIPTION="redhat5.5 image test."
>>>> DEV_PREFIX="hd"
>>>>
>>>> $ oneimage show 13
>>>> IMAGE 13 INFORMATION
>>>> ID : 13
>>>> NAME : datablock_ext4
>>>> USER : oneadmin
>>>> GROUP : oneadmin
>>>> DATASTORE : fs_ds
>>>> TYPE : DATABLOCK
>>>> REGISTER TIME : 10/25 14:21:51
>>>> PERSISTENT : No
>>>> SOURCE :
>>>> /opt/nebula/ONE/var/datastores/100/166e07951a293cafa312a778fa2fb138
>>>> FSTYPE : ext4
>>>> SIZE : 200M
>>>> STATE : rdy
>>>> RUNNING_VMS : 0
>>>>
>>>> PERMISSIONS
>>>> OWNER : um-
>>>> GROUP : ---
>>>> OTHER : ---
>>>>
>>>> IMAGE TEMPLATE
>>>> DEV_PREFIX="hd"
>>>>
>>>> above, Thanks!
>>>>
>>>> david
>>>>
>>>>
>>>> ------------------ 原始邮件 ------------------
>>>> 发件人: "Ruben S. Montero"<rsmontero at opennebula.org>;
>>>> 发送时间: 2012年10月25日(星期四) 下午5:45
>>>> 收件人: "Andr Monteiro"<andre.monteir at gmail.com>;
>>>> 抄送: "David"<david1228 at foxmail.com>; "users"<users at lists.opennebula.org>;
>>>> 主题: Re: [one-users] 回复： Attachdisk image to VM failed
>>>>
>>>> Hi
>>>>
>>>> So as a summary, it seems that if target is not specified there is no
>>>> default_prefix set for the image, and that is missing from Sunstone?
>>>>
>>>> David, could you send the contents of disk.2.attach file please?
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Ruben
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 25, 2012 at 10:48 AM, André Monteiro
>>>> <andre.monteir at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I was executing from Sunstone. From the command line it also failed if
>>>>> no target is supplied. I ran
>>>>>
>>>>> onevm attachdisk 10 --image datablock_ext4 --target vd
>>>>> And it attached well the disk!
>>>>>
>>>>> DISK=[
>>>>> CLONE="YES",
>>>>> DATASTORE="default",
>>>>> DATASTORE_ID="1",
>>>>> DEV_PREFIX="hd",
>>>>> DISK_ID="2",
>>>>> IMAGE="datablock_ext4",
>>>>> IMAGE_ID="17",
>>>>> READONLY="NO",
>>>>> SAVE="NO",
>>>>>
>>>>> SOURCE="/opt/opennebula/var/datastores/1/a9edec2a65484bef413bedaecb7fb85b",
>>>>> TARGET="vd",
>>>>> TM_MAD="shared",
>>>>> TYPE="FILE" ]
>>>>>
>>>>>
>>>>> --
>>>>> André Monteiro
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 25, 2012 at 9:42 AM, David <david1228 at foxmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I added the default type value according to what you said, but the
>>>>>> problem truly exist.
>>>>>>
>>>>>> Output the default type value is raw, before modification the value is
>>>>>> file. Error did not change. are you no problem？
>>>>>>
>>>>>> the TARGET arg is "sda" and do you know why?
>>>>>> -------------------------------------type raw
>>>>>> ERROR: attach_disk: Command "virsh --connect qemu:///system
>>>>>> attach-device one-17 /one_images/0/17/disk.2.attach" failed: error: Failed
>>>>>> to attach device from /one_images/0/17/disk.2.attach
>>>>>> error: operation failed: adding lsi,id=scsi0,bus=pci.0,addr=0x10
>>>>>> device failed: Parameter 'driver' expects a driver name
>>>>>> Try with argument '?' for a list.
>>>>>> ERROR MESSAGE --8<------
>>>>>> Could not attach /one_images/0/17/disk.2 (sda) to one-17
>>>>>> ERROR MESSAGE ------>8--
>>>>>>
>>>>>> Regards！
>>>>>> david
>>>>>>
>>>>>>
>>>>>> ------------------ 原始邮件 ------------------
>>>>>> 发件人: "André Monteiro"<andre.monteir at gmail.com>;
>>>>>> 发送时间: 2012年10月25日(星期四) 下午4:08
>>>>>> 收件人: "David"<david1228 at foxmail.com>;
>>>>>> 抄送: "users"<users at lists.opennebula.org>;
>>>>>> 主题: Re: [one-users] Attachdisk image to VM failed
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I had the same problem on 3.6 and sent to user list, but no answer.
>>>>>> The problem is on /var/tmp/one/vmm/kvm/attach_disk, the code expression
>>>>>> doesn't get a value. Go to line 50 and add a default type to bus like:
>>>>>>
>>>>>> TYPE="raw"
>>>>>> TYPE=$(echo "$TYPE"|tr A-Z a-z)
>>>>>> and leave the other expression also to override if it is not empty.
>>>>>>
>>>>>> --
>>>>>> André Monteiro
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 25, 2012 at 8:17 AM, David <david1228 at foxmail.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am testing vm atachdisk detachdisk features In OpenNebula3.8，but I
>>>>>>> can't succeed attach the disk (from image respository) to VM，Operation
>>>>>>> proccess is as follows：
>>>>>>> 1. Create the datablock's image ，command：
>>>>>>> $oneimage create -d 100 --name datablock_ext4 --type DATABLOCK
>>>>>>> --size=200 --fstype ext4
>>>>>>> $oneimage list
>>>>>>> ID USER GROUP NAME DATASTORE SIZE TYPE
>>>>>>> PER STAT RVMS
>>>>>>> 1 oneadmin oneadmin Centos6.0 default 10G OS
>>>>>>> No rdy 0
>>>>>>> 11 oneadmin oneadmin ext3DataBlock fs_ds 200M DB
>>>>>>> No rdy 0
>>>>>>> 13 oneadmin oneadmin datablock_ext4 fs_ds 200M DB
>>>>>>> No rdy 0
>>>>>>> 2. $ onevm list
>>>>>>> 17 oneadmin oneadmin test-rhel_swap runn 6 512M 192.168.32
>>>>>>> 0d 03h00
>>>>>>> Start attachdisk，command：
>>>>>>> $onevm attachdisk 17 --image ext3DataBlock
>>>>>>> The VM log as follows:
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: clone: Cloning
>>>>>>> compute-13-10.local:/opt/nebula/ONE/var/datastores/100/b5f5dd05338244bca82fee1b33837fc0
>>>>>>> in /one_images/0/17/disk.2
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: ExitCode: 0
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: Successfully execute transfer
>>>>>>> manager driver operation: tm_attach.
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: Command execution fail:
>>>>>>> /var/tmp/one/vmm/kvm/attach_disk one-17 /one_images/0/17/disk.2 sda 0
>>>>>>> PFZNTV9EUklWRVJfQUNUSU9OX0RBVEE+PEhPU1Q+MTkyLjE2OC4zMi45NzwvSE9TVD48TkVUX0RSVj5kdW1teTwvTkVUX0RSVj48TUlHUl9IT1NULz48TUlHUl9ORVRfRFJWLz48REVQTE9ZX0lEPm9uZS0xNzwvREVQTE9ZX0lEPjxMT0NBTF9ERVBMT1lNRU5UX0ZJTEUvPjxSRU1PVEVfREVQTE9ZTUVOVF9GSUxFLz48Q0hFQ0tQT0lOVF9GSUxFLz48VE1fQ09NTUFORD48IVtDREFUQVtDTE9ORSBzc2ggY29tcHV0ZS0xMy0xMC5sb2NhbDovb3B0L25lYnVsYS9PTkUvdmFyL2RhdGFzdG9yZXMvMTAwL2I1ZjVkZDA1MzM4MjQ0YmNhODJmZWUxYjMzODM3ZmMwIDE5Mi4xNjguMzIuOTc6L29uZV9pbWFnZXMvMC8xNy9kaXNrLjIgMTcgMTAwCl1dPjwvVE1fQ09NTUFORD48RElTS19UQVJHRVRfUEFUSD4vb25lX2ltYWdlcy8wLzE3L2Rpc2suMjwvRElTS19UQVJHRVRfUEFUSD48Vk0+PElEPjE3PC9JRD48VUlEPjA8L1VJRD48R0lEPjA8L0dJRD48VU5BTUU+b25lYWRtaW48L1VOQU1FPjxHTkFNRT5vbmVhZG1pbjwvR05BTUU+PE5BTUU+dGVzdC1yaGVsX3N3YXA8L05BTUU+PFBFUk1JU1NJT05TPjxPV05FUl9VPjE8L09XTkVSX1U+PE9XTkVSX00+MTwvT1dORVJfTT48T1dORVJfQT4wPC9PV05FUl9BPjxHUk9VUF9VPjA8L0dST1VQX1U+PEdST1VQX00+MDwvR1JPVVBfTT48R1JPVVBfQT4wPC9HUk9VUF9BPjxPVEhFUl9VPjA8L09USEVSX1U+PE9USEVSX00+MDwvT1RIRVJfTT48T1RIRVJfQT4wPC9PVEhFUl9BPjwvUEVSTUlTU0lPTlM+PExBU1RfUE9MTD4xMzUxMTQwMTYxPC9MQVNUX1BPTEw+PFNUQVRFPjM8L1NUQVRFPjxMQ01fU1RBVEU+MTc8L0xDTV9TVEFURT48UkVTQ0hFRD4wPC9SRVNDSEVEPjxTVElNRT4xMzUxMTM4MTAyPC9TVElNRT48RVRJTUU+MDwvRVRJTUU+PERFUExPWV9JRD5vbmUtMTc8L0RFUExPWV9JRD48TUVNT1JZPjUyNDI4ODwvTUVNT1JZPjxDUFU+MjA8L0NQVT48TkVUX1RYPjExMTA4PC9ORVRfVFg+PE5FVF9SWD4yMDgxNTYwODwvTkVUX1JYPjxURU1QTEFURT48Q1BVPjwhW0NEQVRBWzJdXT48L0NQVT48RElTSz48Q0xPTkU+PCFbQ0RBVEFbWUVTXV0+PC9DTE9ORT48REFUQVNUT1JFPjwhW0NEQVRBW2ZzX2RzXV0+PC9EQVRBU1RPUkU+PERBVEFTVE9SRV9JRD48IVtDREFUQVsxMDBdXT48L0RBVEFTVE9SRV9JRD48REVWX1BSRUZJWD48IVtDREFUQVtoZF1dPjwvREVWX1BSRUZJWD48RElTS19JRD48IVtDREFUQVswXV0+PC9ESVNLX0lEPjxJTUFHRT48IVtDREFUQVtyaGVsNS41X3NtYWxsXV0+PC9JTUFHRT48SU1BR0VfSUQ+PCFbQ0RBVEFbMl1dPjwvSU1BR0VfSUQ+PFJFQURPTkxZPjwhW0NEQVRBW05PXV0+PC9SRUFET05MWT48U0FWRT48IVtDREFUQVtOT11dPjwvU0FWRT48U09VUkNFPjwhW0NEQVRBWy9vcHQvbmVidWxhL09ORS92YXIvZGF0YXN0b3Jlcy8xMDAvMzliODE1YjZjYWRmOTUwYmUxMjhiODE0YmM5ZjgyNDBdXT48L1NPVVJDRT48VEFSR0VUPjwhW0NEQVRBW2hkYV1dPjwvVEFSR0VUPjxUTV9NQUQ+PCFbQ0RBVEFbc3NoXV0+PC9UTV9NQUQ+PFRZUEU+PCFbQ0RBVEFbRklMRV1dPjwvVFlQRT48L0RJU0s+PERJU0s+PENMT05FPjwhW0NEQVRBW1lFU11dPjwvQ0xPTkU+PERBVEFTVE9SRT48IVtDREFUQVtmc19kc11dPjwvREFUQVNUT1JFPjxEQVRBU1RPUkVfSUQ+PCFbQ0RBVEFbMTAwXV0+PC9EQVRBU1RPUkVfSUQ+PERFVl9QUkVGSVg+PCFbQ0RBVEFbaGRdXT48L0RFVl9QUkVGSVg+PERJU0tfSUQ+PCFbQ0RBVEFbMV1dPjwvRElTS19JRD48SU1BR0U+PCFbQ0RBVEFbZGF0YWJsb2NrMl1dPjwvSU1BR0U+PElNQUdFX0lEPjwhW0NEQVRBWzEwXV0+PC9JTUFHRV9JRD48UkVBRE9OTFk+PCFbQ0RBVEFbTk9dXT48L1JFQURPTkxZPjxTQVZFPjwhW0NEQVRBW05PXV0+PC9TQVZFPjxTT1VSQ0U+PCFbQ0RBVEFbL29wdC9uZWJ1bGEvT05FL3Zhci9kYXRhc3RvcmVzLzEwMC80N2M0MjI3YzU4MjJjNmY4MTNiMTkxNDRmZjExNzQxNF1dPjwvU09VUkNFPjxUQVJHRVQ+PCFbQ0RBVEFbaGRiXV0+PC9UQVJHRVQ+PFRNX01BRD48IVtDREFUQVtzc2hdXT48L1RNX01BRD48VFlQRT48IVtDREFUQVtGSUxFXV0+PC9UWVBFPjwvRElTSz48RElTSz48QVRUQUNIPjwhW0NEQVRBW1lFU11dPjwvQVRUQUNIPjxDTE9ORT48IVtDREFUQVtZRVNdXT48L0NMT05FPjxEQVRBU1RPUkU+PCFbQ0RBVEFbZnNfZHNdXT48L0RBVEFTVE9SRT48REFUQVNUT1JFX0lEPjwhW0NEQVRBWzEwMF1dPjwvREFUQVNUT1JFX0lEPjxERVZfUFJFRklYPjwhW0NEQVRBW3NkXV0+PC9ERVZfUFJFRklYPjxESVNLX0lEPjwhW0NEQVRBWzJdXT48L0RJU0tfSUQ+PElNQUdFPjwhW0NEQVRBW3ZtMmRpc2tdXT48L0lNQUdFPjxJTUFHRV9JRD48IVtDREFUQVs5XV0+PC9JTUFHRV9JRD48UkVBRE9OTFk+PCFbQ0RBVEFbTk9dXT48L1JFQURPTkxZPjxTQVZFPjwhW0NEQVRBW05PXV0+PC9TQVZFPjxTT1VSQ0U+PCFbQ0RBVEFbL29wdC9uZWJ1bGEvT05FL3Zhci9kYXRhc3RvcmVzLzEwMC9iNWY1ZGQwNTMzODI0NGJjYTgyZmVlMWIzMzgzN2ZjMF1dPjwvU09VUkNFPjxUQVJHRVQ+PCFbQ0RBVEFbc2RhXV0+PC9UQVJHRVQ+PFRNX01BRD48IVtDREFUQVtzc2hdXT48L1RNX01BRD48VFlQRT48IVtDREFUQVtGSUxFXV0+PC9UWVBFPjwvRElTSz48R1JBUEhJQ1M+PExJU1RFTj48IVtDREFUQVswLjAuMC4wXV0+PC9MSVNURU4+PFBPUlQ+PCFbQ0RBVEFbNTkxN11dPjwvUE9SVD48VFlQRT48IVtDREFUQVt2bmNdXT48L1RZUEU+PC9HUkFQSElDUz48TUVNT1JZPjwhW0NEQVRBWzUxMl1dPjwvTUVNT1JZPjxOQU1FPjwhW0NEQVRBW3Rlc3QtcmhlbF9zd2FwXV0+PC9OQU1FPjxOSUM+PEJSSURHRT48IVtDREFUQVtrdm1icjBdXT48L0JSSURHRT48SVA+PCFbQ0RBVEFbMTMwLjEwLjAuNF1dPjwvSVA+PE1BQz48IVtDREFUQVswMjowMDo4MjowYTowMDowNF1dPjwvTUFDPjxORVRXT1JLPjwhW0NEQVRBW0JsdWUgTEFOXV0+PC9ORVRXT1JLPjxORVRXT1JLX0lEPjwhW0NEQVRBWzBdXT48L05FVFdPUktfSUQ+PE5FVFdPUktfVU5BTUU+PCFbQ0RBVEFbb25lYWRtaW5dXT48L05FVFdPUktfVU5BTUU+PFZMQU4+PCFbQ0RBVEFbTk9dXT48L1ZMQU4+PC9OSUM+PFZNSUQ+PCFbQ0RBVEFbMTddXT48L1ZNSUQ+PC9URU1QTEFURT48SElTVE9SWV9SRUNPUkRTPjxISVNUT1JZPjxPSUQ+MTc8L09JRD48U0VRPjA8L1NFUT48SE9TVE5BTUU+MTkyLjE2OC4zMi45NzwvSE9TVE5BTUU+PEhJRD43PC9ISUQ+PFNUSU1FPjEzNTExMzgxMDY8L1NUSU1FPjxFVElNRT4wPC9FVElNRT48Vk1NTUFEPnZtbV9rdm08L1ZNTU1BRD48Vk5NTUFEPmR1bW15PC9WTk1NQUQ+PFRNTUFEPnNzaDwvVE1NQUQ+PERTX0xPQ0FUSU9OPi9vbmVfaW1hZ2VzPC9EU19MT0NBVElPTj48RFNfSUQ+MDwvRFNfSUQ+PFBTVElNRT4xMzUxMTM4MTA2PC9QU1RJTUU+PFBFVElNRT4xMzUxMTM4MzU0PC9QRVRJTUU+PFJTVElNRT4xMzUxMTM4MzU0PC9SU1RJTUU+PFJFVElNRT4wPC9SRVRJTUU+PEVTVElNRT4wPC9FU1RJTUU+PEVFVElNRT4wPC9FRVRJTUU+PFJFQVNPTj4wPC9SRUFTT04+PC9ISVNUT1JZPjwvSElTVE9SWV9SRUNPUkRTPjwvVk0+PC9WTU1fRFJJVkVSX0FDVElPTl9EQVRBPg==
>>>>>>> 17 192.168.32.97
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][E]: attach_disk: Command "virsh
>>>>>>> --connect qemu:///system attach-device one-17
>>>>>>> /one_images/0/17/disk.2.attach" failed: error: Failed to attach device from
>>>>>>> /one_images/0/17/disk.2.attach
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: error: operation failed: adding
>>>>>>> lsi,id=scsi0,bus=pci.0,addr=0x5 device failed: Parameter 'driver' expects a
>>>>>>> driver name
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: Try with argument '?' for a list.
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][E]: Could not attach
>>>>>>> /one_images/0/17/disk.2 (sda) to one-17
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: ExitCode: 1
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][I]: Failed to execute virtualization
>>>>>>> driver operation: attach_disk.
>>>>>>> Thu Oct 25 12:49:48 2012 [VMM][E]: Error attaching new VM Disk: Could
>>>>>>> not attach /one_images/0/17/disk.2 (sda) to one-17
>>>>>>> Thu Oct 25 12:52:41 2012 [VMM][I]: ExitCode: 0
>>>>>>> Thu Oct 25 12:52:41 2012 [VMM][D]: Monitor Information:
>>>>>>> what the above reason ?
>>>>>>> How to successfully attch disk image to virtual machine?
>>>>>>> Looking forward to reply！
>>>>>>>
>>>>>>> Regards！
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opennebula.org
>>>>>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opennebula.org
>>>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ruben S. Montero, PhD
>>>> Project co-Lead and Chief Architect
>>>> OpenNebula - The Open Source Solution for Data Center Virtualization
>>>> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>>>
>>>
>>>
>>>
>>> --
>>> Ruben S. Montero, PhD
>>> Project co-Lead and Chief Architect
>>> OpenNebula - The Open Source Solution for Data Center Virtualization
>>> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>>
>>
>
>
>
> --
> Ruben S. Montero, PhD
> Project co-Lead and Chief Architect
> OpenNebula - The Open Source Solution for Data Center Virtualization
> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
--
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
More information about the Users
mailing list